Security-related system initialization parameters

There are several system initialization parameters that CICS® provides for specifying your security requirements at the system level. For full details of system initialization parameters, see the CICS System Definition Guide.

SEC
You use the SEC system initialization parameter to specify the level of resource security management you want for your CICS region. There are two options:
YES
This means that the CICS external security interface will be initialized, and control of CICS security is determined by the other security-related system initialization parameters:
CMDSEC SNSCOPE XPCT
DFLTUSER XAPPC XPPT
EJBROLEPRFX XCMD XPSB
ESMEXITS XDB2 XRFSOFF
PSBCHK XDCT XRFSTME
PLTPISEC XEJB XTRAN
RESSEC XFCT XTST
SECPRFX XJCT XUSER
NO
This means that there is no security checking of whether users are allowed to access CICS (and non-CICS) resources from this region, and sign-on cannot take place.
Note: Even if you have specified SEC=NO, with MRO bind-time security, the CICS region userid is sent to the secondary system, and bind-time checking is carried out in the secondary system. See Bind-time security with MRO for more information.
SECPRFX
This parameter is effective only if you also specify SEC=YES. You use the SECPRFX system initialization parameter to specify whether you want CICS to prefix the resource names that it passes to RACF® for authorization. The prefix that CICS uses is the RACF userid under which the CICS region is running.

Prefixing is useful mainly when you have more than one CICS region. It enables you to prevent users on one CICS region from accessing the resources of a different CICS region that has a different prefix. For example, you might have one CICS region with the prefix CICSPROD and another with prefix CICSTEST. Users of the CICSTEST system would be able to use profiles that included the CICSTEST prefix, and users of the CICSPROD system would be able to use profiles that included the CICSPROD prefix. Users of both systems would be able to use resources protected by profiles that included CICS*.

The options on the SECPRFX parameter are:
NO
CICS does not prefix the resource names in authorization requests that it passes to RACF from this CICS region.
YES
Start of changeCICS prefixes the resource names with the CICS region userid when passing authorization requests to RACF.

Start of changeTo change these values employ an ICHRTX00 SAF preprocessing exit. For more information, see Determining the userid of the CICS region. End of change

End of change
Start of changeprefixEnd of change
Start of changeCICS prefixes the resource names with the specified prefix when passing authorization requests to RACF.End of change
For example, if a CICS job specifies USER=CICSREG on the JOB statement, and SECPRFX=YES is specified, you can define and allow access to the CICS master terminal transaction (CEMT) in the TCICSTRN resource class as follows:
RDEFINE  TCICSTRN  CICSREG.CEMT
         UACC(NONE)   NOTIFY(sys_admin_userid)
PERMIT  CICSREG.CEMT  CLASS(TCICSTRN)
        ID(groupid1,...,groupidn) ACCESS(READ)
You can also use a resource group profile in the GCICSTRN resource class. If you do, specify the prefix on the ADDMEM operand. The following shows CICSREG specified in a profile named CICSTRANS:
RDEFINE  GCICSTRN  CICSTRANS
         ADDMEM(CICSREG.CEMT)
         UACC(NONE)   NOTIFY(sys_admin_userid)
PERMIT  CICSTRANS  CLASS(GCICSTRN)
        ID(groupid1,...,groupidn) ACCESS(READ)
Note: If you protect a resource with a resource group profile, avoid protecting the same resource with another profile. If the profiles are different (for example, if they have different access lists), RACF merges the profiles for use during authorization checking. Not only can the merging have a performance impact, but it can be difficult to determine exactly which access authority applies to a particular user. (For more information, see the z/OS Security Server RACF Security Administrator's Guide.)
CMDSEC
Code CMDSEC to specify whether or not you want CICS to honor the CMDSEC option specified on a transaction's resource definition. CMDSEC specified with the option ASIS means that CICS obeys the CMDSEC option. CMDSEC specified with the option ALWAYS means that CICS ignores the CMDSEC option, and always performs the command check.
DFLTUSER
Specify a value for DFLTUSER to identify to CICS the name you have defined to RACF as the default userid. If you omit this parameter, the name defaults to CICSUSER. See Defining the default CICS userid to RACF.
EJBROLEPRFX
Specifies a prefix that is used to qualify the security role defined in an enterprise bean's deployment descriptor. The prefix is applied to the security role:
  • when a role is defined to an external security manager
  • when CICS maps a security role to RACF user ID
For more information about how the EJBROLEPRFX parameter is used to qualify security roles for enterprise beans, see Java™ Applications in CICS.
ESMEXITS
Use ESMEXITS to specify whether you want CICS to pass installation data for use by the RACF installation exits. For more information on ESMEXITS, see Customizing security processing.
PLTPISEC
Code PLTPISEC to specify whether or not you want CICS to perform command security or resource security checking for PLT programs that run during CICS initialization.
PLTPIUSR
Code PLTPIUSR to specify the userid that CICS is to use for security checking for PLT programs that run during CICS initialization.
PSBCHK
Code PSBCHK to specify that you want CICS to perform PSB authorization checks for remote terminal users who use transaction routing to initiate a transaction in this CICS region (to access an attached IMS™ system). The default PSBCHK=NO specifies that CICS is to check the remote link but not the remote user. The remote user is checked by specifying PSBCHK=YES.
RESSEC
Code RESSEC to specify whether or not you want CICS to honor the RESSEC option specified on a transaction's resource definition. RESSEC specified with the option ASIS means that CICS obeys the RESSEC option. RESSEC specified with the option ALWAYS means that CICS ignores the RESSEC option, and always performs the resource check.
SNSCOPE
SNSCOPE—the sign-on SCOPE—applies to all userids signing on by explicit sign-on request; for example, the EXEC CICS SIGNON command or the CESN transaction. Use it to specify whether or not a userid can have more than one CICS session active at the same time.

The sign-on SCOPE is enforced with the MVS™ ENQ macro. The SNSCOPE values correspond to the STEP, SYSTEM, and SYSTEMS levels of ENQ scoping. This means that only those CICS systems that specify exactly the same value for SNSCOPE can check the scope of each other.

SNSCOPE affects only users signing on at local terminals, or signing on after using the CRTE transaction to connect to another system.