CICS security administration covers the tasks and controls used to protect CICS resources and data: who can sign on, which transactions and programs they can run, and which files or datasets they can access. On z/OS, this is usually done by integrating CICS with RACF (Resource Access Control Facility). RACF holds user and group profiles and resource profiles for transactions, programs, and files. CICS calls RACF at sign-on (to authenticate) and when a user attempts a protected operation (to authorize). This page explains the main concepts: sign-on/sign-off, RACF resource classes, how authorization works, and how security events are logged and audited.
Imagine a building with many rooms and a guard at the door. The guard checks your name and badge (sign-on). Once you are in, the guard decides which rooms you can enter (transactions, programs, files). The guard has a list of who is allowed into which room (RACF profiles). Security administration is the job of updating that list: adding people, changing who can go where, and writing down who tried to go where (logging). In CICS, the "guard" is CICS and RACF working together.
Sign-on is how a user identifies themselves to CICS. The user (or the application on their behalf) supplies a user ID and usually a password. CICS passes these to RACF (or the configured security manager) for authentication. If authentication succeeds, CICS establishes a security context for the task or session: subsequent requests are checked against that identity. Until sign-on, the user may only be allowed to run a restricted set of transactions (e.g. the sign-on transaction). Sign-off ends the session and clears the security context. In many installations, sign-on is required before running sensitive transactions or accessing protected resources.
RACF uses resource classes to group similar types of resources. For CICS, the main classes are:
| Class | Purpose |
|---|---|
| CICSTRANS | Protects transaction IDs; controls who can run which transactions |
| CICSPROG | Protects program names; controls who can execute or link to which programs |
| CICSFILE | Protects file and dataset resources used by CICS |
| CICSDATA | Protects specific datasets |
| CICSSYS | Protects system and administrative functions |
Each class has profiles that name a resource (e.g. a transaction ID or program name) and define which users or groups have access (e.g. READ, UPDATE) and under what conditions. Security administrators create and maintain these profiles. CICS performs a RACF check when, for example, a user runs a transaction (CICSTRANS), when a program is invoked (CICSPROG), or when a file is opened (CICSFILE). If the user is not permitted, RACF denies the request and CICS can log the failure and return an error to the application.
When a user attempts a protected operation (e.g. running transaction CUST, linking to program PROG1, or accessing file ACCTFILE), CICS builds a request that includes the resource type and name and the user\'s identity (from the sign-on context). CICS calls RACF with this information. RACF looks up the relevant profile (e.g. CICSTRANS profile for CUST) and checks whether the user (or a group the user belongs to) has the required access. RACF returns permit or deny. If access is denied, RACF can log the event (e.g. ICH408I) and CICS may return a security-related response code to the application. The exact behavior (which resources are protected, which operations are checked) is determined by CICS and RACF configuration.
RACF user profiles define individual users: user ID, password (or pointer to password), and attributes. Group profiles collect users (e.g. CICSAPP, CICSADMIN) so that access can be granted by group rather than by individual. Resource profiles often grant access to a group (e.g. CICSTRANS profile for Txn1 permits group CICSAPP). Adding a user to a group then gives them the access that the group has. This simplifies administration: instead of updating many user profiles when access policy changes, you update the group or the resource profile.
Security-relevant events are logged so that administrators can audit access and investigate failures. RACF can write SMF records and issue messages (e.g. ICH408I for authorization failures). CICS can also log sign-on/sign-off and resource access to SMF or to CICS-specific logs. Auditing and compliance often require that who accessed what and when (and whether access was granted or denied) be recorded. Security administration includes ensuring that logging is enabled for the right events and that logs are protected and retained according to policy.
1. Who typically defines RACF profiles for CICS resources?
2. What is the purpose of CICS sign-on?
3. Which RACF class is used to protect transaction IDs?