Implementing CICS Security with RACF can be a complex and demanding process. In order to do it to a level that creates a good balance can take time and requires good knowledge and understanding of both CICS and RACF. So I will explain the various steps in securing CICS with RACF. Let’s begin with the CICS Userid. This is a Userid that is assigned to the CICS Started task when CICS Initialises. Defining the CICS Userid is done thru a
RACF ADDUSER command. The
PROTECTED attribute should be specified in order to prevent this userid being used to log on to the z/OS system such as TSO. Protected Userids cannot be revoked even if little used. CICS Started tasks are define in the
RACF STARTED Class and the Userid Associated with that Started task is defind in the
STDATA segment of the
STARTED Class. Once CICS has started it will need to issue an Open for the
VTAM ACB (Access Control Block). This is controlled by the
VTAMAPPL Class. The following RACF commands will define this access
RDEF VTAMAPPL CICSPROD UACC(NONE) PERMIT CICSPROD CLASS(VTAMAPPL) ACC(READ)SETROPTS RACLIST(VTAMAPPL) REFRESH I will explain
RACLIST in the next and how to control who can sign onto the CICS System.
Who Can Sign Onto the CICS System?
The Security Administrator can define a Class Descriptor to be RACLISTed. There are many CICS Classes that must be defined as
RACLIST. It is done thru a
RACF SETROPTS command.
RACLIST allows RACF to build a Data Space for a Class. This means that when CICS needs to request that RACF check to see if a Userid has access, a check is made in the relevant Data Space instead of accessing the RACF DataBase, so it is much faster. There are many SIT (System Initialization Table) options that pertain to RACF Security. The first is the Default Userid.
DFLTUSER= This is the Userid assigned to a terminal before signon. This
DFLTUSER can be defined as a Surrogat of the CICS Region Userid if
XUSER=YES is specified.
It should have no access to any transactions, other than those intended to be used by all users. This forces the User to issue CESN for Userid/Password, or CESL for Userid/Passphrase in order to signon. When signon completes, an ACEE (Accessor Control Environment Element) is built and assigned to the terminal. Of course to invoke the CICS signon Transaction,
SEC=YES must have been specified in the SIT. In order to allow access to the CICS APPLID, this must be allowed by defining a Profile in the APPL Class. The
DFLTUSER should be defined in this profile as a minimum. The APPL Class should be RACLISTed.
Securing CICS resources such as Transactions, Programs, Files, etc can take time and a balance has to be found, in my view, as to what is enough and what is too much. Let’s introduce the main RACF Class Descriptors that affect CICS Resources. TCICSTRN/GCICSTRN – Transactions.
Each Pairing of Classes has a Single Entity and a Grouping Entity, so that:
RDEF TCICSTRN CEMT UACC(NONE PERMIT CEMT CLASS(TCICSTRN) ID(SYSPROG) ACCESS(READ) SETR RACLIST CLASS(TCICSTRN) REFRESH
The above allows the group
SYSPROG READ Access to a single entity –
CEMT RDEF GCICSTRN SYSPROGTRANS UACC(NONE) ADDMEM(CEDA,CEDB,CECI,CEBR) PERMIT SYSPROGTRANS CLASS(GCICSTRN) ID(SYSPROG) ACCESS(READ) SETR RACLIST CLASS(GCICSTRN) REFRESH
The above allows group
SYSPROG to the transactions specified in the Entity name of
SYSPROGTRANS. In each case the Class must be refreshed as it is RACLISTed. These two Classes for Transactions are the most popular because we should be securing Transactions, both System and User. However,
TCICSTRN/GCICSTRN only secures Attached Transactions. These are Transactions that are terminal oriented, which of course is most of them. STARTed Transactions that do not specify a Terminal are NOT covered by these two Classes.
With reference to the CICS RACF Security manual, Started transactions that do not specify a Terminal are covered by classes
ACICSPCT/BCICSPCT - XPCT=YES. So in order to have Attached transactions covered by RACF, specify
XTRAN=YES in the SIT/Overrides, but be aware YES here is the default, so if you specify
SEC=YES, then RACF will be called to check if the Userid has access to the Transaction. If you have not specified this transaction in
TCICSTRN, access will be denied.
So if you are establishing RACF Security, my advice is to specify the following:
RDEF TCICSTRN * UACC(READ) SETR RACLIST(TCICSTRN) REFRESH. This will allow all transactions to have
READ access and then you can start to define the individual transactions security until you have completed them and then you can change the
RALT TCICSTRN * UACC(NONE) and
Remember that when the ACEE, mentioned above, is built, it will contain the Userid and every group it is connected to. When CICS checks if the Userid has access to the transaction, it passes the ACEE to RACF for verification. Another question to consider is that if you protect the Transaction, have you protected the Program? CICS doesn’t care how many different transactions invoke the same program. So maybe you need to consider specifying
MCICSPPT/NCICSPPT - XPPT=YES. In order to check if the Userid has access to the program. Another way of course is to check in the program that
EIBTRNID specifies the correct transaction.
In exploring RACF security in CICS, all resources below Transations are considered lower level security or RSL. This applies to Programs, Files, Temporary Storage Queues, Transient Data Queues, Journals. The SIT/Override option is
ALWAYS, should be avoided as this will cause RACF to be checked for every access to a Lower level Resource. Better to specify
ASIS (default) and specify the checking against the individual Transaction with
CEDA DEFINE TRANSACTION(transid) RESSEC=YES. Let’s discuss accessing files from an application.
The Class Descriptors are
FCICSFCT for the single entity, and
HCICSFCT for the grouping entity. Security access to files must be set with access intent, so that if your wish to update a VSAM file
(EXEC CICS WRITE FILE..) then you must specify
UPDATE access in the Class Descriptor
RDEF FCICSFCT FILEA UACC(NONE) PERMIT FILEA CLASS(FCICSFCT) ID(APPLPROG) ACCESS(UPDATE) RACLIST REFRESH
UPDATE access is sufficient for a
KSDS because the access is by Key. But
CONTROL access must be specified for an
ESDS as the access is by
RBA (Relative Byte Address). Next I want to discuss the Command Security and make you aware about a surprising fact concerning Master Terminal transaction
CEMT and how most installations do not protect this transaction sufficiently.
Command Security –
XCMD=YES, offers a more granular approach to securing CICS actions. The
CMDSEC option in the Overrides can be
ASIS (default), but not
ALWAYS. Supplied Transactions
CEMT, CECI, CEDF, CEDG, CEDX, CEDY are delivered with
CMDSEC=YES, so that the moment you specify
XCMD=YES, CEMT/CECI functions will be checked by RACF to make sure that you can issue
SET. So it is important that you define these functions to the appropriate Class Descriptors
CCICSCMD/VCICSCMD. This is also true from within an Application program that might issue
EXEC CICS PERFORM SHUTDOWN. Command Level Programmers should be made aware that their
CEMT functions within their programs can be checked if the Transaction issuing them has
NO being the default.
CEMT is not always done correctly, it invokes program
DFHEMTP. This program does NOT check to see who initiated it. So that any Transaction can be defined to invoke
DFHEMTP. The Transaction needs to be defined so if I cannot access
CEDA, I can write a program and issue
EXEC CICS CSD DEFINE TRANSACTION(ZZZZ) PROGRAM(DFHEMTP) CMDSEC=NO, then issue
EXEC CICS CSD INSTALL TRANSACTION(ZZZZ). I would need
READ access to my program and
READ access to
ZZZZ, to issue
ZZZZ PERFORM SHUT.
One of the most complex issues of CICS security, is trying to workout how to secure CEMT. As already discussed, this transaction can be secured with
TCICSTRN/GCICSTRN. But this means that every CICS region will have CEMT secured the same, even if there are Development Regions. It might be necessary to have CEMT in these regions defined more loosely, so that Development programmers can bring CICS down and use Newcopy. So the way around this is to specify in the Overrides
XTRAN=CLASSNAME. This is user defined such as
DEVCTRN. Then define your own Class Descriptors, e.g
TDEVCTRN/GDEVCTRN in the Dynamic CDT. Be very careful, do NOT choose a
POSIT value of 5, as this value is used for the supplied CICS Classes. So when you issue
SETR CLASSACT(TDEVCTRN) RACLIST, RACF will classact both
GDEVCTRN BUT if you then decide to Class Inact these 2, RACF will class inact every Class Descriptor that matches a
POSIT of 5. So all CICS Classes will be deactivated, thus disabling all CICS security. Chose a
POSIT value 19â€“56 and 128â€“527. So in your Dev Regions, specify
XTRAN=DEVCTRN, CICS will prefix this name with
G and :
RDEF TDEVCTRN CEMT UACC(NONE) PERMIT CEMT CLASS(TDEVCTRN) ID(APPLPROGS) ACC(READ) RACLIST REFRESH.
z/OS Systems Programmer and CICS/TS Systems Programmer of 30 years. Mainframe Training and Software support.