Topic Authorization

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.

OAM and Topic Profiles

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.

Common topic authority bits (distributed naming)
AuthorityAllowsTypical grantee
+pubMQPUT publish to topic stringEvent producer services
+subCreate or use subscriptions on patternConsumer applications
+crt / +chgDEFINE or ALTER TOPIC objectsMQ administrators
+dspDISPLAY TOPIC and related inquireOps read-only roles
+dltDELETE TOPICMQ admins only

setmqaut Examples (Distributed)

shell
1
2
3
4
setmqaut -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.

Topic String vs Topic Object Authority

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).

Hierarchy and Least Privilege

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.

Layered Security Model

  1. CHLAUTH and TLS — who may connect.
  2. Topic PUB — who may publish events.
  3. Topic SUB — who may register interest.
  4. Queue +put — queue manager may deliver copies to DEST.
  5. Queue +get — subscriber application may consume.

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.

Auditing and Compliance

  • Export dspmqaut output quarterly for prod/* branches.
  • Match grants to topic catalog owners in enterprise architecture.
  • Investigate DISPLAY SUB for destinations not in approved consumer list.
  • Log 2035 failures centrally—spikes may indicate credential rotation errors.

Explainer: Building Badge Colors

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).

Explain Like I'm Five: Topic Authorization

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.

Practice Exercises

Exercise 1

Write setmqaut for producer PUB and consumer SUB on prod/logistics/shipment/#.

Exercise 2

Why is granting +pub and +sub on prod/# to the same app ID risky?

Exercise 3

2035 on MQPUT to topic—list five authority checks in order.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. Topic authorization is enforced by:

  • OAM
  • FTP
  • JES only
  • COBOL compiler

2. setmqaut -t topic -n finance/# +pub grants:

  • Publish on matching branch
  • Only channel start
  • DLQ read
  • Page set alter

3. Topic auth without DEST +get causes:

  • Subscriber cannot read copies
  • Publisher always fails
  • Cluster deleted
  • TLS disabled

4. Broad grant on prod/# risk is:

  • Over-subscription and over-publish
  • Faster SSL
  • Smaller logs
  • No channels needed
Published
Read time18 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation