Using resource security to control access to DB2ENTRY and DB2TRAN resource definitions

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.

About this task

CICS command security 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. (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.) 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 has more information about this process.

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

Procedure

  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 CICSTS53.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)

Results