Controlling the use of preset security

When a preset security terminal is installed, the specified userid is implicitly signed on at the terminal.

Ensure that only a trusted person is allowed to define and install terminals with preset security, because the userid specified on the terminal might have access to CICS resources not available to the installer. Automatic preset security for consoles does not carry the same risks because the console user is associated with their true identity (verified by RACF). For this reason, no checking is carried out when a console device is defined to CICS with either USERID(*EVERY) or USERID(*FIRST).

Surrogate user checking ensures that a user is authorized to act for another user. Surrogate user checking can be enforced when a user installs a terminal that is preset for a different userid, and is specified by the RACF SURROGAT resource class. The CICS userid.DFHINSTL resource can be defined in the SURROGAT resource class for authorization to install terminals that are preset for that specific userid.

When a terminal is installed with a preset userid, the surrogate user is the userid that is performing the installation. For more information, see Surrogate user security.

The CEDA command checks the authority of the user to install preset terminals. Consider, therefore, whether to restrict the following functions with a view to controlling who can define and install terminals with preset security:
  • The CEDA transaction:

    Restricting the use of the CEDA transactions to authorized users gives you control over who can define resources, such as terminals, to CICS. For information about protecting CICS-supplied transactions, see Security for CICS transactions

  • The SURROGAT resource class:

    If you restrict who can install terminals with preset security, even when such terminals are defined in the CSD, only authorized users can install them on CICS. This authority is in addition to the authority needed to run CEDA; the user must already have authority to run the CEDA transaction.

    To define a surrogate profile and authorize a user to install a terminal definition with preset security, use the following commands: 
    RDEFINE userid1.DFHINSTL SURROGAT UACC(NONE)
PERMIT userid1.DFHINSTL CLASS(SURROGAT) ID(userid2) ACCESS(READ)

    This permits userid2 to install a terminal preset with userid1

  • The XUSER system initialization parameter:

    To ensure that CICS can perform surrogate user security checks on the use of the CEDA INSTALL command for terminals with preset security, define the XUSER system initialization parameter. See CICS resource class system initialization parameters for information about defining this parameter.

  • The LOCK command for locking CSD definitions

    CICS installs resource definitions in the CSD during an initial or cold start, from the list of groups that are defined on the GRPLIST system initialization parameter. To control the addition of resource groups to the CICS startup group list, use the CEDA LOCK command to lock the list. This lock protects the group list from unauthorized additions. Also, lock all the groups that are specified in this list.

    Note: The OPIDENT of the signed-on user is used as the key for the CEDA LOCK and CEDA UNLOCK commands. For more information about the LOCK and UNLOCK commands, see The CEDA LOCK command and The CEDA UNLOCK command.
Note: When CICS installs a GRPLIST that contains preset terminal definitions, no checking is done at initialization time. However, you can still ensure that you control who can define and install terminals and sessions with preset security by using the CEDA LOCK command to control the contents of GRPLIST groups.