Controlling access to DB2 resources in CICS

In the CICS® region, CICS users might need to perform the following DB2®-related activities:

As far as the CICS region is concerned, you can control access to all these resources and initiate security checking for them, by enabling RACF®, or an equivalent external security manager, for the CICS region, and enabling the appropriate CICS security mechanism (transaction-attach security, resource security, command security, or surrogate security). When a user tries to access protected resources, CICS calls the external security manager to perform security checking. RACF makes security checks using the CICS user's ID, which is authenticated when the user signs on to CICS. If a user does not sign on to CICS, they are given the default user ID, unless a user ID has been permanently associated with a terminal using preset security.

This topic describes how to control users' access to DB2-related resources in the CICS region, as follows:

Some of the DB2-related resources in the CICS region are subject to further security checking by DB2's security mechanisms, and this topic tells you where this applies.

For wider information about the CICS security topics discussed here, such as command and resource security in general, see the CICS RACF Security Guide.

Controlling access to DB2CONN, DB2TRAN, and DB2ENTRY resources

You can control users' access to DB2CONN, DB2TRAN, and DB2ENTRY resource definitions on several levels, by enabling different CICS security mechanisms:

Using resource security to control access to DB2ENTRY and DB2TRAN resources

The CICS resource security mechanism controls users' access to named CICS resources. For example, you can use it to protect certain resources -- such as a particular DB2ENTRY definition -- from being modified by particular users. CICS command security, which is also described in this section, can prevent users from performing certain actions on types of resources, such as "all DB2ENTRY definitions", but it cannot protect individual items within the resource type.

Because your CICS region only has one DB2CONN definition, you do not need to use resource security to protect it; you can control access to the DB2CONN definition using command security. Also, DB2TRAN definitions, for the purpose of resource security, are treated as extensions of the DB2ENTRY definition to which they refer, and are not defined for resource security in their own right. If you give a user permission to access a DB2ENTRY definition, you also give them permission to access the DB2TRAN definitions that refer to it.1 For resource security, you therefore only need to define your DB2ENTRY definitions to RACF.

When resource security is enabled for a transaction, the external security manager checks that the user ID associated with the transaction is authorized to modify the resource that is involved. "Resource security" in the CICS RACF Security Guide has more information about this process.

To protect your DB2-related resources using resource security, complete these steps:

  1. To enable RACF, or an equivalent external security manager, and make resource security available for a CICS region, specify SEC=YES as a system initialization parameter for the CICS region.
  2. In RACF, create general resource classes to contain your DB2-related resources. You need a member class and a grouping class. Unlike the RACF default resource class names for CICS, there are no IBM®-supplied default class names for DB2ENTRYs. Create your own installation-defined class names by adding new class descriptors to the installation-defined part (module ICHRRCDE) of the RACF class descriptor table (CDT). For an example of how to do this, see the IBM-supplied sample job, RRCDTE, supplied in member DFH$RACF of CICSTS31.CICS.SDFHSAMP. This gives an example of a member class called XCICSDB2, and a grouping class called ZCICSDB2. This example uses the same naming convention as the default resource class names for CICS. Do not use existing CICS class names for DB2-related resource definitions; instead, create new class names using a similar naming convention.
  3. Define profiles for your DB2ENTRY definitions in the resource classes that you have created. For example, to add a number of DB2ENTRY names to the XCICSDB2 resource class, use the RDEFINE command as follows:
     
    RDEFINE  XCICSDB2  (db2ent1, db2ent2, db2ent3.., db2entn) UACC(NONE)
                      NOTIFY(sys_admin_userid)
    Protecting DB2ENTRY resource definitions also protects access to associated DB2TRAN definitions, because a DB2TRAN is considered to be an extension to the DB2ENTRY to which it refers. You do not need to protect your DB2CONN definition using resource security.
  4. To activate resource security for your DB2-related resources, specify XDB2=name as a system initialization parameter for the CICS region, where name is the general resource class name that you defined for your DB2-related resources.
  5. Specify RESSEC=YES in the resource definition for any transactions involving DB2-related resources for which you want to enable resource security. Now, when a user tries to use one of these transactions to access one of the DB2-related resources that you have protected, RACF checks that the user ID is authorized to access that resource.
  6. Give permission to your CICS users, or groups of users, to perform appropriate actions on each DB2-related resource that you have protected. Remember that if a user has permission to perform actions on a DB2ENTRY definition, they are automatically authorized to perform the same actions on DB2TRAN definitions associated with it.

    The access that users need to perform certain actions is as follows:

    INQUIRE command
    Requires READ authority
    SET command
    Requires UPDATE authority
    CREATE command
    Requires ALTER authority
    DISCARD command
    Requires ALTER authority

    For example, you can use the PERMIT command to authorize a group of users to modify a protected DB2ENTRY, db2ent1 in class XCICSDB2, with UPDATE authority, as follows:

    PERMIT db2ent1 CLASS(XCICSDB2) ID(group1) ACCESS(UPDATE)

