Db2 for z/OS security involves much more than granting privileges and controlling access to tables. Behind the scenes, security exit routines help determine who a user is, which identities and group privileges they can use, and whether they are authorized to access particular resources.
These routines are powerful, often overlooked, and potentially risky when misunderstood or improperly managed.
During a recent Virtual Db2 User Group session, Emil Kotrc, Principal Software Architect at Broadcom, explored the connection, sign-on, and authorization exit routines that play an important role in Db2 security. His presentation, Safeguarding Your Data: A Comprehensive Guide to Db2 for z/OS Security Exit Routines, examined how these exits work, how they interact with external security managers, and what administrators should understand before customizing or replacing them.
[Scroll to the bottom for the User Group Session Video!]
Here are 10 important takeaways from the session:
1. Authentication and Authorization Are Not the Same Thing
Understanding Db2 security starts with distinguishing two fundamental concepts.
Authentication establishes who a user is. Authorization determines what that user is permitted to do.
For example, a user might successfully authenticate through TSO but still lack permission to query a particular Db2 table.
Db2 security exit routines participate in both processes. Connection and sign-on exits help establish the authorization identities associated with a user, while the external access control authorization exit can help determine whether access to a resource should be permitted.
Understanding where each process occurs is essential when troubleshooting unexpected access decisions.
2. Db2 Uses Three Important Authorization Identities
Db2 relies on several authorization identifiers, and they do not always represent the same thing.
- Primary authorization ID: Typically identifies the user or process connecting to Db2.
- Secondary authorization IDs: Often represent groups associated with the primary ID, potentially providing additional privileges.
- SQL authorization ID: Can influence authorization for certain dynamic SQL operations and serve as the default qualifier in particular SQL contexts.
The connection and sign-on exits help establish these identities.
An important detail: the default exits shipped with Db2 do not necessarily populate secondary authorization IDs. Sites that need this functionality may need to assemble and link the appropriate sample routines provided by IBM.
3. Different Environments Trigger Different Security Exits
Not every Db2 connection follows the same path.
The exits invoked depend on the originating environment, such as TSO, CICS, IMS, or a distributed connection.
In a typical TSO environment, the connection exit is used without a corresponding sign-on exit. Other environments can invoke both exits, while some situations rely on the sign-on exit alone.
This distinction matters because two users accessing Db2 through different environments may experience different authorization behavior.
When investigating an access issue, understanding how the connection originated can help identify which exit routines were involved.
4. Security Exit Routines Have Significant Privileges
One of Kotrc’s strongest cautions concerned the privileges associated with security exits.
These routines execute as extensions of Db2 and reside in APF-authorized program libraries. They run with substantial authority, meaning an incorrectly written or modified exit can create risks beyond an ordinary application defect.
Organizations should treat exit routines as sensitive system components.
That means controlling who can modify them, maintaining version control, reviewing customizations carefully, and documenting their purpose and behavior.
Changes to these routines also require planning. Although the underlying library members can be modified while Db2 is running, the changes do not take effect until Db2 is restarted and the routines are reloaded.
5. Your TSO Dataset Prefix Can Affect Your SQL ID
One of the more surprising examples involved the relationship between the TSO dataset prefix and the Db2 SQL authorization ID.
In the sample connection exit, the SQL ID initially matches the primary authorization ID.
However, in a TSO environment, the exit can examine the user’s dataset prefix. If that prefix matches an eligible secondary authorization ID, the SQL ID may be changed to the dataset prefix.
This can produce confusing results when administrators expect the SQL ID to match the user’s primary ID.
Kotrc described encountering this behavior in a customer environment where the difference initially appeared unexpected.
The lesson: when investigating SQL authorization behavior, do not assume the primary authorization ID and SQL ID are always identical.
6. Internal and External Security Can Coexist, but That Creates Risks
Db2 supports both native and external authorization mechanisms.
With native Db2 security, privileges are maintained in the Db2 catalog and managed using statements such as GRANT and REVOKE.
With external security, authorization decisions can be managed through an external security manager such as RACF.
The complication is that these approaches are not necessarily mutually exclusive.
If an external security manager cannot determine whether a user has permission to access a resource, the authorization exit can return a code indicating that no decision was made. Db2 may then fall back to its internal authorization mechanisms.
This creates a potential problem for organizations migrating from native to external security.
Old privileges left behind in the Db2 catalog could still influence authorization decisions when fallback is permitted.
Kotrc emphasized the importance of understanding and controlling this behavior rather than assuming external security automatically replaces every internal authorization path.
7. A Single ZPARM Setting Can Change Whose Privileges Are Checked
An especially important consideration arises when binding Db2 packages.
During a bind operation, Db2 may need to evaluate privileges associated with both the person performing the bind and the package owner.
The AUTHEXIT_CHECK subsystem parameter affects which user’s security context is passed to the external authorization exit.
With AUTHEXIT_CHECK=PRIMARY, the exit uses the primary authorization identity’s security context. With AUTHEXIT_CHECK=DB2, it uses the context associated with the authorization ID Db2 has identified for the check.
That distinction can produce different results when the binder and package owner are different users.
Kotrc highlighted this as a particularly important consideration when migrating from native Db2 security to external authorization.
A configuration that worked as expected under native security may behave differently after migration if administrators have not examined this setting.
8. Authorization Checks Follow a Defined Sequence
The sample external authorization exit may look intimidating because of its size and assembler code, but its central authorization logic follows a structured, table-driven approach.
The routine uses privilege tables, authorization checking rules, and resource tables to determine what should be checked.
For example, when a user attempts to SELECT from a table, the exit may first evaluate implicit privileges, such as ownership.
If that does not establish authorization, it can proceed through applicable external security profiles and broader authorities.
This sequence matters for troubleshooting.
An authorization decision may depend on several possible paths, not simply whether one narrowly defined privilege exists.
Understanding the sequence helps security administrators determine why access was granted or rejected.
9. Authorization Auditing May Not Show Every Failed Check
The sample authorization exit also has an important approach to auditing.
As it evaluates possible authorization paths, it generally suppresses failure logging for intermediate checks.
If one of the checks succeeds, access can be allowed without generating audit records for every unsuccessful check along the way.
If none of the checks permits access, the exit can repeat the initial authorization check with logging enabled so the failure can be recorded according to the external security manager’s settings.
The result is more manageable audit activity, but it also means security teams should understand what their logs actually represent.
A single recorded denial does not necessarily describe every authorization path evaluated before the final decision.
10. Modern Development Tools Can Make Assembler Exits Easier to Understand
Security exits are written in assembler, which can make them difficult to review, particularly for professionals who do not work regularly with the language.
Kotrc demonstrated how a high-level assembler extension for Visual Studio Code can make the routines more approachable.
Features such as syntax highlighting, branch indicators, macro assistance, navigation tools, and code analysis can help developers follow the logic.
Branch indicators are especially useful when examining conditional paths and loops within the routines.
For organizations maintaining customized exits, these tools can make code reviews and troubleshooting more practical.
They also provide an accessible way for newer mainframe professionals to explore code that might otherwise seem difficult to navigate.
The Bottom Line: Know What Your Security Exits Are Doing
Db2 security exit routines are easy to overlook precisely because they often operate quietly in the background.
But they influence some of the most fundamental aspects of system security: user identity, group privileges, resource authorization, and the interaction between Db2 and external security managers.
Kotrc’s presentation reinforced an important message: understanding these routines is not just an assembler programming exercise. It is an essential part of maintaining a secure and predictable Db2 environment.
For organizations reviewing security controls or considering a migration from native to external authorization, the session offers a useful starting point for examining configurations, understanding authorization behavior, and identifying potential gaps.
This article recaps a Virtual Db2 User Group presentation by Emil Kotrc of Broadcom, hosted by Planet Mainframe. The session explored Db2 for z/OS connection, sign-on, and authorization exit routines, with practical examples from IBM-supplied sample code.
The Virtual Db2 User Group is presented in partnership with Data Kinetics.
0 Comments