There are several different ways to set the credentials used by an IBM MQ server-connection (SVRCONN) channel, and of course they could all interact with each other because you might have several of them turned on in your system. This post aims to discuss all of the different mechanisms and show how they interact.
- Flowed client-side user ID
- Fixed MCAUSER on channel definition
- User ID and password
- CHLAUTH rules setting MCAUSER
- Security exit setting MCAUSER
Flowed client-side user ID
When a client attached application connects to the queue manager, the user ID under which the O/S process on the client machine is running, is flowed up to the queue manager. You can choose to use this user ID if you wish, but generally, you are advised not to trust an unauthenticated client side user ID. Luckily, pretty much everything that follows will over-ride this flowed user ID, so it is not a difficult task to choose to use something else instead.
Fixed MCAUSER on channel definition
The MCAUSER for a running channel can be set with a simple definition. There is an attribute on the SVRCONN channel definition, MCAUSER, which can provide the user ID for the channel to run with. This may be appropriate when combined with something like SSL/TLS certificates and Distinguished Name matching which ensure that this statically defined MCAUSER is only being used by connections that are allowed to connect to this channel. Using a statically defined MCAUSER without some authentication to determine who is allowed to connect to your SVRCONN channel, simply means that everyone who can reach your channel gets to use that user ID and access whatever resources that user ID can work with.
This feature can also be used as a handy trick to ensure that the client flowed ID, mentioned in the first section, is never used. If you define the MCAUSER as ‘rubbish’ then any connection that does not get the MCAUSER set appropriately by one of the next methods cannot connect.
User ID and password
If you are making use of the new IBM MQ V8 feature, Connection Authentication, which checks your user ID and password, you can set up your system so that the user ID that has been authenticated can be used as the running MCAUSER for the SVRCONN channel. You do so by setting ADOPTCTX(YES) on your Authentication Information object that configures Connection Authentication to be used.
ADOPTCTX is a queue manager wide setting and applies to all channels, but you may wish only to do this for some channels. This can be done by combining Connection Authentication with CHLAUTH rules. CHLAUTH rules can be created to determine which channels must supply a user ID and password (the use of CHCKCLNT(REQUIRED) achieves this). Additionally, you must ensure that there isn’t something else over-riding the MCAUSER, by using USERSRC(CHANNEL). For those channels where you don’t want to use the Connection Authentication feature, and you don’t want any client side user ID being adopted you can also ensure this happens with a CHLAUTH rule. You do this by setting the MCAUSER directly in a CHLAUTH rule so that any provided user ID will never be used as the MCAUSER. This shows us that CHLAUTH rules which set the MCAUSER over-ride the adopted user.
CHLAUTH rules setting MCAUSER
Channel Authentication Records (CHLAUTH for short) were added in WebSphere MQ V7.1 and allowed you to set up rules to determine whether connections were allowed to connect at all, and if they were, what MCAUSER they should use. You could make these rules using SSL/TLS Distinguished Names, or IP addresses for example, and then set the required MCAUSER for the connection which matched the rule.
When thinking specifically about MCAUSER, there were two ways to set up a rule. Either apply an MCAUSER, by using USERSRC(MAP) MCAUSER(user-id) or let the channel run with the MCAUSER that it presented by using USERSRC(CHANNEL). In this latter case, that would allow the unauthenticated client-side user ID that we mentioned above be used, or it would allow the authentication user ID which had been password checked be used (and as mentioned above you could ensure that it was mandatory to provide one).
Security exit setting MCAUSER
The above sections show that there are quite a number of different ways to assign the MCAUSER to be used by a particular running instance of a SVRCONN channel. However, if you have some more complicated algorithm that needs to be used to determine the MCAUSER to set, then you always have the fall-back to use a Security Exit. Prior to WebSphere MQ V7.1, security exits were heavily used to do the job now done by CHLAUTH rules, and they are still available to use in combination with all of the above. The security exit wins out over any of the other ways to set exits, so it can take a peek at what was set by other methods and then decide to do something different. A security exit has access to the client-side user ID, the SSL/TLS Distinguished Names, the IP address, the user ID presented with a password, and the currently chosen MCAUSER, and can then set something else if needed.
There are various ways to ensure the MCAUSER user applied to any inbound client connection is the correct one. The most important thing is to ensure that only those connections which are allowed to use the channel can do so, and thus only the resources that should be available to those connections can be used.
I was prompted to write this blog post as a result of a question asked on the List Server.