I've installed WebSphere MQ 7.1 on Linux platform, after which I installed WebSphere Message Broker 8.0.0.1. Now when I try to create an execution group, I get an exception: Reason code 2035. This exception states that the user is unauthorised to connect to the queue manager. I have this user added in the mqm group. I did not face any such issue when I was working with MQ 7.0.x. I searched a lot and came to know that there is user ID blocking in MQ 7.1. But, I want this user to be able to create execution group, how can I do so? Please advise.
MQ security has been improved a lot in MQ v7.1 and is different from what it used to be in earlier MQ versions. In MQ v7.1, by default all SYSTEM.channels are blocked. If you are trying to use any of these SYSTEM. channels then you will get 2035 which is MQRC_NOT_AUTHORIZED. The recommended way is to create your own SVRCONN channel for broker and create channel authentication records to allow the user to access queue manager.
Please see this link for detailed answers from T.Rob on similar issue.
Update:
A SVRCONN channel defines the endpoint of a queue manager meaning the connection information required by the clients to connect to a queue manager. Client applications use this type of channel to send and receive messages to/from a queue or a topic.
Message Broker toolkit is GUI that you can use to administer message broker, for example creating execution groups, creating flow, deploying bar files etc. Toolkit is available on Windows and I guess it's available on Linux.
I got to know that MB toolkit requires SYSTEM.BRK.CONFIG channel which is a SVRCONN channel to connect to queue manager. I am thinking this is the channel you will need to authorize to allow Message Broker to connect to MQ. Can you check if this is the case and if so create channel authentication record for that channel?
If you create a new QMgr at V7.1 or above, it comes with the following default CHLAUTH rules:
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
DESCR(Default rule to allow MQ Explorer access)
ADDRESS(*)
MCAUSER( ) USERSRC(CHANNEL)
SET CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
DESCR(Default rule to disable all SYSTEM channels)
ADDRESS(*)
MCAUSER( ) USERSRC(NOACCESS)
SET CHLAUTH(*) TYPE(BLOCKUSER)
DESCR(Default rule to disallow privileged users)
USERLIST(*MQADMIN)
The one on the bottom tells the QMgr "if someone tries to connect over a SVRCONN using an administrative user ID, block the connection in all cases."
To allow a connection from Broker Toolkit you have two choices as follows:
Remove mqbrkrs from the mqm group. This allows it to connect without firing the CHLAUTH rule that blocks admin users. You will of course be required to grant authorization for the mqbrkrs group to all the broker and application queues to which it needs access since it is no longer an MQ admin.
Override the CHLAUTH rule to allow the broker toolkit to connect as an admin on the SYSTEM.BROKER.CONFIG channel.
As a security specialist, I favor the first option. It is unavoidable that the MQ admin can administer the broker. However it is possible to avoid allowing the broker (and by extension all the broker flows) to administer the QMgr.
If, however, you wish to take the second route you'll need to override the CHLAUTH rule that blocks admin access. There are several ways to do this. You could delete the rule but that opens all your channels to admin connections. A more precise approach is to provide a rule just for the channel on which the administrator is to connect. For example:
SET CHLAUTH(SYSTEM.BKR.CONFIG) TYPE(BLOCKUSER) +
USERLIST('*NOACCESS')
Since WMQ applies the most specific rule, the default rule is overridden by the new one but only for the SYSTEM.BKR.CONFIG channel. The BLOCKUSER rule syntax allows us to specify who to deny but not who to allow and it takes user IDs rather than group IDs. In order to allow admin access it is necessary to specify some ID that is not *MQADMIN. I picked *NOACCESS because it cannot be an actual user ID and is a reserved word used by WMQ elsewhere. You could as easily used any user ID such as nobody or even mqm. (Blocking mqm would allow mqbrkrs but not mqm however since mqbrkrs is in the mqm group it would not restrict mqbrkrs from administering the QMgr.)
Finally, note that any channel which allows admin access should be strongly authenticated. If the only CHLAUTH rule you set is the one above, then anybody with a network route to the QMgr can connect on that channel by asserting the mqbrkrs user ID on the connection. Once connected, they would have full control over the QMgr and the ability to remotely, anonymously execute commands using the mqm or mqbrkrs user IDs. At the very least add a CHLAUTH rule to filter conenctions on this channel by IP address. Or, even better, use SSL and filter connections by the certificate distinguished name.
Related
We have concept of Operators(Employees, Merchants, Billers) and Subscribers in our applications. We have installed OpenAM 12.0 with default configuration to test the setup. We are thinking of setting up realms hierarchy
/Top Level Realm
Operators
Subscribers
When we add a user to a realm via "Subscribers"->"Subjects"->"Users"->"Add", the added user also appears in "Operators" realm. Is there a way to make sure this user is isolated to Subscribers realm?
I have an application where an user can belong to many companies. The user access the company portal via compnaysubdomain.example.com). When an user access a compnay portal I have to update the roles he have for that company (By checking the subdomain and the database).
I created a request event listener for that, which parses the subdomain, queries the database and adds the new roles to the user. The problem is I need to be able to to access the security context so I can update the user roles, so my listener priority has to be less than Firewall priority. But, if firewall listener is executed first, It checks for the user Roles immediatly which are not updated yet based on the company.
Any suggestions?. May be I need to implement a Custom Firewall Listener or something like that. I dont want to overcomplicate.
Thank you.
Ok. I have decided to create A Firewall listener to achieve this.
I followed the tutorial http://symfony.com/doc/current/cookbook/security/custom_authentication_provider.html but only created the Firewall LIstener. The token and provider I am using the one that I was already using.
I'm looking for information about authentication but I'm very newbie so I don't know any system.
My requeriments are: An user only can authenticate from one computer/mobile device/tablet.
I'm thinking about a monitoring system of MAC address and when the user connect using other device I can see this like an alert.
What other methods are there? Certificates?.
Repeat, I'm very newbie with this.
PD: My app has been development with framework Symfony2
So first of all MAC address is a network local address, which means that after it goes trough router/switch the MAC address changes, so you cannot relay on this. Even if you wanted to lookup interface MAC addres with your client software MAC's can be changed.
Secondly Certificates give you certain properties like nonrepudiation (you can calculate digital signatures on operations that users do and then the could not deny doing something in your application). But Public Key Infrastructure is really hard to manage! You would need your Certificate Authority to give valid certificates, You would need to monitor and update Certificate Revocation Lists to deny stolen/invalid/forged certificates from being treated as valid and authentic.
If it is not a security centric application and after you analyzed your options I would suggest simple form authentication (username/password/captcha). And write mechanizm that would periodicly (i.e. every second) send an AJAX request refreshing user status, thus you could recognize if user closed browser or has opened window. And in your authentication process you could check for other ACTIVE sessions for given username and deny login or act in some other fashion. If you need more informations about authentication I would recomend looking through security patterns
I realize that mac addresses or machine ids aren't transferred over the internet, however, I would like to lock down our subscription-based website security so that only specific computers can register and have access to its resources.
Large organizations will subscribe to our service and will undoubtedly have more than one ip for their organization. As well, we'd like to give the ability for their qualified employees to access the website on devices outside of their physical organization (for road-trip presentations, etc.).
Is there a sure-fire way to achieve this end (beyond the username/password assigned to each account)? If not, what would be the most effective approach?
Instead of restricting access via IP, you want to use something that's actually secure.
Username and password over an HTTPS connection should at least be unsniffable, but you might want to look in to client SSL certificates. They can be configured in Apache or other web server software. If username/password authentication is not enough, this is the next (and perhaps final) step up.
UPDATE:
That said, what many application providers will do is provide a method for subscribers to implement an ACL for their accounts. You can even force people to consider their ACL before allowing them to access your services. Think of it this way:
An account is set up in your system allowing login from anywhere. Upon creation, the ACL is UNSET.
User logs in and is immediately directed to an ACL setup page, where they must provide either an IP address or range or subnet associated with their account. You can be clever and pre-populate things with their existing IP address or subnet, perhaps even looking things up at ARIN to see if their IP is in a network assigned to the company name on their account.
Once the ACL is set (or they have, despite your warnings, confirmed that they want to keep their ACL open), they can access your services.
If they try log in from elsewhere, they (and you) are notified via email (or SMS or whatever) of an attempted breach.
If they no longer have access to their ACL-listed IPs (i.e. IP renumbering due to a new upstream Internet provider and bad planning), they can call your phone support who will validate them by other means. FAX confirmation perhaps, because that's SO secure...
A user-managed ACL is not a "sure-fire" way, but it may be sufficiently effective for your needs, and it will certainly instill a sense in your customers that you have their best interests at heart.
There is no sure-fire way. That's in the nature of networks. You accept data from a remote machine and you have to trust it at least to some extend.
Take the simple username/password approach. If the usename and the passwords match, you have to trust, that they where entered by the person that the username and password was intended for. This does not fundamentally change if you require more data to be send by the client.
We upgraded WebSphere Application Server to V7 and previously working applications now get 2035 authorization errors connecting to WebSphere MQ. What is different and how do we fix it?
This is an interesting question. In V6 and earlier if the User ID field on the WAS configuration panel for WMQ was left blank, WAS would use that value (NULL or blanks) as the ID it presented to WMQ on a connection. When WMQ receives a connection request that lacks a User ID it connects using the ID associated with the WMQ channel - which is always administrative and therefore always works.
As of V7, WMQ was changed to try harder to locate a User ID to send with the connection request. In the case of Java/JMS programs, the WMQ client will present the ID of the JVM on a connection request if no other ID was provided. In your case, the app server is now providing an ID whereas before it provided none, and the ID provided is not authorized to WebSphere MQ.
The very fact that this has happened means that your queue manager is configured to accept anonymous administrative connections. The first thing to do here is to lock down all unused inbound channels (those named SYSTEM.* of type RCVR, RQSTR, CLUSRCVR and SVRCONN). Next, make sure that any channels intended for administrative access (SYSTEM.ADMIN.SVRCONN for example) authenticate connections using an exit and/or SSL. If SSL is used, insure that SSLPEER is also used to limit the certificates that can connect.
Finally, once admin access is locked down, take the ID that is supposed to e used for WAS, authorize it's group accordingly and then put that ID in the channel's MCAUSER attribute. This will prevent the app from connecting to the channel as an administrator. If you want to be sure nobody can impersonate the app, set up SSL and/or an exit, the same way you did for the administrative channels.