Providing authorization IDs to Db2 for CICS transactions

So that CICS can pass authorization IDs to Db2®, CICS must be using RACF; SEC=YES must be specified in the SIT. This is because CICS needs to pass a RACF access control environment element (ACEE) to Db2.

About this task

When a CICS transaction's thread TCB signs on to Db2 and goes through the Db2 sign-on processing, it can provide:
  • A primary authorization ID. For CICS transactions, you can choose the primary authorization ID. It can be the user ID or operator ID of the CICS user, or a terminal ID, or a transaction ID; or it can be an ID that you have specified. The ID that is used as the primary authorization ID is determined by attributes in the DB2ENTRY definition (for entry threads), or in the DB2CONN definition (for pool threads and command threads). Providing a primary authorization ID for CICS transactions tells you how to choose the primary authorization ID for a CICS transaction.
  • One or more secondary authorization IDs. You can use the name of a RACF group, or list of groups, as secondary authorization IDs. This has the advantage that you can grant Db2 privileges and authority to RACF groups, rather than to each individual CICS user. To use secondary authorization IDs, use the AUTHTYPE attribute in the DB2ENTRY definition (for entry threads), or the AUTHTYPE or COMAUTHTYPE attributes in the DB2CONN definition (for pool threads or command threads), to specify the GROUP option. You also need to replace the default Db2 sign-on exit routine DSN3@SGN, because the default routine does not pass secondary authorization IDs to Db2. When you specify the GROUP option, the primary authorization ID is automatically defined as the user ID of the CICS user associated with the transaction. Providing secondary authorization IDs for CICS transactions tells you how to set up and use secondary authorization IDs.
A key consideration for choosing the authorization IDs that CICS transactions provide to Db2 is the security mechanism that you have chosen for security checking in the Db2 address space. This security checking covers access to Db2 commands, plans, and dynamic SQL. You can choose to have this security checking carried out by:
  • Db2 internal security.
  • RACF, or an equivalent external security manager.
  • Partly Db2, and partly RACF.
If you are using RACF for some or all of the security checking in your Db2 address space, CICS transactions that sign on to Db2 must provide an authorization ID by one of the following methods:
  • Specify AUTHTYPE(USERID) or COMAUTHTYPE(USERID) in the appropriate definition for the thread (DB2ENTRY or DB2CONN), to provide the user ID of the CICS user associated with the transaction to Db2 as the primary authorization ID.
  • Specify AUTHTYPE(GROUP) or COMAUTHTYPE(GROUP) in the appropriate definition for the thread (DB2ENTRY or DB2CONN), to provide the user ID of the CICS user associated with the transaction to Db2 as the primary authorization ID, and the name of a RACF group or list of groups as the secondary authorization IDs.
  • Specify AUTHTYPE(SIGN) in the appropriate definition for the thread (DB2ENTRY or DB2CONN), and specify the CICS region user ID in the SIGNID attribute of the DB2CONN, to provide the CICS region ID to Db2 as the primary authorization ID.

Note that if the RACF access control environment element (ACEE) in the CICS region is changed in a way that affects the CICS Db2 attachment facility, Db2 is not aware of the change until a sign-on occurs. You can use the CEMT or EXEC CICS SET DB2CONN SECURITY(REBUILD) command to cause the CICS Db2 attachment facility to issue a Db2 sign-on the next time a thread is reused, or when a thread is built on an already signed-on TCB. This ensures that Db2 is made aware of the security change.