Topic ACLs are the concrete access control lists that IBM MQ stores for topic strings and topic objects—who may publish, subscribe, define, alter, display, or delete in each branch of the topic tree. While topic authorization is the concept, ACLs are what auditors export: dspmqaut output, DISPLAY AUTHREC reports, and RACF profile listings on z/OS. Beginners confuse ACL with “only queues”—pub/sub failures at 2035 are often missing or overly broad topic ACL entries, not missing channel definitions. This tutorial explains how topic ACLs are represented, how they differ from queue ACLs, setmqaut and AUTHREC patterns, inheritance along hierarchy, negative testing with non-admin principals, exporting ACLs for compliance, revoking access during incidents, and pairing ACL reviews with DISPLAY SUB and TOPIC catalogs.
Each ACL entry binds four ideas: the queue manager, the object profile name (topic string or object name), the object type topic, the security principal (user or group), and a bit mask of authorities. On distributed MQ, setmqaut creates these entries in the OAM repository. The effective user at runtime is usually MCAUSER on SVRCONN, the bindings OS user, or a mapped certificate identity—not the person who ran setmqaut from an admin laptop unless they connect as that same ID.
| Authority | Meaning | Who typically gets it |
|---|---|---|
| pub | Publish messages to matching topic | Producer service IDs |
| sub | Create or use subscriptions | Consumer service IDs |
| crt | DEFINE new topic objects | MQ administrators |
| chg | ALTER topic definitions | MQ administrators |
| dsp | DISPLAY topic and inquire | Ops read-only |
| dlt | DELETE topic objects | MQ admins only |
123456setmqaut -m QM1 -t topic -n 'prod/retail/order/#' -p MQ.ORDPROD +pub setmqaut -m QM1 -t topic -n 'prod/retail/order/#' -p MQ.ANALYT +sub setmqaut -m QM1 -t topic -n 'prod/retail/order/#' -p MQ.ADMIN +crt +chg +dsp +dlt dspmqaut -m QM1 -t topic -n 'prod/retail/order/#' -p MQ.ORDPROD dspmqaut -m QM1 -t topic -n 'prod/retail/order/#' -p MQ.ANALYT * Revoke: setmqaut ... -remove +pub
Script ACL changes through Git like MQSC. After deploy, verify with dspmqaut using application principals, not your admin ID. Group principals (-p MQ.GROUP.NAME) simplify LDAP role mapping—one ACL row per role instead of per developer.
Minimum consumer ACL set: +sub on topic pattern, +get and +dsp on DEST queue, and queue manager delivery context must +put to DEST (often implicit—verify on z/OS). Minimum producer set: +pub on published branch only—no SUB, no GET on unrelated queues. Topic ACL without queue GET produces subscriptions that fill DEST while the app cannot read—operators with admin GET see depth; application logs 2035.
Granting ACL on prod/finance/# allows authorities on all strings under that prefix per IBM tree matching rules. Finer grants on prod/finance/payment/# override or add to parent depending on evaluation order documented for your release—test with dspmqaut on leaf strings after parent grant. Never copy prod/# ACL to lab without changing prefix to test/#.
On z/OS, ALTER AUTHREC OBJTYPE(TOPIC) PROFILE('profile') PRINCIPAL('user') AUTHADD(PUB SUB) maps RACF profiles to MQ. Profile naming conventions differ from distributed slash strings—coordinate with security administrators. Export RACF reports alongside MQ DISPLAY for audits.
The topic ACL is the guest list on a floor of a building. It states who may speak (pub) and who may sign up for copies (sub). A separate list guards each mailbox (queue ACL) for who may open it (+get).
A topic ACL is a list of names allowed to talk about dinosaurs and to ask for dinosaur newsletters. If your name is not on the list, the computer says no—even if you can walk in the building.
Write setmqaut and dspmqaut pair for producer and consumer on one branch.
List topic ACL and queue ACL needed for durable consumer.
Why audit both pub and sub on prod/# quarterly?
1. Topic ACLs are enforced by:
2. Pub/sub needs topic ACL plus:
3. dspmqaut shows:
4. Granting +pub on prod/# is: