Authentication Feature of MQ 8

IBM MQ v8 has introduced the feature of Authentication for the first time. So far in all the earlier versions, MQ was only providing Authorization using the underling OS. In this blog, will try to cover how MQ is providing Authentication feature.

Authentication mechanism is provided for Local Connection as well as Client Connection. That is, now as a administrator we do have the option of authenticating applications connecting in Binding as well Client mode. And we also have the option of implementing this authentication using underlying OS account or LDAP.

This blog is divided into 2 parts – First part will focus on implementing Authentication using OS while the Second part will focus on using LDAP

To provide authentication, changes introduced in MQ comprises of following

• 2 new types of MQ AUTHINFO Objects introduced –> IDPW OS and IDPW LDAP
• 2 System objects, 1 each for OS and LDAP authentication, is created as part of Queue Manager
• Queue Manager by default configured to use OS based Authentication CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
• New property “Connection Authentication (CONNAUTH)” added to Queue Manager properties
• Feature introduced in Channel Authentication Records to override the Authentication behavior that is specified at Queue Manager level using AUTHINFO object

But, before proceeding to cover about the authentication mechanism introduced in MQ v8, lets take a step back to understand how MQ handled authorization prior to MQ 8. Remember there was no authentication in MQ prior to v8.

For Binding mode

1. Application running under user account “User1”, makes API call to the queue manager
2. To check the access level for the user “User1”, queue manager’s OAM retrieves user properties from the OS
3. Based on the properties of the user, queue manager’s OAM verifies the authority with the ACL

For Client Mode

1. Application running under user account “User1” on MQ Client machine, makes API call to the remote queue manager on MQ Server machine
2. The Channel Authentication records on the Queue Manager allows remote access / blocks the access based on the rules configured for the server connection channel used by application. When allowed, the Channel Authentication record applied also dynamically sets the MCAUSER (user account) to be used by queue manager for authorization
3. To check the access level for the MCAUSER value, queue manager’s OAM retrieves user properties from the OS
4. Based on the properties of the user, queue manager’s OAM verifies the authority with the ACL

Now, lets look at the authentication & authorization mechanism in MQ v8. To enable connection authentication for the QM in MQ 8, new attribute CONNAUTH (Connection Authentication) has been added to queue manager. This attribute points to a name of the AUTHINFO object of types IDPWOS or IDPWLDAP that specifies the authentication requirements.

How the ADOPTCTX property of AUTHINFO influences the Queue Manager OAM authorization is illustrated in below table –

Remember, Authorization is an existing functionality that is performed by QM’s OAM. With the introduction of Authentication layer before Authorization, the ADOPTCTX attribute of authentication determines the user id that is be passed onto the Authorization layer, as indicated by the above table.

From the authorization perspective, change introduced in MQ v8 comprises of User-based authorization in Linux / Unix environment. In the earlier versions, authorization was controlled at the group level only in Linux / Unix environment. To enable user-based authorization in Linux / Unix platform, additional attribute “-oa group | user” has been added to the crtmqm command. Default value for the -oa attribute is group.

crtmqm -oa user NEBULAQM

Note: In case, you do not want to use the Authentication feature of MQ 8 and want to disable it, run the following script command (empty space between single quotes)

ALTER QMGR CONNAUTH(‘ ‘)

REFRESH SECURITY

Authentication using OS

1. (Client Mode Connection) Application App1 running on Client machine, running under User2 account, makes Connection request to the remote queue manager on MQ Server machine (in client mode) by passing user id as User1 and its password.
2. (Binding Mode Connection) Application App2 running under User3 account, makes Connection request to the queue manager in binding mode by passing user id as User1 and its password.
3. (Only for Client connection) The Channel Authentication records on the Queue Manager allows remote access / blocks the access based on the rules configured for the server connection channel used by application. When allowed, the Channel Authentication record applied also dynamically sets the MCAUSER to User3 for use by queue manager for authorization. Also we do have the option of overriding the Connection Authentication properties of the queue manager
4. Queue Manager authenticates the application connection request by passing the User1 & its password with the corresponding OS account. Once authenticated successfully, it retrieves the User3 account property from the OS for authorization purpose by OAM [Assumption: ADOPTCTX is set to NO in the AUTHINFO object]
5. Based on the properties of the user, queue manager’s OAM verifies the authority with the ACL

Setting up Queue Manager NEBULAQM for OS based Authentication

Note: Ensure User1 & User3 account is setup on the MQ Server machine. Provide the User1 credential details to the applications to be used for connecting to queue manager

Create NEBULAQM queue manager and start the queue manager. In the script window (runmqsc NEBULAQM) of the queue manager execute the following scripts

DEFINE AUTHINFO(USER.IDPWOS) AUTHTYPE(IDPWOS) CHCKLOCL(OPTIONAL) CHCKCLNT(REQUIRED) ADOPTCTX(NO)

ALTER QMGR CONNAUTH(USER.IDPWOS)

REFRESH SECURITY

SET CHLAUTH(‘*’) TYPE(USERMAP) CLNTUSER(‘User2’) USERSRC(MAP) MCAUSER(‘User3’) CHCKCLNT(REQUIRED) ACTION(ADD)

Hope this blog provides insight into authentication mechanism. Will be following up this with LDAP based authentication shortly.