Security for CICS transactions

The RACF® profile definitions for the transactions that are supplied with CICS® are described in three categories. Each transaction is identified within a category that describes its use within CICS. Each category specifies the recommended security specifications, in terms of both the CICS transaction definitions and the corresponding RACF profiles. The three categories contain all the required CICS transactions, which are generated in their designated groups when you initialize your CICS system definition data set (CSD). This initialization does not include the CICS sample transactions (the transactions that are in groups that start with DFH$). Some category 1 transactions are not in the CSD. They are defined by CICS during installation.

See Implementing CICSPlex SM security for details of transactions that are related to CICSPlex SM.

The three categories are:

Category 1 transactions: Transactions that are for CICS internal use only and must not run from a user terminal. See Category 1 transactions for details.
Category 2 transactions: Transactions that must be restricted to specific signed-on users; for example, you might want to limit access to transactions that define and install CICS resources. See Category 2 transactions for details.
Category 3 transactions: Transactions that are available to all users, whether signed-on or not. These transactions are not subject to security checking. Any security definitions for these transactions are redundant. See Category 3 transactions for details.

By default, all CICS transactions (except for category 3 transactions) are subject to RACF protection, unless you run your CICS regions with transaction security switched off. You can switch off transaction security either by:

Specifying the system initialization parameter SEC=NO, which switches off all security checking, or
Specifying the system initialization parameter XTRAN=NO, which switches off transaction-attach security checking only.

If you run with transaction security (SEC=YES and XTRAN=YES), CICS issues a security check for each transaction attach, other than a transaction within category 3. This check establishes whether the user is permitted to run that transaction.

Category 1 transactions

Category 1 transactions are never associated with a terminal. They are for CICS internal use only, and must not be started from a user terminal. Do not modify the CSD definitions of these transactions. For a list of category 1 transactions, see List of CICS transactions.

CICS checks that the region user ID has the authority to attach these transactions. If the region user ID is not authorized to access any of the category 1 transactions, CICS issues message DFHXS1113 for each unauthorized category 1 transaction and fails to initialize.

Customize and run the sample CLIST DFH$CAT1 to create the RACF definitions. You need to provide an owner of the profile, the CLASSNAME of the transaction, and the list of CICS region user IDs.

The sample CLIST is in library CICSTS56.CICS.SDFHSAMP.

Category 2 transactions

Category 2 transactions are initiated by CICS users, or are associated with CICS users. Some are associated with signed-on users. Others are associated with task user IDs that are associated with adapters. Restrict authorization to initiate these transactions to user IDs that belong to specific RACF groups. For a list of category 2 transactions, see List of CICS transactions.

The supplied transactions are defined with the recommended RESSEC and CMDSEC options. Make sure that the user groups that are authorized to use the transactions are also authorized to access the CICS resources and commands that these transactions use. You can change these definitions but, if you do so, copy them to another group.

For most category 2 transactions, specify them to RACF as follows:

UACC(NONE) and AUDIT(FAILURES) in the transaction profile. AUDIT(FAILURES) is the default and does not have to be specified.
Access list.

If you protect a resource with a resource group profile, be careful if you protect the same resource with another profile and a user can have different access to both profiles. If the profiles are different (for example, if they have different access lists), RACF merges the profiles that are used during authorization checking. The merging might incur higher cost in checking, and it can be difficult to determine exactly which access authority applies to a particular user. For more information, see z/OS Security Server RACF Security Administrator's Guide.

It is unlikely that users require access to all the transactions in this category, so consider defining the transactions in several subcategories. You can choose to group CICS transactions in the way that best suits the needs of your installation. The sample CLIST DFH$CAT2 (in library CICSTS56.CICS.SDFHSAMP) shows one way that you might group the category 2 transactions. To use a different setup, adapt the CLIST, or provide your own.

