Providing a primary authorization ID for CICS transactions

When a CICS transaction's thread TCB signs on to DB2, it must provide a primary authorization ID to DB2. The ID that a transaction uses as its primary authorization ID is determined by an attribute in the resource definition for the thread that the transaction uses to access DB2.

About this task

This means that all transactions that use the same type of thread (either the same type of entry thread, or pool threads, or command threads) must use the same type of primary authorization ID. In each CICS region, you need to set a primary authorization ID for:
  • Each type of entry thread, using your DB2ENTRY definitions.
  • The pool threads, using your DB2CONN definition.
  • The command threads (used for the DSNC transaction), using your DB2CONN definition.

Before you start to set primary authorization IDs, ensure that you have authority to do so. As well as having authority to change your DB2CONN or DB2ENTRY definitions, 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. These operations are modifying the AUTHID, COMAUTHID, AUTHTYPE, or COMAUTHTYPE attributes on a DB2ENTRY or DB2CONN definition, and modifying the SIGNID attribute on a DB2CONN definition. Using surrogate security and AUTHTYPE security to control access to the authorization IDs that CICS provides to DB2 tells you how to grant users authority to perform these operations.

There are two methods of setting the primary authorization ID for a particular type of thread:
  1. Use the AUTHID attribute in the DB2ENTRY definition (for entry threads), or the AUTHID or COMAUTHID attribute in the DB2CONN definition (for pool threads or command threads), to specify a primary authorization ID. For example, you could define AUTHID=test2. In this case, the CICS DB2 attachment facility passes the characters TEST2 to DB2 as the primary authorization ID.

    Using AUTHID or COMAUTHID does not permit the use of secondary authorization IDs, and also is not compatible with the use of RACF, or an equivalent external security manager, for security checking in the DB2 address space.

  2. 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 instruct CICS to use an existing ID that is relevant to the transaction as the primary authorization ID. This ID can be a CICS user ID, operator ID, terminal ID, or transaction ID; or it can be an ID that you have specified in the DB2CONN definition for the CICS region.

    Using AUTHTYPE or COMAUTHTYPE is compatible with the use of RACF (or an equivalent external security manager) for security checking in the DB2 address space, if you use the USERID or GROUP options, and with the use of secondary authorization IDs, if you use the GROUP option.

The two methods of determining the primary authorization ID are mutually exclusive; you cannot specify both AUTHID and AUTHTYPE, or COMAUTHID and COMAUTHTYPE, in the same resource definition.

Remember that all IDs that you select as primary authorization IDs must be defined to RACF, or your equivalent external security manager, if the security manager is active for the DB2 subsystem. For RACF, the primary authorization IDs must be defined as RACF USER profiles, not just as RESOURCE profiles (for example, as a terminal or transaction).

Follow the instructions in DB2CONN resources and DB2ENTRY resources to set up or modify DB2CONN and DB2ENTRY definitions. If you are using the AUTHTYPE or COMAUTHTYPE attributes to determine the primary authorization ID for a type of thread, use Table 1 to identify the options that provide the required authorization ID and support the facilities you want. The key points to consider are:
  • If you want to provide secondary authorization IDs to DB2 as well as a primary authorization ID, you need to select the GROUP option. When you specify the GROUP option, your primary authorization ID is automatically defined as your CICS user ID, but you can base your security checking on the secondary authorization IDs instead.
  • If you are using RACF for security checking in the DB2 address space, you need to select either the GROUP option, or the USERID option. Only these options can pass the RACF access control environment element (ACEE) to DB2, which is required when RACF is used for security checking.
  • Think about the performance and maintenance implications of your choice of authorization ID. Selecting authorization IDs for performance and maintenance outlines these. With the USERID, OPID, TERM, TX or GROUP options, sign-on processing occurs more frequently, and maintenance also takes more time, because you need to grant permissions to a greater number of authorization IDs. With the SIGN option, or using the AUTHID attribute instead of the AUTHTYPE attribute, sign-on processing is decreased, and maintenance is less complicated. However, using standard authorization IDs makes DB2's security checking less granular.
  • Think about the accounting implications of your choice of authorization ID. The authorization ID is used in each DB2 accounting record. From an accounting viewpoint, the most detailed information is obtained if using USERID, OPID, GROUP or TERM. However, depending on the ACCOUNTREC specification, it may not be possible to account at the individual user level in any case. For more information about accounting in a CICS DB2 environment, see Accounting and monitoring in a CICS DB2 environment.

Table 1 shows the primary authorization IDs that the CICS DB2 attachment facility passes to DB2 when you select each option for the AUTHTYPE or COMAUTHTYPE attributes.

Table 1. Options available on the AUTHTYPE and COMAUTHTYPE attributes
Option Primary authorization ID passed to DB2 Supports RACF checking for DB2? Supports secondary auth IDs?
USERID User ID associated with the CICS transaction, as defined to RACF and used in CICS sign-on Yes No
OPID User's CICS operator ID, defined in the CICS segment of the RACF user profile No No
SIGN An ID you specified in the SIGNID attribute of the DB2CONN definition for the CICS region. Defaults to the applid of the CICS region Yes, when the SIGNID attribute of the DB2CONN resource matches the CICS region userid. No
TERM Terminal ID of the terminal associated with the transaction No No
TX Transaction ID No No
GROUP User's CICS RACF user ID used in CICS sign-on Yes Yes
If you are not planning to provide secondary authorization IDs for your CICS transactions, you do not need to replace the default DB2 sign-on exit routine DSN3@SGN. The default sign-on exit routine handles primary authorization IDs. However, the DB2 subsystem to which you are connecting might use a different sign-on exit routine for some other reason. If the DB2 subsystem uses the sample sign-on exit routine DSN3SSGN, you might need to make a change to DSN3SSGN, if all of the following conditions are true:
  • You have chosen an AUTHID or AUTHTYPE option other than GROUP.
  • RACF list of groups processing is active.
  • You have transactions whose primary authorization ID is not defined to RACF.
If this is the case, see Securing Db2 in Db2 for z/OS product documentationfor the change you need to make to the sample sign-on exit routine.