WMQ special consideration for WAS clients?

We have a WMQ - WAS/JMS client setup through server connection channels where we are trying to put in security through user Ids.

Now, we set up a local user id on the MQ box, mquserid, and left the channel's MCAUSER blank.

We thought: the id running the MQ client (WAS in our case) wasuserid, when passed to MQ will fail as it is not setup on MQ box. So we shall then set up JAAS alias (with User Id: mquserid) for the Queue connection factory on WAS which will then be passed to MQ and will allow connections.

But, we are able to connect and put messages without the JAAS alias :(

I wrote a standalone Java program t开发者_高级运维o connect to QMs and it is behaving correctly depending on the user Id I pass when obtaining connection.

Does WMQ treat WAS in a special way allowing connections without checking against its local user registry?

No, WAS is treated like any other connection.

In version 6 and earlier of WAS it will send a blank ID if the user ID on the WMQ connection is not specified. You can tell if this is the case by looking at the channel status while WAS is connected. The MCAUSER of the running channel will contain the ID that was used to connect. If the running channel status shows no MCAUSER value then WAS did not present an ID.

The other possibility is that the SVRCONN channel definition (not status) has a value such as mqm in the MCAUSER. In this case, the ID presented during the connection request is ignored. Again, check the channel status to see what ID is being used at run time or just check the SVRCONN channel definition to look for an MCAUSER value.

Now here's the kicker - if the channel's MCAUSER is blank then WMQ will accept whatever ID is presented. If no ID is presented, then the connected app or user runs as an administrator. If an app or user can be a WMQ administrator then they can do anything on the QMgr and can also remotely execute arbitrary OS commands on the server under the QMgr. Not good.

The correct answer is to set the MCAUSER on the channel to whatever value the app is supposed to connect as. At this point, the app cannot use any other ID because the channel will override it. However, anyone can connect to that channel so the next step is to authenticate the connection request. You can use an exit like BlockIP2 which is free or MQAUSX which is a commercial vendor product. BlockIP2 will filter incoming requests by IP address which may be sufficient for connections arriving from a static IP in a locked datacenter. MQAUSX will actually check the UserID and password sent during the connection request from WAS (or any client, for that matter). You can also use SSL and the channel's SSLPEER attribute to authenticate requests using X.509 certs. Note that if you use MQAUSX to validate a user ID and password either use SSL encryption with it or use both the client-side and server-side versions of the exit. Otherwise your credentials are flowed in cleartext over the wire which defeats the purpose.

Of course, if you secure the app's channel it's necessary to secure the other channels on the host such as SYSTEM.DEF.* and SYSTEM.AUTO.* or else an attacker will simply bypass the app channel.

Note that if the RCVR, RQSTR and CLUSRCVR channels do not authenticate requests or contain an MCAUSER value they also expose admin access. For example, if I want to control your QMgr and you locked the SVRCONN channels, I'd create a QMgr on my desktop, delete my SYSTEM.DEF.RECEIVER, create a new SDR channel called SYSTEM.DEF.RCVR and point it at yout QMgr. If your SYSTEM.DEF.RCVR (or S.D.RQSTR or S.D.CLUSRCVR) or any other of these channel types that you have defined lack SSL or an exit then I can connect and if they lcak an MCAUER then I can administer the QMgr anonymously and execute OS commands.

Any channel definition without an MCAUSER value allows administrative access.
Any channel without SSL/SSLPEER and/or an exit allows anonymous connections.

For more on this, please see the WMQ Hardening presentation and WMQ Security Lab documents at https://t-rob.net/links. Also, please see the articles on SSL and other WMQ security topics in the Mission:Messaging column on IBM developerWorks Tech Journal.