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.

Before you begin

Begin program-specific programming interface information.

An alternative is to set the AUTHEXIT_CHECK system parameter to DB2. With that setting in effect, Db2 provides the ACEE of the package owner to perform authorization checking when processing autobinds or BIND and REBIND commands. Db2 provides the ACEE of the authorization ID as determined by the DYNAMICRULES option to perform dynamic SQL authorization checking. 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. See AUTH EXIT CHECK (AUTHEXIT_CHECK subsystem parameter).End program-specific programming interface information.

About this task

RACF provides support for BINDAGENT through Db2 roles. To use BINDAGENT, you must specify a role, instead of a secondary ID, as the owner of a plan or package and perform the BIND task within a trusted context. If you set field 1 (RESTART or DEFER) to DEFER and set field 2 (objects to restart or defer) to ALL in installation panel DSNTIPS, you cannot use trusted connections.

For this task, suppose you want role ROLEOWNER to own package COLLECTION01.PACKAGE01, but will have role ROLEBINDAGENT perform the BIND on behalf of role ROLEOWNER.

Procedure

To have ROLEBINDAGENT perform the BIND on behalf of ROLEOWNER:

  1. Create role ROLEOWNER and role ROLEBINDAGENT.
    Make sure that the ROLEOWNER role is the owner of the package and that the binder is associated with the ROLEBINDAGENT role and will bind the package.
  2. Create trusted context CTX1 with the WITH ROLE AS OBJECT OWNER AND QUALIFIER clause.
    Specify ROLEBINDAGENT as the default role and set JOB=BINDPKG (which is the bind job name) and SYSTEM AUTHID=UBINDER (which is the binder's userid).
  3. Create a RACF profile V91A.ROLEOWNER.BINDAGENT to control BINDAGENT access
  4. Permit role ROLEBINDAGENT access to profile V91A.ROLEOWNER.BINDAGENT by issuing a RACF PERMIT command: 
    PERMIT  V91A.ROLEOWNER.BINDAGENT ID(*) +            
		WHEN(CRITERIA(SQLROLE('ROLEBINDAGENT'))) CL(MDSNSM)
  5. Set up appropriate RACF profiles and give role ROLEOWNER the BINDADD and CREATE IN privileges on the package collection: 
    PERMIT V91A.BINDADD ID(*) CL(MDSNSM) + 
		WHEN(CRITERIA(SQLROLE('ROLEOWNER')))
    PERMIT V91A.COLLECTION01.CREATEIN ID(*) CL(MDSNCL) + 
		WHEN(CRITERIA(SQLROLE('ROLEOWNER')))
  6. Permit role ROLEOWNER all the required privileges for executing SQL statements in the application as shown in the following example: 
    PERMIT V91A.USRT007.TABL01.SELECT ID(*) CL(MDSNTB) + 
		WHEN(CRITERIA(SQLROLE('ROLEOWNER')))
  7. Have UBINDER submit bind job BINDPKG that will run in trusted context CTX1 with role ROLEBINDAGENT and perform the BIND on behalf of role ROLEOWNER: 
    BIND PACKAGE(COLLECTION01) MEMBER(PACKAGE01) ACTION(REP) OWNER(ROLEOWNER)

    RACF performs the BINDAGENT check on binder UBINDER, its role ROLEBINDAGENT, and its RACF groups. It then perform all the remaining checks on role ROLEOWNER and allows the BIND command to complete.End program-specific programming interface information.