CICS users

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 userid).

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 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 Overview of 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 users. They are
The region 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
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 userid does not protect the system from unauthorized access: in many cases, userids 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.