IBM MQ channel authentication records: what they control, and where they do not apply

IBM MQ estates tend to outlive the teams that built them, and access control is where that shows first. Channel authentication records — CHLAUTH — are IBM MQ's mechanism for exercising precise control over the access granted to connecting systems at the channel level [1]. They are worth understanding exactly, because the cases they do not cover matter as much as the ones they do.

What they control

IBM's documentation lists four functions [1]:

• Blocking connections from specific IP addresses.
• Blocking connections from specific user IDs.
• Setting the MCAUSER value — the user ID used for the channel's authority checks — for any channel connecting from a specific IP address.
• Setting the MCAUSER value for any channel that asserts a specific user ID.

The problems they solve

• Clients connecting with a blank or high-level user ID. A client that connects as a privileged user could perform actions it should never be allowed to; CHLAUTH can block it [1].
• Identities that do not exist on the server. A client may assert a user ID that is valid on its own platform but unknown or invalid on the server. A record can map it to a valid user ID [1].
• A misbehaving application. An application causing problems can be blocked by IP address until the firewall rules are updated or the application is fixed [1].
• Locking down an administration channel. A channel set up for a tool such as IBM MQ Explorer can be restricted to specific client machines by IP address [1].

Turning them on

Channel authentication records only control inbound channels once they are enabled on the queue manager, with the MQSC command `ALTER QMGR CHLAUTH(ENABLED)` [1]. On an inherited queue manager, that setting is the first thing to check: records that exist but are not enforced are documentation, not security.

Where they do not apply

The rule that surprises people: CHLAUTH rules are applied to a channel's message channel agent only when it is created in response to a new inbound connection. For a channel started locally, no CHLAUTH rules are applied [1].

For server-to-server channel pairs, that means the end where rules apply depends on which end started the channel. On a requester–sender pair started at the requester, for example, the rules apply at the sender for the initial connection and at the requester for the callback [1]. Anyone reviewing an estate's access control needs that table in front of them, not a general sense that CHLAUTH is switched on.

The wider point

Inherited middleware rarely fails because a control is missing. It fails because a control exists, is believed to apply everywhere, and does not. Knowing the exact boundary of a mechanism is most of what securing it involves.