When CICS® security
is active, requests to attach transactions, and requests by transactions to
access resources, are associated with a user. When a user makes
a request, CICS calls the external security manager to determine if the user
has the authority to make the request. If the user does not have the correct
authority, CICS denies the request.
In many cases, a user is a human operator, interacting with CICS through
a terminal or a workstation. However, this is not always the case: a user
can also be a program executing in a client system. In general, a CICS user
is an entity that is identified by a user identifier (or user
ID).
All CICS users must be defined to the security manager; when the security
manager is RACF®,
information about each users is stored in a user profile.
Here are some of the ways that the user of a CICS transaction, or a CICS
resource, can be identified:
- A human operator signs on (and so provides a userid) at the start of the
terminal session. The userid remains associated with the terminal until the
terminal operator signs off. Transactions executed from the terminal, and
requests made by those transactions, are associated with that userid.
For
more information, see Identifying CICS terminal users
- A userid is permanently associated with a terminal. Transactions executed
from the terminal, and requests made by those transactions, are associated
with the preset userid.
For more information, see Preset terminal security.
- A client program that is communicating with CICS using the Secure Sockets
Layer (SSL) supplies a client certificate to identify itself. The security
manager maps the certificate to a userid. The transaction that services the
client's request, and further requests made by that transaction, are associated
with that userid.
For more information, see About security for TCP/IP clients.
- A CICS application program issues a START command with the USERID option.
The started transaction, and requests made by that transaction, are associated
with the specified userid.
For more information, see Security for started and XPCT-checked transactions.
- A transaction is started when the trigger level of an intrapartition
transient data queue is reached. If the USERID attribute is specified in the
TDQUEUE definition for the queue, then the started transaction, and requests
made by that transaction, are associated with the specified userid.
For
more information, see Protecting non-terminal transactions.
- A remote program executing in another system, supplies a userid when it
sends an attach request to CICS. The attached transaction, and requests made
by that transaction, are associated with the specified userid.
For more
information, see User security for intercommunication.
- A remote system connects to CICS, and link security is specified for the
connection to the remote system. Transactions invoked from the remote system,
and requests made by that transaction, are associated with the link userid.
For more information, see Intercommunication link security.
- A CICS business transaction services (BTS) process is activated by a RUN
command, and the DEFINE PROCESS command specified the USERID option. The transaction
under which the process runs, and requests made by that transaction, are associated
with the specified userid.
For more information, see Security in BTS.
- A second phase PLT program runs during CICS initialization. Depending
upon the value of the PLTPISEC system initialization
parameter, requests made by the program are associated with the userid specified
in the PLTPIUSR system initialization parameter.
For
more information, see PLT programs.
There are two user IDs that CICS uses in addition to those that identify
individual end users:
- The region user ID
- This user ID is used for authorization checking when the CICS system (rather
than an individual user of the system) requests access to a resource.
For
more information, see The CICS region user ID.
- The default user ID
- This user ID identifies the user whose security attributes are used to
protect CICS resources in the absence of other, more specific, user identification.
For
more information, see The CICS default user ID.
By itself, a user ID does not protect the system from unauthorized access:
in many cases, user IDs are known to other people than the user they identify.
To prevent impersonation, another piece of information — known only to the
individual user — must be supplied in order to authenticate the user. For
example:
- For a terminal user, the password which the user supplies during sign
on authenticates the user.
- For a client using SSL, the client certificate authenticates the client.