Providing secondary authorization IDs for CICS transactions

When a thread TCB that belongs to a CICS transaction signs on to Db2®, it can provide one or more secondary authorization IDs to Db2, in addition to the primary authorization ID.

About this task

You can provide Db2 with the name of a CICS user's 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. CICS users can then be connected to, or removed from, RACF groups as required. RACF group profiles explains how users can be placed into RACF groups.

You can only provide secondary authorization IDs to Db2 for CICS transactions if you specify the GROUP option for 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). If you specify any other option for AUTHTYPE or COMAUTHTYPE, the secondary authorization ID is set to blanks. When you specify the GROUP option, you cannot choose the primary authorization ID for the thread type; it is automatically defined as the user ID of the CICS user associated with the transaction. You should base your security checking on the secondary authorization IDs instead.

To provide the names of a user's RACF groups to Db2 as secondary authorization IDs, complete the following steps:
  1. Specify SEC=YES as a system initialization parameter for the CICS region, to ensure that CICS uses RACF. If your CICS transaction profile names are defined with a prefix, also specify the system initialization parameter SECPRFX=YES or SECPRFX=prefix.
  2. If the CICS region is using MRO:
    1. Ensure that each connected CICS region is also using RACF security (SEC=YES).
    2. Specify ATTACHSEC=IDENTIFY on the CONNECTION definition for the TOR, to ensure that sign-on information is propagated from the TOR to the AORs.
  3. Replace the default Db2 sign-on exit routine DSN3@SGN. This sign-on exit routine is driven during sign-on processing. The default sign-on exit routine does not support secondary authorization IDs, so you need to replace it with the sample sign-on exit routine DSN3SSGN, which is provided with Db2, or with your own routine. DSN3SSGN is shipped in source form in the Db2 SDSNSAMP library, and you can use it as a basis for your own routine. For information about sign-on exits and about writing exit routines, see Securing Db2 in Db2 for z/OS product documentation. If the RACF list of groups option is not active, DSN3SSGN passes the name of the current connected group as the secondary authorization ID. If the RACF list of groups is active, DSN3SSGN obtains the names of all the groups to which the user is connected, and passes them to Db2 as secondary authorization IDs.
  4. Use the AUTHTYPE attribute in the DB2ENTRY definition (for entry threads), or the AUTHTYPE or COMAUTHTYPE attribute in the DB2CONN definition (for pool threads or command threads), to specify the GROUP option as the authorization type for each type of thread for which you want to provide secondary authorization IDs. If surrogate user checking is in force for the CICS region (that is, the system initialization parameter XUSER is set to YES), you need to obtain special authority to perform operations involving Db2 authorization IDs. Using surrogate security and AUTHTYPE security to control access to the authorization IDs that CICS provides to DB2 tells you how to do this.
If you have successfully completed all the steps listed above, when a CICS transaction's thread TCB signs on to Db2 with the types of thread that you have defined with the GROUP option, the CICS user's user ID will be passed to Db2 as the primary authorization ID, and the user's RACF group or list of groups will be passed to Db2 as secondary authorization IDs. If you have not successfully completed all the steps, the CICS Db2 attachment facility will issue an authorization failed message.

As an alternative to providing the names of RACF groups as secondary authorization IDs to Db2, you can write your own sign-on exit routine that sets secondary IDs for CICS transactions. See Securing Db2 in Db2 for z/OS product documentation.