WebSphere MQ Channel Access Security Questions

Question

Consider the following queue defintinons:

SET AUTHREC OBJTYPE(QMGR) GROUP('mq-user') AUTHADD(INQ,DSP,CONNECT)

SET AUTHREC PROFILE(SYSTEM.MQEXPLORER.REPLY.MODEL) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(INQ,DSP,GET)

SET AUTHREC PROFILE(SYSTEM.ADMIN.COMMAND.QUEUE) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(INQ,DSP,PUT)

DEFINE CHANNEL ($cname) CHLTYPE (SVRCONN) TRPTYPE (TCP) MCAUSER('tcs-mq-user') REPLACE

SET CHLAUTH($cname) TYPE(ADDRESSMAP) ADDRESS(*) MCAUSER('tcs-mq-user')

1. What is the meaning of MCAUSER in both DEFINE CHANNEL and SETCHLAUTH?
2. Should tcs-mq-user belong to mq-user group?
3. Does this mean only tcs-mq-user has access to the queue manager in bindings mode? Now what if I want to give access to another user in the binding mode, should I create another pair of DEFINE CHANNEL and SET CHLAUTH commands for this user?
4. Is it possible to give the channel access to the mcs-user group?

Answer 1

OK, answers are on sale, buy one get three free today! :-) Let's take these in order...

1.A. The channel's MCAUSER value is the ID against which authorization checks are performed. If the DEFINE CHL() CHLTYPE(SVRCONN) leaves MCAUSER blank, then clients connecting can specify the ID that they wish to connect as. If they fail to specify, WMQ client attempts to use the ID of the client user as seen from the workstation where the client app is running and present that. Setting MCAUSER in the channel definition prevents the client app from specifying the value.

1.B. The MCAUSER in an ADDRESSMAP rule is used to map the MCAUSER based on some identifying criteria. It says "IF a connection arrives on this channel with a specified IP address | User Name | SSL Distinguished Name THEN use this ID as the MCAUSER AND allow the channel to run if no other rules block it.

The recommendation if a CHLAUTH mapping rule is used is usually to set the channel's MCAUSER to a value that cannot possibly be a user ID so it will not run. This way the channel defaults to a secure state unless a CHLAUTH rule overrides the MCAUSER to a value intended to allow access. The quintessential value for MCAUSER used to be nobody until Mark Taylor, WMQ Strategist from the Hursley Lab, suggested using a value that can not be an actual user ID, such as no#body. As of WMQ V7.1 the value *NOACCESS is a reserved work and what I'm using in the conference presentations these days.

2. Yes. WMQ authorizes based on groups. The standard advice is to deconstruct your security requirements into roles like 'admin', 'app1', 'app2', 'monitoring', 'anonymous', etc. Then for each of these roles that requires access, create a group.

But access requests come from principals that are uniquely identified, not from groups. The authorization check requires an account to check against so the MCAUSER in the channel is an ID while the authorization rights are stored by group. To associate a user with the correct rights, enroll them in the right group.

This is standard UNIX authorization model that supports separation of duties. Resource admins (the WMQ administrator) authorize groups. Account admins enroll user IDs in groups. It takes both groups to provide access. In the real world, most shops do not utilize the separation of duties feature but in a significant cases it is mandatory.

3. Sort of. A default QMgr at V7.1 or higher won't allow any remote connections at all. This is because when created it has no AUTHREC rules so non-admins are not granted access. Admins are blocked from remote access by the default CHLAUTH rule.

With the rules specified, anyone can successfully connect to the $cname channel and will be authorized as tcs-mq-user. If you want them to connect as a different user ID with the same privileges then you would need to add that ID to the mq-user group and then set the channel up to map the IDs presented. If you wanted to enforce which ID someone connected as you'd have to specify the mapping by IP address or, better yet, based on their certificate distinguished name.

4. No. As noted in #2 above, access requests are always made by principals, not by groups. The whole point of CHLAUTH rules, MCAUSER and distinguished name mapping is to resolve the user ID that the channel uses for authorization checks. The channel definition's MCAUSER is a security control in that ID resolution process and so it operates on the ID and not on the group.

If you haven't already found the site, you might find T-Rob.net useful. In particular, on the Links page I have posted all the WMQ Security presentations from the conferences as well as links to my and other authors' articles.