Using command security to control using SPI commands for DB2 resources

The CICS command security mechanism controls users' ability to issue particular SPI commands against types of DB2-related resource. For example, you can use it to control which users are allowed to issue CREATE and DISCARD commands against DB2ENTRY resource definitions. Unlike resource security, CICS command security cannot protect individual named resources; it is designed to protect types of resource. You can use command security to protect DB2CONN, DB2ENTRY, and DB2TRAN resource definitions.

When command security is enabled for a transaction, the external security manager checks that the user ID associated with the transaction is authorized to use that command to modify the type of resource that is involved. "CICS command security" in the CICS RACF Security Guide has more information about this process.

If you have both resource security and command security enabled for a particular transaction, RACF performs two security checks against the user ID. For example, if a transaction involves the user issuing a DISCARD command against DB2ENTRY definition db2ent1, RACF checks:

  1. That the user ID is authorized to issue the DISCARD command (ALTER authority) against the DB2ENTRY resource type.
  2. That the user ID is authorized to access the DB2ENTRY definition db2ent1 with ALTER authority.

To protect your DB2-related resources using command security, complete these steps:

  1. To enable RACF, or an equivalent external security manager, for a CICS region, specify SEC=YES as a system initialization parameter for the region.
  2. Add the DB2 resource names DB2CONN, DB2ENTRY, and DB2TRAN as resource identifiers in one of the IBM-supplied RACF resource classes for CICS commands, CCICSCMD or VCICSCMD. Alternatively, you can use a user-defined general resource class for your CICS commands. "CICS resources subject to command security checking" in the CICS RACF Security Guide tells you more about this. For example, you can use the REDEFINE command to define a profile named CMDSAMP in the default class VCICSCMD, and use the ADDMEM operand to specify that the DB2 resource types are to be protected by this profile, as follows:
     RDEFINE  VCICSCMD CMDSAMP UACC(NONE)
                      NOTIFY(sys_admin_userid)
                      ADDMEM(DB2CONN, DB2ENTRY, DB2TRAN)
  3. To make command security available for a CICS region:
    1. If you have used the IBM-supplied RACF resource classes CCICSCMD or VCICSCMD for CICS command profiles, specify XCMD=YES as a system initialization parameter for the region. Specifying YES means that CCICSCMD and VCICSCMD are used to build RACF's in-storage profiles.
    2. If you have used a user-defined general resource class for CICS commands, specify XCMD=user_class as a system initialization parameter for the region, where user_class is the name of the user-defined general resource class.
  4. Specify CMDSEC=YES in the resource definition for any transactions involving DB2-related resources for which you want to enable command security. Now, when a user tries to use one of these transactions to issue a command to modify one of the DB2-related resources that you have protected, RACF checks that the user ID is authorized to issue that command against that type of resource.
  5. Give permission to your CICS users, or groups of users, to issue appropriate commands against each type of DB2-related resource. For command security, you need to give separate permissions relating to the DB2TRAN resource type, as well as to the DB2ENTRY resource type. You can also protect the DB2CONN resource type (that is, the CICS region's DB2CONN definition).

    The access that users need to issue certain commands is as follows:

    INQUIRE command
    Requires READ authority
    SET command
    Requires UPDATE authority
    CREATE command
    Requires ALTER authority
    DISCARD command
    Requires ALTER authority

    For example, if you have defined the DB2 resource types in the CMDSAMP profile as in the example in Step 2, you can use the PERMIT command to authorize a group of users to issue EXEC CICS INQUIRE commands against the DB2 resource types as follows:

    PERMIT CMDSAMP CLASS(VCICSCMD) ID(operator_group) ACCESS(READ)

    Within a transaction, you can query whether a user ID has access to DB2 resource types by using the EXEC CICS QUERY RESTYPE(SPCOMMAND) command, with the RESID parameter specifying DB2CONN, DB2ENTRY, or DB2TRAN.

Using surrogate security and AUTHTYPE security to control access to authorization IDs

The CICS surrogate security and AUTHTYPE security mechanisms control users' ability to modify the authorization IDs that CICS provides to DB2. You can use it to ensure that only certain users are permitted to change these authorization IDs, which are used for DB2's own security checking. Surrogate security and AUTHTYPE security are set for the whole CICS region, and any transactions that involve changes to the authorization IDs are subject to them.

Providing authorization IDs to DB2 for the CICS region and for CICS transactions explains how to select and change these authorization IDs. To summarize, the authorization IDs that CICS provides to DB2 are set by the AUTHID, COMAUTHID, AUTHTYPE and COMAUTHTYPE attributes on DB2-related resource definitions, and by the SIGNID attribute on the DB2CONN definition for the CICS region. To change the authorization IDs, you first need authority to modify the DB2CONN and DB2ENTRY definitions, which might be protected by command security or resource security. Surrogate security provides an extra layer of protection, because it involves CICS acting on DB2's behalf to check that the user modifying the authorization ID, is permitted to act as a surrogate for the existing authorization ID that is specified in the resource definition.

True surrogate security provides security checking when a user attempts to change the SIGNID, AUTHID or COMAUTHID attributes on a DB2CONN or DB2ENTRY definition, all of which specify an authorization ID that is used when a process signs on to DB2. CICS uses the surrogate user facility of RACF to perform this checking. A surrogate user is one who has the authority to do work on behalf of another user, without knowing that other user’s password. When a user attempts to change one of the SIGNID, AUTHID or COMAUTHID attributes, CICS calls RACF to check that the user is authorized as a surrogate of the authorization ID that is presently specified on the SIGNID, AUTHID or COMAUTHID attribute.

For the AUTHTYPE and COMAUTHTYPE attributes, which give a type of authorization ID to be used rather than specifying an exact authorization ID, CICS cannot use true surrogate security. Instead, it uses a mechanism called AUTHTYPE security. When a user attempts to change one of the AUTHTYPE or COMAUTHTYPE attributes, CICS calls RACF to check that the user is authorized through a profile that you have defined for the resource definition in the RACF FACILITY general resource class. Although AUTHTYPE security is not true surrogate security, it is enabled by the same system initialization parameter, and you will probably want to use it in addition to surrogate security, so the instructions in this topic tell you how to set up both types of security.

Note that when DB2CONN and DB2ENTRY resource definitions are installed as part of a cold or initial start of CICS, if surrogate security and AUTHTYPE security are enabled, RACF makes surrogate security and AUTHTYPE security checks for the CICS region user ID. If you install DB2CONN and DB2ENTRY resource definitions in this way, ensure that the CICS region user ID is defined as a surrogate user for any authorization IDs specified in the resource definitions, and also that it is authorized through the correct profiles in the RACF FACILITY general resource class.

To implement surrogate security and AUTHTYPE security to protect the authorization IDs that CICS provides to DB2, complete the following steps:

  1. To enable RACF, or an equivalent external security manager, for a CICS region, specify SEC=YES as a system initialization parameter for the region.
  2. To activate surrogate security and AUTHTYPE security for a CICS region, specify XUSER=YES as a system initialization parameter for the region. This system initialization parameter enables both the security mechanisms. When the security mechanisms are enabled, CICS calls RACF to perform security checks whenever a transaction involves EXEC CICS SET, CREATE, and INSTALL commands that operate on the SIGNID, AUTHID, COMAUTHID, AUTHTYPE and COMAUTHTYPE attributes of DB2CONN and DB2ENTRY resource definitions. For the SIGNID, AUTHID and COMAUTHID attributes, RACF performs the surrogate security check, and for the AUTHTYPE or COMAUTHTYPE attributes, RACF performs the AUTHTYPE security check.
  3. For the purpose of surrogate security, you need to define appropriate CICS users, or groups of users, as surrogates of any authorization IDs that are specified on the SIGNID, AUTHID or COMAUTHID attributes of your DB2CONN and DB2ENTRY definitions. To define a user ID as a surrogate of an authorization ID:
    1. Create a profile for the authorization ID in the RACF SURROGAT class, with a name of the form authid.DFHINSTL, with the authorization ID defined as the owner. For example, if you have specified DB2AUTH1 as an authorization ID on a SIGNID, AUTHID or COMAUTHID attribute, use the following command to create a profile:
       RDEFINE  SURROGAT  DB2AUTH1.DFHINSTL  UACC(NONE) OWNER(DB2AUTH1)
    2. Permit appropriate CICS users to act as a surrogate for the authorization ID, by giving them READ authority to the profile you have created. For example, to permit a user with the ID CICSUSR1 to act as a surrogate for the authorization ID DB2AUTH1, and therefore to install or modify any SIGNID, AUTHID or COMAUTHID attributes that specify DB2AUTH1 as the existing authorization ID, use the following command:
      PERMIT   DB2AUTH1.DFHINSTL  CLASS(SURROGAT) ID(CICSUSR1)  ACCESS(READ)
    Repeat this process for all the authorization IDs that you have specified on SIGNID, AUTHID or COMAUTHID attributes. Also, if you might need to install DB2CONN and DB2ENTRY resource definitions containing SIGNID, AUTHID or COMAUTHID attributes as part of a cold or initial start of CICS, permit the CICS region user ID to act as a surrogate for any authorization IDs specified by those attributes. (The defaults for DB2CONN and DB2ENTRY resource definitions do not involve the AUTHID and COMAUTHID attributes. The default SIGNID for an installed DB2CONN definition is the applid of the CICS region.)
  4. For the purpose of AUTHTYPE security, you need to create a profile for each of your DB2CONN or DB2ENTRY resource definitions in the RACF FACILITY general resource class, and give appropriate CICS users, or groups of users, READ authority to the profiles. (This process imitates the true surrogate security mechanism, but does not involve the use of a specific authorization ID; instead, it protects each resource definition.) To do this:
    1. Create a profile for the DB2CONN or DB2ENTRY resource definition in the RACF FACILITY general resource class, with a name of the form DFHDB2.AUTHTYPE.authname, where authname is the name of the DB2CONN or DB2ENTRY resource definition. For example, to define a profile for a DB2CONN resource definition named DB2CONN1, use the following command:
       RDEFINE  FACILITY  DFHDB2.AUTHTYPE.DB2CONN1   UACC(NONE)
    2. Give appropriate CICS users READ authority to the profile you have created. For example, to permit a user with the ID CICSUSR2 to install or modify the AUTHTYPE or COMAUTHTYPE attributes on a DB2CONN resource definition named DB2CONN1, use the following command:
       PERMIT  DFHDB2.AUTHTYPE.DB2CONN1 CLASS(FACILITY) ID(CICSUSR2) ACCESS(READ)
    Repeat this process for each of your DB2CONN and DB2ENTRY resource definitions. Also, if you might need to install DB2CONN and DB2ENTRY resource definitions containing AUTHTYPE or COMAUTHTYPE attributes as part of a cold or initial start of CICS, give READ authority to the CICS region user ID on the profiles for those resource definitions.

Controlling access to DB2 CICS transactions

You can control users' access to

by using the CICS transaction-attach security mechanism. When transaction-attach security is enabled, RACF, or an equivalent external security manager, checks that the CICS user is authorized to run the transaction that they have requested.

To protect DB2-related transactions using transaction-attach security, follow the instructions in "Transaction security" in the CICS RACF Security Guide. The process is the same for all CICS transactions; there are no special considerations for DB2-related transactions as far as the transaction-attach security mechanism is concerned. The instructions tell you how to:

If you have defined transactions other than DSNC to issue CICS DB2 attachment facility commands and DB2 commands (for example, if you have created a separate transaction to run each command), remember to define these transactions to RACF as well.

You can now control which CICS users can use transactions that access DB2. Add the appropriate users or groups of users to the access list for the transaction profiles, with READ authority. "Defining transaction profiles to RACF" in the CICS RACF Security Guide has some recommendations about this.

For transactions that issue CICS DB2 attachment facility commands and DB2 commands, bear in mind that:

CICS DB2 attachment facility commands do not flow to DB2, so they are not subject to any further security checking. They are only protected by CICS transaction-attach security. However, DB2 commands, and CICS transactions that access DB2 to obtain data, are subject to further stages of security checking by DB2's own security mechanisms, as follows:

In addition, the CICS region itself must be authorized to connect to the DB2 subsytem.

Providing authorization IDs to DB2 for the CICS region and for CICS transactions tells you how to authorize the CICS region to connect to the DB2 subsystem, and how to provide valid authorization IDs for transactions.

Authorizing users to access resources within DB2 tells you how to grant permissions to the authorization IDs that the transactions have provided to DB2.

Related concepts
Security in a CICS DB2 environment
Providing authorization IDs to DB2 for the CICS region and for CICS transactions
Authorizing users to access resources within DB2
Multilevel security and row-level security

1.
In the case where a transaction changes the name of the DB2ENTRY with which a DB2TRAN definition is associated, a double security check is performed, to verify the user's authority to modify both the old DB2ENTRY to which the definition referred, and the new DB2ENTRY to which it will refer.

[[ Contents Previous Page | Next Page Index ]]