Controlling users' 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.

About this task

Controlling users' access to Db2-related CICS transactions describes how to control users' access to transactions that issues Db2 commands in the CICS address space.

When a user issues a Db2 command through a CICS transaction, they are also subject to Db2 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 1 illustrates the process.
Figure 1. 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. For information about how to grant, and revoke, Db2 permissions for authorization IDs, see Securing Db2 in Db2 for z/OS product documentation.