Topic permissions govern who may publish events and who may subscribe to branches of the IBM MQ topic tree. Unlike a single queue where +put and +get are enough, pub/sub security spans three layers: +pub on the topic string where producers write, +sub on the branch where consumers register interest, and often +get on destination queues where copies arrive. A marketing dashboard with +sub on retail/# but no +get on its queue sees empty depth forever. A compromised ID with +pub on enterprise/# can broadcast fraudulent messages across every matching subscriber. This tutorial explains +pub and +sub in depth, wildcard and hierarchy effects, pairing with TOPIC administrative objects, managed subscriptions, cluster topic visibility, setmqaut and dspmqaut examples, comparison with queue-only security, and troubleshooting pub/sub 2035 errors for beginners.
Topic strings look like file paths: retail/order/created, finance/payment/settled. Grants use patterns with / separators; # matches multiple levels and + matches one level per IBM topic syntax rules. Granting on retail/order/# allows operations on retail/order/created and retail/order/shipped but not retail/inventory/stock unless that string also matches. Document pattern breadth in security reviews—prod/# is almost never appropriate for application service IDs.
| Permission | Allows | Typical principal |
|---|---|---|
| +pub | MQPUT to topic, publish API | Event producer services |
| +sub | MQSUB, DEFINE SUB on branch | Analytics, fan-out consumers |
| +crt | Create topic objects where applicable | Deployment automation |
| +chg +dlt +alt | Administrative topic changes | MQ administrators only |
| +dsp +inq | DISPLAY TOPIC, SUB | Operators, auditors |
1234setmqaut -m QM1 -t topic -n 'retail/order/#' -p ORDPROD +pub setmqaut -m QM1 -t topic -n 'retail/order/#' -p ORDANAL +sub setmqaut -m QM1 -n ORDANAL.DEST.Q -t queue -p ORDANAL +get +browse dspmqaut -m QM1 -t topic -n 'retail/order/#' -p ORDPROD
Notice the producer has +pub but not necessarily +sub, and the consumer has +sub plus queue +get on the destination. Publishers should not receive +sub on branches they only announce to unless they also consume. Separate IDs limit blast radius when credentials leak.
DEFINE TOPIC objects can anchor a subtree for DISPLAY and governance. Administrative topic objects may influence how authorities propagate—test dspmqaut on leaf strings after parent grants. finance/# parent grant plus finance/payment/restricted/ child deny patterns require careful ordering per IBM evaluation rules for your release. When unsure, run negative tests with a non-admin test principal.
+sub lets you register; delivery still requires the queue manager to put to a destination queue. Managed subscriptions create dynamic queue names—grant +get on predicted patterns or use service IDs with template authority. DISPLAY SUB during incidents shows unexpected subscribers—pair with topic permission audits to find shadow consumers.
+pub is permission to broadcast on a radio frequency band. +sub is permission to tune radios to that band. You still need permission to open the mailbox (+get) where recorded copies are dropped off.
Cluster topics may deliver publications across members. Topic permissions are evaluated on the queue manager where the operation runs—standardize setmqaut across cluster nodes for consumer roles. SUBSCOPE(ALL) subscriptions visible cluster-wide do not bypass per-queue-manager OAM on manual DEFINE SUB operations.
Topics are announcement boards in the hallway. +pub means you may pin notices on certain boards. +sub means you may ask the school to copy notices to your tray. You still need permission to open your tray.
Grant producer +pub on healthcare/claim/# and consumer +sub plus queue +get without +pub on consumer.
Explain risk of +pub on finance/# for one integration account.
Write dspmqaut checks after subscription create fails with 2035.
1. +pub allows:
2. +sub allows:
3. setmqaut topic type uses:
4. prod/# grant risk: