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*.
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.