Working with WMQ Authentication Record

It's not the first time that I have been asked to secure a WMQ Server using the out-of-the-box security feature of WMQ.

WMQ provides from V7.1 enhanced security capabilities with the channel authentication records.

There are a lot of information available out there, I have however figure out that it may be not trivial to understand the principle.

I found very useful information from very knowledge persons at the following link:
Channel Auth Record by Morag Hudson
WMQ Security deep dive with T.Rob.

I provide here after a short description of what the feature provides and examples to help understanding the principle.

Before beginnin, the channel authentication records have to be enabled  in order to be applied by the queue manager. This is a Queue Manager property.

The security feature

So what does this feature provides?
How to define it?

Channel authentication records (CHLAUT) are defined using the MQ Explorer under the channel topic (same level as client channel) or using the scripting interface.

The aim of this feature is to allow or block access to someone. It comes from the former BlockIP  MQ support pack. It gives also the ability to map a user provided by the client application to another user.
This setting is made of rules that are defined using channel authentication records.

The principle

A client application use a client channel to connect to a queue manager. On the server a server connection channel is associated to this client channel.
It is possible to define a client authentication record that block any incomming connection from an or a range of IP address at the listener level.
If the connection is allowed, queue manager performs the following based on the CHLAUT defines:
1. resolves a rule to be applied on the connection
2. identifies what channel identity information is used for the rule
3. perform an action on the connection: allow, map a user, block

The resolution of the rule is performed using a channel profile.
The rules that are applied are those having the most specific match only. For example if there are two rules with the match criteria "SYSTEM.*" and "SYSTEM.ADMIN.*, then the SYSTEM.ADMIN.* rule will be applied for a client application using a channel "SYSTEM.ADMIN.SVRCONN". It is possible to further filter the rules to be applied by using IP address when the match criteria was SSL, Client User ID or Remote queue manager.

When the rule has been resolved, the queue manager uses the CHLAUTH definition to identify the identity information from the client connection to be used.
The identity information can be one of the following:

• SSL Distinguished Name
• Client user ID (user Id provided by the clientapplication)
• Remote queue manager
• IP Address

A special extra rule is available for blocking a connection: "Final user Id".
This rule is applied after that all other rules have been applied and after that any security Id has been called.
A typical usage of this rule is to block any user that has administration rights.

If the channel profile match multiple rules then the rules that the rule precedence order are provided here after:

1. SSL DN
2. Client User ID
3. Remote queue manager
4. IP Address

If the value of the identity information match the value defined in the CHLAUTH definition then the action of the CHLAUTH is executed: the resulting of the rule would be either to map the incoming user to another user, to block the connection or to allow the connection.
If the rule didn't block the connection, the queue manager checks if there is a special rule "block final user Id". If such rule is resolved, the rule is executed to find out if the resolved user is allowed to connect or not. The resolved user may be the incoming user provided with the connection, a user that would have been maped by a previous rule or modified by any security exit called.

Examples

I find out that it is easies to understand the principle with some example.

Example 1

Lets take the asumption that the queue manager have the following server connection channel defined:

• SYSTEM.DEF.SVRCONN
• SYSTEM.ADMIN.SVRCONN

And the client application is connecting using the client channel "SYSTEM.DEF.SVRCONN" with the user "userX".

If the following CHLAUTH is defined
SET CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP) ADDRLIST(*) USERSRC(NOACCESS)

This rule would be applied to all server connection channel beginning with "SYSTEM." that a client application would use.
The identity information used by the queue manager to apply this rule is the IP address (type ADDRESSMAP) and the it match all the IP addresses (ADDRLIST=*).
The action of this rule is to block the connection.

This means that all client application will be rejected if it tries to connect using a client channel that begins with "SYSTEM." and therefore the application connection using "SYSTEM.DEF.SVRCONN" will be refused.

Now if an MQ administrator add the following rule
SET CHLAUTH(SYSTEM.DEF.SVRCONN) TYPE(ADDRESSMAP) ADDRLIST(*) USERSRC(CHANNEL)

It match the server connection channnel "SYSTEM.DEF.SVRCONN".
As the client application is using this channel, this rule will overwrite the first one for this connection because it is a more specific matching than "SYSTEM.*".
The rule is using the IP address identity and it match all IP addressses (all client connection with this channel name).
The action is telling use the channel user as final user.
The result will be that the connection will be allowed and the user provided by the client application will be used to get the queue manager authorization.

Now if the following CHLAUT is defined:
SET CHLAUTH(SYSTEM.DEF.SVRCONN) TYPE(USERMAP) CLNTUSER(userX) USERSRC(userY)

When the client application connects, the two rules above matches.
The table provided upper shows that the client userId takes precedence on IP Address, therefore the new rule is executed.
If the client application is using the userX then the rule would map this user to userY. If this user has no access authorization to the queue manager then the connection would be refused.


Finally, if the mq adminstrator creates the following CHLAUT:
SET CHLAUTH(SYSTEM.*) TYPE(BLOCKUSER) USERLIST(*MQADMIN)

As this rule is the special extra rule that is applied after the other rules or security exit, this rule is executed after those defined above.
This rule block all user that have MQ administration right. And this rule is applied for all channels that match "SYSTEM.*". Hence if the client application is connecting with a user that has administration right or if the userY (mapped user for userX) has administration rights, the connection will be refused.

Default Configuration

From WMQ 7.1, when a new queue manager is created, the following authentication records are created:

SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST(*MQADMIN)
SET CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(NOACCESS)
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(CHANNEL)

With the first rule, any user that try to connect using a user having mq administration right will be blocked.

With the second rule, if the user doesn't have administration right, the user will be blocked if it is connecting using a channel that begins with "SYSTEM." other than "SYSTEM.ADMIN.SVRCONN".

The last rule allows a user to connect to the queue manager using the channel "SYSTEM.ADMIN.SVRCONN" if the user doesn't have the MQ administration right.