Table 1. Suggested subcategories for Category 2 transactions.. To see which transactions are in each subcategory, see List of CICS transactions or the DFH$CAT2 CLIST.
Subcategory	Contains	Notes
For all users:
ALLUSER	Transactions that are used by all users.	Add to the list of transactions your good morning transaction (defined on the GMTRAN system initialization parameter) and your good night transaction in this group (defined on the GNTRAN system initialization parameter).
For operators:
SYSADM	Transactions that are used by system programmers who need full access to the system.
INQUIRE	Transactions that are used by operators or other users who need only to inquire on resources.
OPERATOR	Transactions that are used by operators.
DBCTL	Transactions that are used by operators of the DBCTL interface to IMS.
CMCIUSER	Transactions that are used by operators who use the CICS Explorer® and other users of the CMCI.
For application developers:
DEVELOPER	Transactions that are used by application developers on a non-Production system.
For application users:
JVMUSER	Transactions that are used by users of Liberty applications.	Depending on your security configuration, transactions CJSA and CJSU might require the CICS default user to have access. For more information, see Security for Java applications, Configuring z/OS Connect EE and Configuring permissions for z/OS Connect Services and APIs. As a security best practice, turn on Liberty security and avoid using the CICS default user to run application tasks. For the z/OS® Connect Service, you can install a URIMAP resource that CICS uses to associate the work for the Service with a specific transaction ID in CICS and with an initial user ID. CJSA is the default transaction ID for any web request that does not have a matching URI. Consider restricting access to CJSA to prevent any arbitrary application being run.
INTERCOM	Transactions that are used by application users who run transactions on multiple regions.	If you are using function shipping, the mirror transactions must be available to remote users in a function shipping environment. When a database or file is on another CICS region, CICS function ships the request to access the data. The request runs under one of the CICS-supplied mirror transactions. In this situation, the following conditions apply: The terminal user that runs the application must be authorized to use the mirror transaction. See Transaction security. The terminal user must also be authorized to use the data that the mirror transaction accesses. See Resource security. The mirror transactions are supplied with RESSEC(YES) defined; so, even if the user's transaction specifies RESSEC(NO), the mirror transaction fails if the user is not authorized to access the data. If you do not use resource security checking, change the mirror transaction definitions to specify RESSEC(NO). Because the mirror transactions are an IBM®-protected resource, first copy these definitions into your own groups and then change them. For a deferred START request, if the user transaction to be started is eligible for dynamic routing, system transaction CDFS will run and start the user transaction at the specified time. Ensure that security for CDFS is correctly configured.
WEBUSER	Transactions that are used by application users who run transactions using the CICS web interface.	The CICS default user requires access to the CWBA transaction initially, even if an analyzer program is then used to assign another user ID to the task. Make sure that the CICS default user that is specified in the DFLTUSER system initialization parameter has access to this transaction. If you use the supplied CLIST DFH$CAT2 to create a WEBUSER RACF profile, the default user must have access to this profile.
RPCUSER	Transactions that are used by application users who run transactions using ONC RPC.
PIPEUSER	Transactions that are used by application users who run web services transactions.
EVENTUSER	Transactions that are used by EP adapters.	If the RESSEC and CMDSEC options for these transactions are not the ones you want, you can specify your own transaction IDs in the adapter tab Advanced Options section of the Event binding editor. For more information, see Specifying EP adapter and dispatcher information.
For users of IBM MQ:
MQADMIN	CKAM CKCN CKDL CKRS CKSD CKSQ
MQBRIDGE	CKBC CKBP CKBR
MQMONITOR	CKTI
MQSTATUS	CKQC CKBM CKRT CKDP

Category 3 transactions

Category 3 transactions are either initiated by the terminal user or associated with a terminal. For a list of category 3 transactions, see List of CICS transactions.

All CICS terminal users, whether they are signed on or not, require access to transactions in this category. For this reason, category 3 transactions are exempt from any security check, and CICS permits any terminal user to initiate these transactions.

These transactions can be defined to RACF. Although this definition does not affect task attach-time processing, it is needed to support the QUERY SECURITY command.