The System Authorization Facility (SAF) is the common front door z/OS products use to ask “is this user allowed to do this on this resource?” IBM MQ for z/OS is a SAF caller: queue opens, connects, and many administrative actions translate into SAF requests with resource class, profile name, and access level. SAF itself does not store rules—it routes to the installed external security manager (ESM), almost always RACF in IBM shops, sometimes CA ACF2 or Broadcom Top Secret. Understanding SAF separates platform security architecture from MQ object names beginners memorize in tutorials. When SAF denies access, applications see MQRC_NOT_AUTHORIZED (2035) and operators work with security teams on profiles, not on mqauth.conf files. This tutorial explains SAF’s role, the request and return code model, how MQ maps objects to SAF resources, differences from distributed OAM, auditing interfaces, performance and caching considerations at a high level, and coordinated troubleshooting with RACF administrators.
Distributed IBM MQ queue managers use the Object Authority Manager to store grants for principals and groups. z/OS enterprises standardized on SAF decades before cloud MQ; duplicating a second permission database for every subsystem would fragment audits. MQ therefore integrates with SAF so one RACF profile change can remove a user from datasets, transactions, and queues consistently. Skills you learn for CICS SAF checks transfer to MQ SAF checks—the resource class and profile naming differ, the pattern is the same.
| Component | Role | Example |
|---|---|---|
| Resource class | Category of resource | MQQUEUE (per IBM MQ doc) |
| Profile name | Identifies specific resource | qmgr.queue.name pattern |
| User ID / ACEE | Who is asking | CICS region user PAYSRV |
| Access requested | READ, UPDATE, CONTROL, ALTER | UPDATE for MQPUT |
When SAF returns authorized, MQ continues the MQI call. When SAF returns not authorized, MQ surfaces 2035 to the application or fails the command. Other reason codes appear for object missing, queue full, or syncpoint errors—do not assume every failure is SAF without reading the reason code. MQ messages and CSQ output often include the user ID and sometimes the profile name that failed. Provide that text to security administrators verbatim to speed LISTDSD lookups.
12345Application MQOPEN fails -> MQ reason 2035 (NOT_AUTHORIZED) -> MQ invoked SAF for class/profile/access -> ESM (e.g. RACF) denied -> Fix: PERMIT correct ID/GROUP on profile, REFRESH class
IBM MQ documents which SAF/RACF classes apply to queues, queue managers, channels, and commands for each release. Profile names often concatenate queue manager and object identifiers; wildcards reduce profile count but require governance. Security teams sometimes split test and production with different queue manager names in profiles even when object names match. Never copy production profiles to test without changing queue manager qualifiers—accidental production grants in test IDs are a common audit finding.
Before MQOPEN, MQCONN or equivalent attach may require SAF authority to the queue manager resource class. Distributed client connections to z/OS queue managers still end in SAF checks for the asserted user ID after CONNAUTH and TLS mapping. The full stack is: network TLS, connection authentication (CONNAUTH), channel CHLAUTH and MCAUSER, then SAF on each object operation. A failure at any layer looks like “MQ broken” to applications but has different owners.
SAF is the intercom every program uses to ask security the same way. IBM MQ speaks into the intercom; RACF (or another guard) answers yes or no. Without the intercom, every program would need its own guard with separate rulebooks.
SAF abstracts the ESM. MQ documentation primarily examples RACF because of IBM portfolio prevalence. ACF2 and Top Secret sites use the same SAF entry points with ESM-specific administration commands. Profile syntax and class names differ—MQ administrators on those systems pair with their ESM experts using IBM MQ for z/OS manuals for their product. The conceptual tutorial here still applies: profiles, access levels, user IDs, audit.
Failed accesses often generate RACF SMF type records when auditing is enabled. Successful accesses may be audited for high-risk profiles only due to volume. MQ’s own error logs supplement SMF. Incident response playbooks should list which team pulls SMF versus AMQ logs. Periodic access certification uses RACF reports filtered to MQ classes.
High-volume MQ applications open and close queues frequently. z/OS and MQ may cache SAF decisions per internal rules to reduce RACF load. Caching does not mean security is off—profile changes propagate after refresh intervals documented by IBM and RACF. After RACF maintenance, operators may need MQ refresh or application restart if accesses behave inconsistently—follow site runbooks.
SAF is how IBM MQ asks the mainframe security guard one standard question: “Can this person touch this thing?”
Write the SAF request components for a batch job MQPUT to QUEUE.PAY.IN under user PAYBAT.
Compare one distributed dspmqaut line to its SAF/RACF equivalent conceptually.
List three teams to involve when production sees sudden widespread 2035 after RACF maintenance.
1. SAF is:
2. RACF sits:
3. MQRC_NOT_AUTHORIZED is often:
4. ACF2 and Top Secret also: