RACF and CICS

RACF is the security manager most CICS sites use. CICS asks RACF every time a user signs on or touches a protected resource.

How CICS uses RACF

• CICS talks to RACF through SAF, the System Authorization Facility. CICS never checks passwords itself.
• When security is on, every sign-on, transaction start, and resource access triggers a RACF check.
• A failed check produces an ICH408I message in the log and the user gets a NOTAUTH response.
• RACF profiles define who can do what. A profile names a resource and lists the permitted userids.

CICS resource classes in RACF

• TCICSTRN protects transactions. MCICSPPT protects programs. FCICSFCT protects files.
• DCICSDCT protects transient data queues, JCICSJCT protects journals, and SCICSTST protects temporary storage.
• Use grouping classes like GCICSTRN to put many transactions in one profile and manage them together.
• Activate a class with SETROPTS CLASSACT and refresh in-storage profiles with SETROPTS RACLIST(class) REFRESH.

Good RACF habits for CICS

• Start with UACC(NONE) so nobody has access unless explicitly permitted. Open up only what is needed.
• Permit groups, not individual userids, so access follows people when they change teams.
• Keep CICS region userids separate from human userids. Region userids need system-level access humans should not have.
• Review profiles regularly. Old permits for moved employees are a common audit finding.

Example: giving a user access to a transaction

• Define a profile for the transaction, permit the user, then refresh the class so CICS sees the change.
• RDEFINE TCICSTRN PAYUPD UACC(NONE) PERMIT PAYUPD CLASS(TCICSTRN) ID(PAYUSER) ACCESS(READ) SETROPTS RACLIST(TCICSTRN) REFRESH
• UACC(NONE) means nobody has access unless explicitly permitted. This is the safest default.
• ACCESS(READ) is enough to run a transaction. Higher access levels are rarely needed for transactions.