Considerations for the access control authorization routine

You need to take additional factors into consideration when you use the access control authorization exit routine.

When DB2 cannot provide an ACEE
Sometimes DB2 cannot provide an ACEE. This happens, for example, when you do not use external security in CICS® and CICS does not pass an ACEE to the CICS attachment facility.
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.
Invalid and inoperative packages
In DB2, when a privilege that is required by a package is revoked, the package is invalidated. DB2 can automatically rebind an invalidated package if proper privileges are granted.
Automatic rebind with DB2 roles
If you execute a package that is marked invalid, DB2 will attempt to rebind it.
DB2 roles for the DYNAMICRULES(BIND) Option
The DYNAMICRULES(BIND) option provides the flexibility for you to specify the owner of a plan or a package that DB2 checks for the required authorization for dynamic SQL statements. Because RACF does not support secondary IDs, you can use DB2 roles to exploit this flexibility.
Using DB2 roles for BINDAGENT
You can bind plans and packages on the behalf of the owner by using the RACF BINDAGENT privilege through a DB2 role.
View authorization
DB2 passes specific base table information to an access control authorization exit (ACAE) routine. This information helps the routine to effectively control data access through views.
Behavior of EXPLAIN STMTCACHE with the access control authorization routine
The behavior of EXPLAIN STMTCACHE changes because in some instances the primary authorization ID replaces the statement authorization ID.
Dropping views
A view is dropped when the privilege that is required to create it is revoked.
Caching of EXECUTE on plans, packages, and routines
The results of authorization checks on the EXECUTE privilege for plans are not cached when those checks are performed by the authorization access control exit routine. The results of authorization checks on the EXECUTE privilege for packages and routines are cached if package and routine authorization caching is enabled on your system.
Implicit ownership privileges supported by RACF
When a user is the owner of a DB2 object, that user has some, but not all, implicit privileges associated with the ownership of the object. This limitation applies when the RACF access control module is used for authorization, for example.
Authorization checks for caching of dynamic SQL statements
Dynamic statements can be cached when they have passed the authorization checks if the dynamic statement caching is enabled on your system.
Resolution of user-defined functions
The create timestamp for a user-defined function must be older than the bind timestamp for the package or plan in which the user-defined function is invoked. If DB2 authorization checking is in effect, and DB2 performs an automatic rebind on a plan or package that invokes a user-defined function, any user-defined functions that are created after the original BIND or REBIND of the invoking plan or package are not candidates for execution.
Creating materialized query tables
When a materialized query table is created, a CRTVUAUTT authorization check is performed. The CRTVUAUTT check is used to determine whether the creator of a materialized query table can provide the required SELECT privileges on base tables to the owner of the materialized query table.
SNA connection and DSNR class check at the server
In some cases, an additional RACF DSNR class check for the DIST profile at the server might occur.

Parent topic: Access control authorization exit routine