Access control authorization exit routine

You can provide your own access control authorization exit routine by using an exit point that DB2® provides. Alternatively, after you carefully consider several important factors, you might choose to let RACF® perform DB2 authorization checking for you.

Begin program-specific programming interface information.

Is the access control authorization exit routine right for you?

Using the RACF (Security Server for z/OS®) to perform access control is not the best choice for every customer. Consider the following points before choosing RACF to perform access control:

  • If you want the database administrators to manage security, integration with DB2 is very important. Using RACF access control provides less integration with DB2. In most of these cases, DB2 authorization provides advantages.
  • If you want security administrators to manage security, integration with the security server is more important. In most of these cases, using RACF for access control provides advantages. Furthermore, if you want a security group to define authorization and a centralized security control point, RACF access control is an excellent match.

If you change from DB2 authorization to RACF access control, you must change to RACF methods for some authorization techniques, and you must understand how DB2 and RACF work together. Expect to make the following changes when you implement RACF access control:

  • Plan to use RACF facilities (such as groups and patterns) more.
  • Plan to use patterns instead of individual item access profiles and permissions.
  • Start of changePlan to use DB2 roles, RACF groups, or both, instead of secondary authorization IDs, which are not implemented in RACF. OWNER generally must be a valid group or a DB2 role.End of change
  • Start of changePlan to use DB2 roles for BINDAGENT processing. BINDAGENT based on secondary authorizations IDs is not implemented in RACF.End of change
  • Understand how SET CURRENT SQLID works with RACF. SET CURRENT SQLID can set a qualifier, but does not change authorization.
  • Know that authorizations are not dropped when objects are dropped or renamed.
  • Be aware of the relationship between objects and revoked privileges. Packages are not invalidated when authorizations are revoked. Views are not dropped when authorizations are revoked.

How the access control authorization routine works

Your routine specifies whether the authorization checking should all be done by RACF only, or by both RACF and DB2. (Also, the routine can be called and still let all checking be performed by DB2.)

When DB2 invokes the routine, it passes three possible functions to the routine:

  • Initialization (DB2 startup)
  • Authorization check
  • Termination (DB2 shutdown)

The bulk of the work in the routine is for authorization checking. When DB2 must determine the authorization for a privilege, it invokes your routine. The routine determines the authorization for the privilege and then indicates to DB2 whether the privilege is authorized or not authorized, or whether DB2 should do its own authorization check, instead.

When you write an access control authorization routine, use the general guidelines for writing exit routines, with the following exceptions to the environment description:

  • The routine executes in non-cross-memory mode during initialization and termination (XAPLFUNC of 1 or 3).
  • During authorization checking, the routine can execute under a TCB or SRB in cross-memory or non-cross-memory mode.

Bypass of the access control authorization routine

In the following situations, the access control authorization routine is not called to check authorization:

  • The authorization ID that DB2 uses to determine access has installation SYSADM or installation SYSOPR authority (where installation SYSOPR authority is sufficient to authorize the request). This authorization check is made strictly within DB2. For example, if the execute privilege is being checked on a package, DB2 performs the check on the plan owner that this package is in. If the plan owner has installation SYSADM, the routine is not called.

    Start of changeThe RACF access control module is called for any additional authorization checks that are done as part of a process, if those checks are done on behalf of another user or role that does not have installation SYSADM or installation SYSOPR authority. An example of such a process is revoking of dependent privileges.End of change

  • DB2 security has been disabled. (You can disable DB2 security by specifying NO on the USE PROTECTION field of installation panel DSNTIPP).
  • Authorization has been cached from a prior check.
  • In a prior invocation of the exit routine, the routine indicated that it should not be called again.
  • GRANT statements.

The routine executes in the ssnmDBM1 address space of DB2.

End program-specific programming interface information.