Authorization IDs and ACEEs

XAPL has two authorization ID fields, XAPLUPRM (the primary authorization ID) and XAPLUCHK (the authorization ID that Db2 uses to perform the authorization). These two fields might have different values.

Begin program-specific programming interface information.The ACEE passed in XAPLACEE is that of the primary authorization ID, XAPLUPRM. If XAPLOWAC is on, the ACEE passed in XAPLACEE is that of the authorization ID that Db2 uses to perform the authorization, XAPLUCHK.

The implications of the XAPLUPRM and XAPLUCHK relationship need to be clearly understood. XAPLUCHK, the authorization ID that Db2 uses to perform authorization may be the primary authorization ID (XAPLUPRM), a secondary authorization ID, or another authorization ID such as a package owner.

If the RACF® access control module is used, the following rules apply:
  • RACF uses the ACEE of the primary authorization ID (XAPLUPRM) or the owner ID (XAPLUCHK) to perform authorization. The ACEE of the XAPLUCHK ID is used when the AUTHEXIT_CHECK subsystem parameter is set to DB2.

    To ensure successful authorization checks with the owner ACEE, the owner authorization ID in XAPLUCHK must be permitted access to the resources in RACF. If the owner is a group in RACF, you need to permit the group access to the resource associated with the connection in the RACF DSNR class. For example, if the group access is from a batch application, you can issue the following PERMIT command to grant a group access to subsystem.BATCH or subsystem.* in the DSNR class:

    PERMIT DSN.BATCH CLASS(DSNR) ID(DB2GRP) ACCESS(READ)
PERMIT DSN.* CLASS(DSNR) ID(DB2GRP) ACCESS(READ)
  • Secondary authorization IDs are not implemented in RACF. Db2 roles or RACF groups should be used instead.

Examples

The following examples show how the rules apply:

  • A package may be bound successfully by using the privileges of the binder (XAPLUPRM). Then only the EXECUTE privilege on the package is needed to execute it. If at some point this package is marked invalid (for instance, if a table it depends upon is dropped and re-created), the next execution of it will cause an autobind, which will usually fail. In this case, autobind checks the runner for the necessary authorization, but the runner does not have the required privileges for a successful rebind. However, if the owner of the package is a Db2 role, and the role has the necessary authorization, autobind will succeed. Or, if the AUTHEXIT_CHECK subsystem parameter is set to DB2, RACF checks the owner of the package (XAPLUCHK) for the necessary privileges, and autobind will succeed.
  • If the OWNER on the BIND command is based on secondary authorization IDs, RACF groups should be used instead. Secondary authorization IDs are not supported by RACF.
  • SET CURRENT SQLID can set a qualifier, but it cannot change authorization.
  • The DYNAMICRULES settings have a limited effect on which authorization ID is checked. Only the primary authorization ID and secondary IDs that are valid RACF groups for this user are considered. For dynamic statements with the DYNAMICRULES(BIND) option to work, for example, the package owner must be the primary authorization ID or one of the RACF groups of the user who executes the statements.

    However, the DYNAMICRULES settings will have the effect that you want on which authorization is checked if the authorization is based on a Db2 role or if the AUTHEXIT_CHECK subsystem parameter is set to DB2. For example, using a Db2 role, the dynamic statements with the DYNAMICRULES(BIND) option will work if a Db2 role is the owner of a plan or package or the definer of a stored procedure. If the AUTHEXIT_CHECK subsystem parameter is set to DB2, the dynamic statements with the DYNAMICRULES(BIND) option will work.

  • Start of changeThe PKLIST bind option, location-name, or collection-ID value of an asterisk (*) can defer the authorization check until run time. At runtime, the runner is checked for the necessary authorization. If the AUTHEXIT_CHECK subsystem parameter is set to DB2, the owner of the package or plan (XAPLUCHK) is checked for the necessary privileges.End of change
  • User-defined function and stored procedure authorizations involve several authorization IDs, such as implementer, definer, invoker, and so forth. Only the primary authorization ID and secondary IDs that are Db2 roles or RACF groups are considered. If the AUTHEXIT_CHECK subsystem parameter is set to DB2, the user-defined function and stored procedure authorizations that involve various authorization IDs will work.End program-specific programming interface information.