Authentication

Authentication in IBM MQ answers one question before business logic touches a queue: is this connection allowed to claim this identity? Unlike authorization—which judges each put and get against object rules—authentication happens at the boundary when a client opens an SVRCONN, when certain server connections negotiate, or when administrative tools attach. A failed authentication closes the session early; a passed authentication still requires OAM grants for every sensitive object. Enterprises mix mechanisms: password repositories on small labs, LDAP for thousands of application IDs, mutual TLS for machine-to-machine partners, and on z/OS RACF validation through the System Authorization Facility. Beginners who conflate “cannot connect” with “2035 on put” waste hours tuning setmqaut when CONNAUTH or certificate trust is wrong. This tutorial defines authentication in the MQ security model, compares mechanisms, explains how AUTHINFO and CONNAUTH fit together, contrasts client and channel paths, covers identity adoption and MCAUSER handoff, documents failure symptoms, and points to dedicated tutorials for IDPWOS, LDAP, and CHLAUTH.

Authentication in the Connection Lifecycle

A typical Java or COBOL client resolves the queue manager name, opens a TCP connection to the listener port, optionally completes TLS, then issues an MQCONNX. The queue manager evaluates CONNAUTH if configured: validate password against IDPWOS or LDAP, verify OS userid, or inspect the client certificate chain. Only after success does the application MQOPEN a queue. Channel-initiated flows on RCVR and CLUSRCVR differ: partners authenticate through TLS and CHLAUTH rules; MCAUSER on the channel definition often becomes the putting identity for messages arriving from the partner. Understanding which path your integration uses determines which tutorial to read next when logon fails.

CONNAUTH and AUTHINFO Overview

ALTER QMGR CONNAUTH(MY.AUTH) tells the queue manager which AUTHINFO object governs connection authentication. DEFINE AUTHINFO with AUTHTYPE IDPWLDAP or IDPWOS sets LDAP URL, bind DN, or password file location. Changing CONNAUTH affects new connections immediately; plan maintenance windows. Multiple AUTHINFO objects can exist for different purposes—CRLLDAP for revocation is not the same as IDPWLDAP for logon—even though both use the AUTHINFO object type. See authentication info objects and CONNAUTH tutorials for MQSC detail.

1
2
3
4
5
6
7
8
DEFINE AUTHINFO('APP.LDAP') AUTHTYPE(IDPWLDAP) +
  CONNAME('ldap.corp.example.com(389)') LDAPUSER('') +
  LDAPPWD('') CHCKCLNT(OPTIONAL)
ALTER QMGR CONNAUTH(APP.LDAP)
DISPLAY QMGR CONNAUTH
* Lab password repository alternative:
DEFINE AUTHINFO('APP.OS') AUTHTYPE(IDPWOS)
ALTER QMGR CONNAUTH(APP.OS)

Identity After Authentication

A successful password login may present user PAYAPP to the queue manager. CHLAUTH on SVRCONN may MAP that ID to MCAUSER mqpayproc for all subsequent puts. Channel messages may ignore the client userid entirely and use MCAUSER from the SDR partner. Adoption settings on the queue manager control whether the asserted MQI user ID is trusted or replaced—misconfiguration here causes audits to show the wrong principal in logs while OAM checks a service account. Document the effective user ID per integration in your connection specification.

Authentication Versus Channel Rules

CHLAUTH is often described alongside authentication because operators configure both in security projects. Technically CHLAUTH performs channel access control—block, allow, map SSL peer, set MCAUSER—not password validation. A complete design uses CONNAUTH for who may log on and CHLAUTH for which channel names and partner certificates are acceptable. TLS can authenticate the server to the client and the client to the server while CONNAUTH still requires a password if policy demands dual control.

Failure Symptoms and First Steps

1. Client cannot connect—check CONNAUTH, AUTHINFO, LDAP reachability, password lockout.
2. Channel never RUNNING—check CHLAUTH and TLS before CONNAUTH.
3. Connect works, put fails 2035—switch to authorization and MCAUSER tutorials.
4. Certificate errors—verify trust store, expiry, SSLPEER rules.
5. Compare effective user with dspmqaut for that principal.

Explainer: Showing ID at Reception

Authentication is the reception desk checking your photo ID before you enter the building. Authorization is each office door requiring your badge to match that floor. You can pass reception and still be turned away at the payments office door.

Explain Like I'm Five: Authentication

Before you play in the treehouse, you tell the guard your secret password or show a special bracelet. If the guard does not believe you, you never climb up—even if you know which box you wanted.

Practice Exercises

Exercise 1

List whether each integration uses SVRCONN password, certificate, or channel MCAUSER only.

Exercise 2

Why is 2035 on MQPUT not fixed by resetting a client password?

Exercise 3

Draw connect-time steps from TCP to first MQOPEN.

Frequently Asked Questions

Test Your Knowledge