How it works: Securing CICS with RACF

Resource Access Control Facility (RACF®), part of z/OS®' security server, is an IBM® provided security manager. Other external security managers (ESMs) are available and provide similar functions. The CICS® TS documentation refers only to RACF unless it is to explain the interfaces to ESMs.

For more information about the terminology used by other ESM tools, see the following:

RACF provides the following facilities:

  • The necessary functions to record information that identifies individual users who access system resources, and information that identifies the resources that require protection.
  • The facilities to define which users, or groups of users, are either permitted a level of access, or excluded from access, to the resources for which profiles are defined.
  • A method to process requests to authenticate the identity of users who are defined to RACF.
  • A method to process requests to check a user’s access authorization to resources.
  • The facilities for logging security-related events, such as authentication and authorization to the MVS System Management Facility (SMF).
The basic concepts and terms of RACF security, as they apply to CICS, are as follows:
Resource profile

Sometimes simply referred to as a profile. It defines resources to be protected.

A resource profile can protect a discrete or generic resource (for example, a single transaction CEMT or all resources starting with AB) or a resource group (for example, a named member list containing multiple resources).

Class
Also called a class profile, contains a set of resource profiles for resources of the same type. For example, transactions.
User
Also called a user profile, defines characteristics about a user.
Group
Also called a group profile, contains a set of users with the same role, for example, bank tellers. A user can be associated with one or more roles.

A group can be given a level of access to a resource profile. For example, bank tellers can run the banking transaction.

When CICS tries to perform an operation that is subject to a security check, it calls RACF. RACF checks whether the user (in the group) has at least the level of access that is required to perform that operation on the profile that represents that resource. Checks can be audited in SMF records, and failures can results in ICH408I security failure messages.

Figure 1. RACF security elements
A diagram showing RACF security elements, a user ID (user profile) in a group, a resource profile in a class, and the access level defined for the user (in the group) to the resource profile (in the class).

To learn more about RACF basics, watch the 9-minute video: IBM Security: Resource Access Control Facility (RACF) Introduction.

An example of basic concepts in RACF

The following example explains RACF concepts of user IDs, groups, and the access they have to resource profiles in classes and how these relate to CICS resources such as transactions.

The user OCTAVIA is a system administrator who should have access to run the CEMT transaction. In CICS terms, CEMT is a named resource, in this case a transaction.

In RACF, access is controlled by resource profiles in a class. A resource profile is a named resource. In this example, the resource profile is the transaction name CEMT, which can be specifically defined in the general resource class TCICSTRN.

The following RACF definitions specifies OCTAVIA has access to run the CEMT transaction:

RDEFINE TCICSTRN CEMT UACC(NONE)
PERMIT CEMT CLASS(TCICSTRN) ID(OCTAVIA) ACCESS(READ)
Understand the snippet:
  1. The order is important. First you define a resource profile in a class using the RDEFINE command. Then you permit users to access it using one or more PERMIT commands.
  2. TCICSTRN is a class that contains a set of resource profiles representing resources.
  3. The RDEFINE command explicitly uses the transaction name as the resource profile. CEMT is the resource profile that protects the transaction CEMT.
  4. UACC(NONE) means that no one has access unless they are explicitly permitted to have access. UACC other than none means that everyone needs some access for their job, such as a transaction that displays help information.
  5. The format of the RDEFINE and PERMIT commands are different, but the TCICSTRN class and the CEMT resource profile are the same in both.
  6. The user ID OCTAVIA is given READ access to the CEMT profile in the TCICSTRN class. To CICS, READ means OCTAVIA can run the CEMT transaction.

Therefore, with that definition alone, only OCTAVIA has access to run the CEMT transaction.

In most cases, OCTAVIA is one of several system administrators. Instead of issuing PERMIT commands for each of the system administrators, it is recommended to define OCTAVIA in a group of system administrators, and issue PERMIT for the whole group:

ADDGROUP ADMIN
CONNECT OCTAVIA GROUP(ADMIN)
CONNECT OLIVER GROUP(ADMIN)
Understand the snippet:
  1. The order is important. First you define a group using the ADDGROUP command. Then add users to that group using one or more CONNECT commands.
  2. ADMIN is the name of the group. It can be used in subsequent RACF commands in the same way that a user ID is used.
  3. The CONNECT commands add OCTAVIA and OLIVER to the ADMIN group.

After you have defined the ADMIN group, you can define their permission to run CEMT as follows:

RDEFINE TCICSTRN CEMT UACC(NONE)
PERMIT CEMT CLASS(TCICSTRN) ID(ADMIN) ACCESS(READ)
Understand the snippet:
  1. The PERMIT command gives READ access to the CEMT profile for all users in the ADMIN group.
  2. There is no difference in the format of the PERMIT command to define access for users or groups.

By granting the ADMIN group access to multiple resources, you can allow all system administrators access to those resources. If OCTAVIA changes jobs and stops being a system administrator, it's easy to remove her from access to all the system administrator resources by removing her from the group using the following command:

REMOVE OCTAVIA GROUP(ADMIN)

The transaction CEMT is just one of several transactions that a system administrator needs to use as part of their job. Rather than adding definitions for each of these transactions, it is simpler to define the set of transactions in a group of resources known as a member list. This is shown in the following command:

RDEFINE GCICSTRN SYSADM ADDMEM(CEMT,CESD,CETR) UACC(NONE)
PERMIT SYSADM CLASS(GCICSTRN) ID(ADMIN) ACCESS(READ)
Understand the snippet:
  1. The class name GCICSTRN has a prefix of G. This class is related to the TCICSTRN class mentioned before. Whereas TCICSTRN contained members, GCICSTRN contains member lists (resource groups). For more information about different types of resource class, see RACF classes and profiles for resources.
  2. SYSADM is the name of the member list containing the group of transactions.
  3. The ADDMEM option lists the transactions.
  4. The PERMIT command allows all the users in the ADMIN group access to run all the transaction in the SYSADM member list.

Using groups of users and groups of transactions makes subsequent administration a lot easier. For example, to add transaction CEDA to the list of transactions in the SYSADM member list, you issue the following command:

RDEFINE GCICSTRN SYSADM ADDMEM(CEDA)

This gives all the users in the ADMIN group access to run CEDA.

Each CICS region or set of CICS regions is configured to use these classes by using the Xnnn SIT parameters. For example, the transaction classes that a CICS region uses is defined by the XTRAN SIT parameter. Classes come in pairs, a general resource class that contains members and a resource group class that contains member lists. In this example, these are TCICSTRN and GCICSTRN. The SIT parameter that configures CICS to use these transaction classes is XTRAN=CICSTRN. RACF knows that it needs to add the prefixes T and G to the name specified in the SIT parameter to find the name of the general resource class and the resource group class.

In practice, after you have updated all the profiles in a class, you need to refresh the RACF cache for the changes to take effect. For instructions, see Caching of RACF classes and their profiles.