Command security
Command security applies to CICS® system programming commands. Security checking is performed for these commands, when they are issued from a CICS application, and for the equivalent commands that you can issue with the CEMT main terminal transaction or CECI. Command security operates in addition to any transaction security or resource security that you define for a transaction. You should always enable command security. Without command security, either applications or any user who has access to CEMT or CICS can issue any SPI command.
For a list of the system programming commands, see System commands.
Like resource security, you can control command security checking at the individual transaction level. You can control access to the SPI commands that are associated with a particular transaction. A user who is authorized to invoke a particular transaction might be allowed only to inquire on the status of a resource but not to change it. A primary use of this support is to restrict what users can do with powerful transactions such as CEMT, which you can use to inquire on resources, to change them, and to shut down CICS.
System initialization parameters (XCMD and CMDSEC) and attributes on a TRANSACTION resource definition control when CICS issues an authorization request for access to a SPI command. The XCMD parameters tell CICS that you want command security checking on CICS system commands. CICS checks the authority to run the command every time that a transaction tries to access it. CMDSEC gives you additional flexibility to control command security at the transaction level. The CMDSEC attribute on a TRANSACTION resource specifies that you want command security to apply to that transaction. The CMDSEC system initialization parameter determines whether CICS honors the setting on the TRANSACTION resource definition or overrides it and always performs command security checking.
The user ID that is used for authorization is the user ID that is associated with the request. For details of user IDs, see How it works: Identification in CICS.
- The user initiates a CEMT request, for example,
CEMT PERFORM SHUTDOWN. - CICS checks whether command security is active for CICS system commands (XCMD SIT parameter).
- CICS checks whether command security in the transaction resource definition is active (CMDSEC), for example:
DFHCSD TRANSACTION(CEMT) CMDSEC(YES) - CICS checks the SIT parameter CMDSEC. If it is set to ALWAYS, the command security check is always performed regardless of the CMDSEC value in the transaction resource definition.
- CICS calls RACF® to determine whether the user has enough access rights to run the command by checking the resource identifier for the command. Resource identifiers for each command are described in CICS resources subject to command security checking.
- RACF checks the currently active resource profile and returns a yes or no decision to CICS. RACF also logs the activity. If RACF is unable to locate a matching profile, CICS then handles the situation as a negative decision.
- CICS then allows or denies the user access to run the command.
CICS and RACF process the authorization request using profiles for each transaction in RACF resource classes. You define these profiles either in the default RACF resource classes for CICS (CCICSCMD or VCICSCMD) or in your own classes. See RACF classes and profiles for resources for more information about the RACF resource classes.
The currently active profile is used for authorization checking. To understand this, see Refreshing profiles for SETROPTS RACLIST processing.
- Set the XCMD system initialization parameter. Always have XCMD on.
- Control command security for individual transactions by setting the CMDSSEC attribute on the TRANSACTION resource definition.
- Set the CMDSEC system initialization parameter to tell CICS whether to honor or override the CMDSEC attribute on a TRANSACTION resource definition.
- Set up RACF profiles to specify if a user is authorized to access a resource.