IBM MQ security is layered: nothing at one layer compensates for a hole at another. A partner may present a valid TLS certificate yet lack put authority on the payment queue; an application may pass OAM checks while credentials traverse the network in cleartext if TLS is off. The MQ security model separates authentication (proving who is connecting) from authorization (deciding what that identity may do on which object), and adds channel-specific identity through MCAUSER, optional message-level protection through Advanced Message Security, and on z/OS integration with RACF or other System Authorization Facility products. Beginners encountering MQRC_NOT_AUTHORIZED reason code 2035 need this model to know whether to adjust setmqaut, CHLAUTH, CONNAUTH, or MCAUSER. This tutorial walks through each layer with comparisons, effective principal resolution, distributed versus z/OS differences at overview level, how security interacts with clusters and pub/sub, default-deny posture on modern releases, and MQSC examples that illustrate checks without replacing your platform security policy.
Authentication answers whether the connection is allowed to establish a session with the queue manager at all—password validated against OS or LDAP, certificate trusted by the queue manager keystore, or on z/OS passed to RACF for verification. Authorization happens afterward when the application or channel attempts MQOPEN, MQPUT, MQGET, or administrative commands: OAM compares the effective user ID against authorities on the queue, topic, process, or channel object. Failing authentication typically surfaces at connect time; failing authorization surfaces as 2035 on a specific operation. Both can look like application failure if logs are not read.
| Aspect | Authentication | Authorization |
|---|---|---|
| Question | Who connects? | What may they do? |
| Mechanisms | CONNAUTH, TLS client auth, OS logon | OAM, setmqaut, RACF profiles |
| Typical failure | Connection refused | 2035 on put/get |
| Object scope | Queue manager | Per queue, topic, channel |
| Tutorial follow-on | connauth, LDAP | setmqaut, queue permissions |
OAM maintains a control record for each object and principal combination—whether user app1 may put on PAYMENT.IN, whether group mqops may alter channels, whether user monitor may browse depth only. Authorities include +put, +get, +browse, +alt, +dl, +chg, +clr, and others per IBM reference. Default authority on many objects allows no access until granted explicitly on hardened systems; legacy estates may still rely on default-allow and require migration planning. setmqaut grants authority; dspmqaut displays it; revoke with remove authority options per command syntax on your release.
123456* Grant put and get to application ID on a queue: setmqaut -m QM1 -n PAYMENT.IN -t q -p app1 +put +get * Display effective authority: dspmqaut -m QM1 -n PAYMENT.IN -t q -p app1 * Channel put often uses MCAUSER - grant that ID too: setmqaut -m QM1 -n PAYMENT.IN -t q -p mqbridge +put +get
Client connections over SVRCONN pass through the listener, CONNAUTH if configured, and CHLAUTH that may block or adopt a user ID. The open user ID from the application often drives OAM for puts and gets. Inbound SDR and RCVR channels run under MCAUSER unless message context or protocol changes effective ID—partners sending with wrong credentials cause 2035 at put time even when the channel is RUNNING. Cluster RCVR and CLUSRCVR are high risk if CHLAUTH defaults ever allowed anonymous cluster senders—harden with explicit rules and TLS.
TLS encrypts data between endpoints and can authenticate the server, the client, or both with certificates. TLS does not replace OAM: an encrypted connection with a valid cert mapped to a powerful MCAUSER still needs least-privilege grants. Cipher suites, certificate expiry, and GSKit keystore maintenance belong in the TLS tutorials; here, place TLS at the perimeter layer under authentication and above raw TCP.
Cluster channels move metadata and messages; CHLAUTH and TLS apply to CLUSSDR and CLUSRCVR as with point-to-point channels. Cluster queue puts authorize against the putting application or channel identity on each hop per IBM rules. Pub/sub adds topic and subscription authorities—publish without +pub on the topic fails; subscribe without +sub fails. Clustered topic security tutorial extends this for TOPTYPE CLUS. Repository inconsistencies do not bypass OAM—a common misconception.
On Linux and Windows, OAM often uses OS user and group principals. On z/OS, RACF profiles in MQPROFILE or equivalent map queue managers and objects to RACF users and groups; the security model is the same logically but commands and profiles differ. External security managers integrate through product interfaces—operators must know which product owns the grant. Mixed estates need documentation so distributed teams do not apply setmqaut syntax to z/OS incorrectly.
AMS protects message payload with signing and encryption inside MQ—useful when multiple administrators can reach the queue manager and regulatory text requires end-to-end payload protection beyond TLS hop-by-hop. AMS is separate from OAM: you can be authorized to put while AMS policies require encrypted message format. Plan key distribution and policy objects in dedicated AMS tutorials.
Parking lot fence is firewall. Ticket and ID check at door is authentication. Security lane maps you to a passenger badge is CHLAUTH and MCAUSER. Each gate to a jet bridge requires the badge to scan for that flight—OAM per queue.
To put your toy in the shared box, you must show the teacher your name tag at the door, and the teacher must say you are allowed to use that specific box—not just any box in the room.
Given 2035 on PUT from a channel, list four IDs or rules to check in order.
Draw a diagram with five security layers for one SVRCONN client put.
Why is TLS alone insufficient for a regulated payment queue?
1. OAM handles:
2. MCAUSER is associated with:
3. TLS protects:
4. 2035 means: