For the purposes of security, DB2® uses the term "process" to represent all forms of access to data, either by users interacting directly with DB2, or by users interacting with DB2 by way of other programs, including CICS®. A process that connects to or signs on to DB2 must provide one or more DB2 short identifiers, called authorization IDs, that can be used for security checking in the DB2 address space. Every process must provide a primary authorization ID, and it can optionally provide one or more secondary authorization IDs. DB2 privileges and authority can be granted to either primary or secondary authorization IDs. For example, users can create a table using their secondary authorization ID. The table is then owned by that secondary authorization ID. Any other user that provides DB2 with the same secondary authorization ID has associated privileges over the table. To take privileges away from a user, the administrator can simply disconnect the user from that authorization ID.
CICS has two types of process that need to provide DB2 with authorization IDs:
During connection processing and sign-on processing, DB2 sets the primary and secondary authorization IDs for the process to use in the DB2 address space. By default, DB2 uses the authorization IDs that the process has provided. However, both connection processing and sign-on processing involve exit routines, and these exit routines allow you to influence the setting of the primary and secondary authorization IDs. DB2 has a default connection exit routine and a default sign-on exit routine. You can replace these with your own exit routines, and a sample connection exit routine and sign-on exit routine are supplied with DB2 to assist you with this.
Providing authorization IDs to DB2 for a CICS region tells you how to set up authorization IDs for a CICS region to connect to DB2.
Providing authorization IDs to DB2 for CICS transactions tells you how to set up authorization IDs for CICS transactions.
When the CICS DB2 attachment facility creates the overall connection between a CICS region and DB2, the process goes through DB2's connection processing. The CICS region can provide:
The connection type that CICS requests from DB2 is single address space subsystem (SASS). For the connection between a CICS region and DB2, you cannot choose the primary authorization ID that is initially passed to DB2's connection processing. The ID that is passed to DB2 as the primary authorization ID for the CICS region is one of the following:
The user ID that a CICS region might use must be defined to RACF, or your equivalent external security manager, if the external security manager is active. Define the user ID to RACF as a USER profile. It is not sufficient to define it as a RESOURCE profile.
Once you have defined the CICS region's user ID to RACF, permit it to access DB2, as follows:
RDEFINE DSNR (DB2A.SASS) OWNER(DB2OWNER)
PERMIT DB2A.SASS CLASS(DSNR) ID(CICSHA11) ACCESS(READ)
DB2's connection exit routine takes the primary authorization ID (the user ID) provided by the CICS region, and sets it as the primary ID for the CICS region in DB2. The default DB2 connection exit routine DSN3@ATH, and the sample DB2 connection exit routine DSN3SATH, both behave in this way. It is possible to change the primary ID that DB2 sets, by writing your own connection exit routine. The DB2 Universal Database™ for OS/390® and z/OS® Administration Guide has more information about the sample connection exit routine and about writing exit routines. However, you might find it more straightforward to provide secondary authorization IDs for the CICS region, and grant permissions to the CICS region based on these, rather than on the primary authorization ID.
When a CICS region connects to DB2, it can provide one or more secondary authorization IDs to DB2, in addition to the primary authorization ID. You can use the name of the RACF group, or list of groups, to which the CICS region is connected, as secondary authorization IDs. This enables you to grant DB2 privileges and authority to RACF groups, and then connect multiple CICS regions to the same groups, instead of granting DB2 privileges to all the possible primary authorization IDs for each CICS region.
To provide the name of the RACF group, or list of groups, to which a CICS region is connected, to DB2 as secondary authorization IDs, complete the following steps:
When the CICS region connects to DB2, the sample connection exit routine sets the CICS region's primary authorization ID (the region's user ID) as the primary ID, and sets the names of the RACF groups to which the CICS region is connected, as secondary IDs.
As an alternative to providing the names of RACF groups as secondary authorization IDs to DB2, you can write your own connection exit routine that sets secondary IDs for the CICS region. The DB2 Universal Database for OS/390 and z/OS Administration Guide has information about writing connection exit routines.
When a CICS transaction's thread TCB signs on to DB2 and goes through DB2's sign-on processing, it can provide:
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. In DB2 Version 5 or later, you can choose to have this security checking carried out by:
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:
CICS must also be using RACF (SEC=YES must be specified in the SIT). These conditions apply because when RACF is used for security checking in the DB2 address space, CICS needs to pass a RACF access control environment element (ACEE) to DB2. CICS can only produce an ACEE if it has RACF active, and only threads defined with the USERID or GROUP option can pass the ACEE to DB2.
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.
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. 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:
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 authorization IDs 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:
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.
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 the CICS Resource Definition Guide and "DB2 entry definitions" 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 3 to identify the options that provide the desired authorization ID and support the facilities you want. The key points to consider are:
Table 3 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.
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 | No | 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:
If this is the case, the DB2 Universal Database for OS/390 and z/OS Administration Guide tells you the change you need to make to the sample sign-on exit routine.
When a CICS transaction's thread TCB signs on to DB2, it can provide one or more secondary authorization IDs to DB2, in addition to the primary authorization ID. 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" in the CICS RACF Security Guide 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:
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. The DB2 Universal Database for OS/390 and z/OS Administration Guide has information about writing sign-on exit routines.