Topic authorization is how IBM MQ decides whether a connecting identity may publish to, subscribe to, or administer a topic string or topic object. Without explicit grants, publish and subscribe attempts fail with not authorized (reason code 2035 in many MQI scenarios)—even when the same application can put and get on ordinary queues. Topic authority is evaluated against the topic tree: grants on finance/payment/# ripple to child strings according to rules documented for your release. Beginners who copy queue OAM templates to topics often grant too little (missing SUB) or too much (PUB on # for every developer). This tutorial frames topic authorization as its own discipline: OAM profiles, setmqaut on distributed systems, RACF on z/OS at a high level, relationship to TOPIC object authority versus string authority, hierarchy planning, separation of duties between PUB and SUB, integration with channel MCAUSER and TLS identity, auditing DISPLAY AUTHREC, and ordered troubleshooting when pub/sub security fails.
The Object Authority Manager checks the effective user ID of the connection—often the MCAUSER on SVRCONN channels, the logged-in user for bindings, or a mapped certificate DN. Topic checks use object type topic with a profile name matching the topic string or object name. Authorities include pub, sub, crt, chg, dsp, dlt, and others per IBM tables. Topic authorization runs at publish and subscribe registration time, not only at connect time—so a connection can succeed while MQPUT to a topic fails moments later.
| Authority | Allows | Typical grantee |
|---|---|---|
| +pub | MQPUT publish to topic string | Event producer services |
| +sub | Create or use subscriptions on pattern | Consumer applications |
| +crt / +chg | DEFINE or ALTER TOPIC objects | MQ administrators |
| +dsp | DISPLAY TOPIC and related inquire | Ops read-only roles |
| +dlt | DELETE TOPIC | MQ admins only |
1234setmqaut -m QM1 -t topic -n 'prod/retail/order/#' -p ORDPROD +pub setmqaut -m QM1 -t topic -n 'prod/retail/order/#' -p ANALYT +sub setmqaut -m QM1 -t topic -n 'prod/retail/order/#' -p MQADMIN +crt +chg +dsp +dlt dspmqaut -m QM1 -t topic -n 'prod/retail/order/#' -p ORDPROD
Use group principals (-p mqgrp) where LDAP or AD groups map to application roles. Wildcard topic profiles must align with your hierarchy document—prod/retail/# is narrower than prod/#. Test with the same MCAUSER the application uses in production, not with your personal admin ID, or false positives hide gaps.
Applications may publish using a topic handle opened by name (TOPICOBJ) or by string. Authority resolution follows IBM rules for the path used—ensure grants cover the string actually published. DEFINE TOPIC object FIN.ORDER with TOPSTR prod/retail/order/created still requires PUB on the effective string unless object-level authority is configured on your platform. Standardize whether security profiles use strings (recommended for tree inheritance) or object names (useful when catalog names are stable but strings version).
Grant at the shallowest branch that satisfies the role: prod/finance/payment/# for payment services, not prod/#. Administrative topic objects help document where grants attach. Separate lab queue managers with test/# grants so developers never receive PUB on prod/# via mistaken copy-paste in setmqaut scripts.
Topic authorization covers steps 2 and 3. See PUB authority and SUB authority tutorials for role-specific depth; see unmanaged queues for DEST queue OAM.
Topic authorization is the color of badge you wear in each hallway of a building. Red badge may enter finance wing to speak (PUB). Blue badge may listen and receive copies (SUB). Gray badge may rewire hallways (TOPIC admin). Wearing red does not automatically let you open someone else’s mailbox (+get on DEST).
The topic tree is a school with halls. Authorization is the list of which kids may talk in which hall (publish) and which may sign up for announcements there (subscribe). The list is separate from who may open their personal mailbox.
Write setmqaut for producer PUB and consumer SUB on prod/logistics/shipment/#.
Why is granting +pub and +sub on prod/# to the same app ID risky?
2035 on MQPUT to topic—list five authority checks in order.
1. Topic authorization is enforced by:
2. setmqaut -t topic -n finance/# +pub grants:
3. Topic auth without DEST +get causes:
4. Broad grant on prod/# risk is: