Authorizing users to access resources within DB2

Controlling access to DB2 resources in CICS tells you how to control CICS® users' access to resources that are held in the CICS address space. Once the user has accessed the DB2® address space from a CICS transaction, either to issue a DB2 command (using DSNC or a similar transaction) or to obtain data, they might need permission to perform the following actions:

Access to the DB2 resources that a CICS user needs to perform these actions is subject to security checking by DB2's security mechanisms. In DB2 Version 5 or later, you can choose to have this security checking carried out by:

The DB2 Universal Database™ for OS/390® and z/OS® Administration Guide has more information about setting up RACF to perform security checking in the DB2 address space.

If you are using RACF for some or all of the security checking in your DB2 address space, remember that CICS transactions that sign on to DB2 must provide an authorization ID by using the USERID or GROUP option on the AUTHTYPE or COMAUTHTYPE attribute in the resource definition for the thread that they use. (Providing authorization IDs to DB2 for CICS transactions describes how to do this.) CICS must also be using RACF (SEC=YES must be specified in the SIT). This is 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.

When the ACEE is passed to DB2, it is used by the DB2 exit DSNX@XAC, which determines whether RACF, or an equivalent non-IBM® external security manager, or DB2 internal security is used for security checking. DSNX@XAC is driven when a transaction whose thread has signed on to DB2, issues API requests. You can modify DSNX@XAC -- the DB2 Universal Database for OS/390 and z/OS Administration Guide has more information about this.

DB2, or the external security manager, performs security checking using the authorization IDs that the CICS transaction provided to DB2 when the thread that it was using signed on to DB2. The authorization IDs could be related to the individual CICS user (for example, the CICS user's user ID and the RACF groups to which the user is connected), or they could be related to the transaction (for example, the terminal ID or transaction ID), or they could be related to the whole CICS region. Providing authorization IDs to DB2 for the CICS region and for CICS transactions tells you how to choose these authorization IDs and provide them to DB2.

DB2, or the external security manager, checks that you have given the authorization IDs permission to perform the relevant actions in DB2. You can give the authorization IDs this permission by using GRANT statements in DB2. The DB2 Universal Database for OS/390 and z/OS Administration Guide has full information on how to grant, and revoke, DB2 permissions for authorization IDs.

This topic tells you how to control access to resources in the DB2 address space, as follows:

Controlling access to DB2 commands

For CICS users, the first security checking related to DB2 commands is performed in the CICS address space, when the user tries to access a CICS transaction that issues DB2 commands. This could be DSNC, or a user-defined transaction that invokes DFHD2CM1 and runs an individual DB2 command. Controlling access to DB2 CICS transactions describes how to control users' access to these transactions in the CICS address space.

When a user issues a DB2 command through a CICS transaction, they are also subject to DB2's own security checking, which verifies that they are authorized to DB2 to issue the command. This security checking uses the authorization IDs (primary or secondary) that the transaction has passed from CICS. Providing authorization IDs to DB2 for the CICS region and for CICS transactions tells you how to choose these authorization IDs and provide them to DB2. For transactions that use DFHD2CM1 to issue DB2 commands, the authorization IDs are set by the COMAUTHID or COMAUTHTYPE attribute of the CICS region's DB2CONN definition. For other applications that issue DB2 commands, the authorization IDs are set by the AUTHID or AUTHTYPE attribute for the CICS region's resource definition for the type of thread used by the transaction (pool thread or entry thread). These attributes control the authorization ID, or type of authorization ID, that is passed to DB2 by a transaction that is using that type of thread.

DB2 commands are therefore subject to two security checks, one in the CICS address space and one in the DB2 address space. Figure 25 illustrates the process.

Figure 25. Security mechanisms for DB2 commands
 A user at a terminal uses DSNC to enter a DB2 command (with a CRC of "-"). In the CICS address space, the input is checked to ensure the user is authorized to use the DSNC transaction. If the user has this authority, DSNC is started, and the CICS DB2 attachment facility requests a command thread into DB2. The authorization ID of the user is passed through the command thread to the general command processor in the DB2 address space. DB2 uses the authorization ID to check that the user is authorized to issue that DB2 command.

In most cases, only a limited number of users are permitted to execute DB2 commands. A convenient solution can be to specify COMAUTHTYPE(USERID) on the DB2CONN definition, which resolves to the 8-byte CICS user ID as the authorization ID in DB2. Using this method, you can give different DB2 privileges explicitly to CICS user IDs. For example, you can use GRANT DISPLAY to give specific CICS user IDs permission to use only the -DIS command.

To authorize a user to issue a DB2 command, use a GRANT command to grant DB2 command privileges to the authorization ID that the transaction has passed from CICS. The DB2 Universal Database for OS/390 and z/OS Administration Guide has full information on how to grant, and revoke, DB2 permissions for authorization IDs.

Controlling access to plans

As for DB2 commands, the first security check for users' access to plans takes place in the CICS address space, when CICS verifies that the user is permitted to access the transaction that will execute the plan. The second security check takes place in the DB2 address space, when DB2 verifies that the authorization ID provided by the transaction, is authorized to execute the plan. Figure 26 illustrates this process.

Figure 26. Security mechanisms for executing a plan
 A user at a terminal enters a transaction. In the CICS address space, the input is security checked to ensure the user is authorized to use that transaction. If the user has that authority, the transaction runs. When the application program issues a SQL call, the CICS DB2 attachment facility requests an appropriate entry thread or a pool thread into DB2. The user's authorization ID is passed to DB2 through this thread. DB2 uses the authorization ID to check that the user is allowed to execute the application plan associated with the entry thread or pool thread.

To authorize a user to execute a plan, use a GRANT command to grant DB2 command privileges to the authorization ID that the transaction has passed from CICS. The DB2 Universal Database for OS/390 and z/OS Administration Guide has full information on how to grant, and revoke, DB2 permissions for authorization IDs.

If a plan includes dynamic SQL

When using static SQL, the binder of the plan must have the privileges needed to access the data, and the authorization ID passed from CICS to DB2 need only have the privileges to execute the plan.

However, if a plan includes the use of dynamic SQL, the authorization ID passed from CICS to DB2 must possess the privileges required to access all the DB2 resources involved, both the plan and the data. For example, if you specify AUTHTYPE(USERID), the CICS user ID must be granted DB2 privileges to the DB2 resources involved in the dynamic SQL. If this user ID is also a TSO user ID, it has access to the DB2 resources directly from SPUFI, QMF™, and other utilities.

If you do not want to spend too much time granting DB2 privileges, where a transaction executes a plan that involves the use of dynamic SQL, consider using one of the following methods of supplying an authorization ID to DB2:

In each case, you can then grant DB2 privileges for DB2 resources involved in all dynamic SQL to a single ID, either the standard authorization ID from the DB2CONN definition or the AUTHID attribute, or the name of the RACF group. Providing authorization IDs to DB2 for the CICS region and for CICS transactions tells you how to provide authorization IDs by all these methods.

Related concepts
Security in a CICS DB2 environment
Controlling access to DB2 resources in CICS
Providing authorization IDs to DB2 for the CICS region and for CICS transactions
Multilevel security and row-level security
[[ Contents Previous Page | Next Page Index ]]