Point-to-point security in IBM MQ often fits in one mental model: can this user put and get on queue PAYMENTS.IN? Publish/subscribe adds a routing layer where messages never rest on the topic itself—they fan out to subscriber queues based on topic strings and active subscriptions. Security therefore splits into domains that mature enterprises document separately: who may publish events (PUB), who may register interest (SUB), who may administer the topic tree (TOPIC object authority), and who may read the resulting copies on destination queues (+get). Treating “MQ security” as only queue ACLs leaves holes—a team with +get on a subscriber queue but no SUB authority should not create shadow subscriptions, and a team with broad SUB but no PUB should not inject events. Auditors ask for topic catalogs showing production finance/* publishers are a small set of service IDs. This tutorial frames those domains, maps them to setmqaut and RACF patterns on distributed and z/OS, explains cluster topic propagation risks, and gives a role-based matrix beginners can copy into their standards.
When a publisher calls MQPUT against a topic, the queue manager evaluates whether that connection’s effective identity has PUB authority for the resolved topic string in the topic tree. If allowed, the pub/sub engine evaluates each subscription; for each match it performs a put to the subscription destination queue using a combination of publisher context and queue manager rules. The subscriber application then MQGETs from DEST. A failure can occur at publish time (no PUB), at routing time (no +put on DEST for the queue manager), or at consume time (no +get for the app). Three checkpoints, three different grant types—beginners who fix only one wonder why behavior changed after adding a subscription.
| Domain | What it controls | Typical principal |
|---|---|---|
| PUB on topic | Who may publish to a topic string/branch | Event producer service IDs |
| SUB on topic | Who may create or use subscriptions | Consumer apps, analytics |
| TOPIC admin | DEFINE/ALTER/DISPLAY topic objects | MQ admins only |
| DEST queue OAM | +put (QM delivery) and +get (app) | Per-subscriber service ID |
| Channel/TLS/CHLAUTH | Who may connect remotely | Network + cert policies |
Grant PUB narrowly on production branches—finance/payment/# for the payment engine, not for every developer laptop user. On distributed systems, setmqaut -t topic -n finance/payment/# -p PAYENG +pub grants publish to that subtree. Wildcard authority follows topic tree rules documented by IBM for your release—test in lab with MQPUT using a topic handle. Overly broad PUB on # or root-level topics effectively lets an identity spam every subscriber in the estate. Pair PUB grants with application design that uses versioned schemas and monitoring on unexpected publish rates.
1234setmqaut -m QM1 -t topic -n 'retail/order/#' -p ORDPROD +pub setmqaut -m QM1 -t topic -n 'retail/order/#' -p ANALYTICS +sub setmqaut -m QM1 -n SUB.ORDERS.ANALYTICS -p ANALYTICS +get +dsp * ORDPROD may publish; ANALYTICS may subscribe and get from DEST
SUB allows DEFINE SUB or dynamic subscription APIs (JMS createDurableSubscriber, etc.). A malicious SUB on hr/salary/# with destination queue EXFIL.QUEUE could copy sensitive publications to an attacker-controlled queue if DEST is writable. Restrict SUB on sensitive subtrees to known service accounts. Review DISPLAY SUB(*) periodically for unexpected destination queues. Non-durable dynamic subscriptions created at runtime inherit the connecting user’s SUB rights—treat SVRCONN MCAUSER mapping as part of SUB domain design.
DEFINE TOPIC, ALTER TOPIC, and DISPLAY TOPIC are object privileges separate from PUB/SUB on strings. Admins need them; applications usually do not. Cluster topic definitions affect routing to entire clusters—limit +crt and +chg on clus topic objects. Administrative topic objects (TOPTYPE LOCAL at branch points) shape default properties for child strings; unauthorized ALTER could enable RETAIN or alter cluster routing flags with wide blast radius.
The queue manager must put delivery copies on subscriber queues. Ensure the queue manager principal or context used for publish/subscribe delivery has +put on DEST (often granted via special profiles or default queue manager behavior per platform—verify rather than assume). Subscribers need +get and typically +dsp on DEST. Separate DEST per subscriber class so compromise of one queue does not expose all event streams. DLQ handling for undeliverable pub/sub copies follows queue manager configuration—monitor depth on subscriber queues as security-relevant backpressure signal.
Cluster topics replicate publication interest across members. PUB on one member may reach remote subscribers whose DEST queues live on other queue managers—authority must be consistent or you get asymmetric behavior (publish succeeds locally, partial fan-out). Repository channels and cluster SUB profiles add another review surface. Document which queue managers are allowed to host finance/* subscribers versus publishers only.
PUB is the key to the megaphone. SUB is the key to sign up for announcements. +get on the destination queue is the key to open your personal inbox where copies arrive. Topic admin is the key to rearrange the building’s announcement wiring. Handing one master key to everyone defeats the purpose.
Transport security does not replace topic authority. Mutual TLS proves which service connected; PUB still decides whether that service may publish to inventory/stock/low. Combine certificate DN mapping to MCAUSER with topic profiles scoped to those MCAUSER names. REST messaging APIs need the same topic and queue grants for the authenticated HTTP user.
At school, only teachers can use the loudspeaker (PUB). Only kids who signed up get a copy in their mailbox (SUB and their own desk). Only the principal can change which speakers are in which hallways (topic admin).
Design setmqaut lines for producer PUB and consumer SUB +get on one topic branch.
List three risks of granting SUB on # to a generic application ID.
Publish succeeds but subscriber queue empty—write checks for PUB, SUB, DEST +put, and +get in order.
1. PUB authority controls:
2. SUB without queue +get causes:
3. Splitting PUB and SUB domains helps:
4. Topic admin authority includes: