CODEWITHSUNDEEP
javajmsibm-mq
arrehman
arrehman

Reputation: 1322

WebSphere MQ v7.1 Security User Credentials

Linux Server Box running WebSphere MQ Server v7.1:

I have created a user 'mq-user' that belongs to 'mq-users' group in Linux. Then I created a queue manager QM_TEST, and used MQSC to issue the following commands to create a queue and set up the security:

SET AUTHREC OBJTYPE(QMGR) PRINCIPAL('mq-user') AUTHADD(ALL)
SET AUTHREC PROFILE(SYSTEM.MQEXPLORER.REPLY.MODEL) OBJTYPE(QUEUE) PRINCIPAL('mq-user') AUTHADD(INQ,DSP,GET)
SET SET AUTHREC PROFILE(SYSTEM.ADMIN.COMMAND.QUEUE) OBJTYPE(QUEUE) PRINCIPAL('mq-user') AUTHADD(INQ,DSP,PUT)
DEFINE CHANNEL (TEST_CHANNEL) CHLTYPE (SVRCONN) TRPTYPE (TCP) MCAUSER('mq-user')
SET CHLAUTH(TEST_CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) MCAUSER('mq-user')
DEFINE QLOCAL (TEST_QUEUE)
SET AUTHREC PROFILE(TEST_QUEUE) OBJTYPE(QUEUE) PRINCIPAL('mq-user') AUTHADD(ALL)
DEFINE LISTENER (TEST_LISTENER) TRPTYPE (TCP) CONTROL (QMGR) PORT (1414)
START LISTENER (TEST_LISTENER)

Linux Client Box running WebSphere MQ Client v7.1 and WebSphere MQ Explorer:

I am logged in as my username (arrehman) which is not part of mq-users group. However I am able to access the queue I created above both via a Java Application and via MQ Explorer client without passing any user credentials. Why is it this way if security is in effect?

Any further details needed, please let me know. Thanks.

Upvotes: 2

Views: 5087

Answers (1)

T.Rob
T.Rob

Reputation: 31832

This line:

SET CHLAUTH(TEST_CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) MCAUSER('mq-user')

Says the following:

  • For connections requesting TEST_CHANNEL...
  • Originating from any IP address...
  • Set the MCAUSER to mq-user

In other words, enable the channel such that any connections inherit the privileges of mq-user regardless of where they originate and what identity they present. So the behavior you are seeing is the expected behavior based on the CHLAUTH rule above.

There are a few other problems with the rules as listed:

  • The use of PRINCIPAL rather than GROUP. On non-windows servers if you specify PRINCIPAL what happens is that the QMgr looks up that ID, queries its primary group and then sets authorizations based on that. So if mq-users has a primary group of staff or users that that is what gets authorized instead of mq-users and is probably not what you intended. Always use group so that you get the result you intend with setmqaut or AUTHREC.
  • Granting ALL on the QMgr makes the ID/group administrative. One of the privileges at the QMgr level is SET and any user in a group with SET rights can set, among other things, authorization control lists. So even though you only granted AUTHADD(INQ,DSP,PUT) the mq-users ID can submit PCF commands to grant all access to all objects. Only grant CONNECT and INQUIRE on the QMgr if that's all you need.
  • There's an assumption stated (in bold, actually) that you would have expected to be required to pass user credentials. Please be aware that WMQ does not validate a user ID and password if you do provide them. It accepts the ID that you assert. The password field is available to exits which can be used to validate the ID and password against, for example, LDAP or the local OS. Such an exit can be purchased from a 3rd party or written but base WMQ doesn't do anything with the password. Had you specified USERSRC(CHANNEL) on the mapping, then your ID would have been used and most likely rejected. But the rejection would have been either because it is in the mqm group (which is blocked by a default CHLAUTH rule) or because there are no AUTHREC records for the group it is in.

For more about hardening WMQ, there are a number of resources collected here. The Hardening WebSphere MQ presentation is from v7.0. Although v7.1 has new controls, the principals remain the same:

  • Authenticate the connection using IP filtering (for apps or QMgrs where the connection originates in a locked datacenter), SSL/TLS and/or an exit
  • Map the authenticated identity to an MCAUSER value by hard-coding it in the channel or by using an exit or CHLAUTH rule to dynamically set it
  • Administrative connections and high-value applications should be authenticated using TLS

Upvotes: 7

Related Questions