Access control authorization exit routine

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.
• Plan 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.
• Plan to use Db2 roles for BINDAGENT processing or set the AUTHEXIT_CHECK subsystem parameter DB2. BINDAGENT based on secondary authorizations IDs is not implemented in RACF.
• 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.

An alternative is to set the AUTHEXIT_CHECK system parameter to DB2. With that setting in effect, Db2 provides the ACEE of the package or plan owner to perform authorization checking during the processing of the autobind, BIND, REBIND PACKAGE, and REBIND PLAN commands and, if needed, the execution of the package or plan. Db2 also provides the ACEE of the authorization ID as determined by the DYNAMICRULES option to perform dynamic SQL authorization checking at run time. The access control authorization exit uses the ACEE for XAPLUCHK for authorization checking. The XAPLUCHK authorization ID can be a user or a group in RACF. To ensure successful authorization checks with the owner ACEE, the owner authorization ID in XAPLUCHK must be permitted access to the resources in RACF.

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.

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

• 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 database services address space (ssnmDBM1) of Db2.