How it works: Identification in CICS

All CICS tasks are associated with one or more user IDs. The primary user ID is known as the task user ID. The task user ID is derived from whoever or whatever started the task and that can be one of many different things. To differentiate the user ID that comes from each of these starting points, CICS uses different names for them. These names are explained in this document.

CICS calls RACF to determine whether the user ID has the authority to complete the request. For example, when a task issues a request to access a resource or to attach a CICS transaction to run another task,

Individual users make requests of CICS and supply identification to do so. The following users (in alphabetical order) are identified with RACF user IDs that reflect how they accessed CICS:

Table 1. Simple RACF user IDs
Definition	Brief description
Asserted user ID	User ID flowed from a trusted remote system.
Authenticated user ID	User ID shared from a remote system that includes credentials that CICS uses to authenticate the user.
Certificate user ID	User ID associated with a client certificate.
Client user ID	An identity that comes from outside of CICS with some credentials to be authenticated.
EDF user ID	The user ID under which the Execution Diagnostic Facility is run to test a transaction.
Functional user ID	A functional user ID is a user ID used by all users of a function instead of identifying individual client user IDs.
Link user ID	A user ID passed as part of the bind process or defined in a resource definition that is associated with the connection.
Resource user ID	A user ID defined in a resource definition and used to run a task or used to authorize a request.
Session user ID	A user ID that can be associated with a session, such as a 3270 terminal session.
Task user ID	The task user ID is obtained from whoever or whatever started the task.
Technical user ID	Alternative name for functional user ID.

CICS supports surrogate security, where one user can act on behalf of another. The following users (in alphabetical order) are identified with RACF user IDs when CICS is using surrogate security:

Table 2. RACF IDs that use surrogate security
Definition	Brief description
Batch region user ID	A batch region user ID, is the user ID under which a request will run. It is typically a functional user ID.
Execution user ID	An execution user ID, typically a functional user ID, is paired with a surrogate user ID.
Surrogate user ID	A surrogate user has the authority to start work on behalf of another user (the execution user).

Not all user IDs originate as RACF user IDs. Remote systems that have different user identities that come from external security realms can connect to CICS. Similarly, the Liberty JVM servers that are used by CICS use different types of user identity. These different user identities can be mapped to RACF user IDs to enable them to access CICS resources.

Table 3. Remote user IDs that are mapped to RACF
Definition	Brief description
Distributed identity	A distributed identity represents user identity information from a different security realm that is flowed into CICS.
Java security subject	A Java security subject is used by Liberty to represent a user.

How users are identified in CICS explains how these user IDs are used.

A number of users are associated with the CICS region itself. These users are identified with RACF user IDs that reflect the configuration of CICS:

Table 4. User IDs associated with the CICS region and its configuration
Definition	Brief description
CICS default user ID	One of the user IDs that is associated with the CICS region to protect resources in the absence of other more specific user identification.
CICS region user ID	One of the user IDs that is associated with the CICS region that is associated with the tasks started when CICS starts.
Kerberos service principal user ID	One of the user IDs that is associated with the CICS region that is related to Kerberos use.
PLT user ID	One of the user IDs that is associated with the CICS region when requests are made by second phase PLT programs.

Information about users is stored in a user registry. See User registries for the options that CICS supports.

How users are identified in CICS

Figure 1 shows different ways in which user IDs can come into CICS and how they map to the task user ID of the task that processes their requests. When requests come into CICS, various system tasks do processing before the user task is started; these system tasks are not shown in the diagram.

From a session

Each user supplies credentials that contain a user ID and a secret, such as a password, when they start the session. This user ID is known as the session user ID. Examples of sessions include interaction with CICS through a 3270 terminal, from CICS Explorer (by using CMCI JVM server) or the CICSPlex SM WUI. Every request that the user makes during the session goes back to the same connection and runs under the same user ID. Any task that is initiated through the session runs under the session user ID that the user supplied at the start of the session.

Over an untrusted connection

An untrusted connection is one in which trust is not established for the connection itself. Requests are stateless, so each request must establish trust by supplying credentials that can be authenticated in CICS before the request is processed. The credentials contain an authenticated user ID. The authenticated user ID is used as the task user ID.

Over a trusted connection

Two user IDs are associated with requests over a connection:

A link user ID is associated with the connection itself.
A user ID that is associated with the request.

The remote system and the CICS system must establish trust when the connection is bound, which can be done in one of two ways:

The remote system supplies credentials that are authenticated when the connection is established. These credentials can be a certificate, which is associated with the link user ID.
The session can be securely defined in z/OS, for example, in VTAM definitions. Depending on the type of connection, the link user ID can flow into CICS or be defined in CICS.

The CICS connection definition can require that, in addition to a trust relationship of the connection, the user ID that is associated with the request must also be authenticated. The request must then supply credentials that can be authenticated, resulting in an authenticated user ID. Alternatively, the CICS connection definition can specify that it trusts the remote system. In this case, the remote system needs only to supply an asserted user ID as part of the request.

The CICS connection definition specifies whether the user ID that is associated with the request (either the authenticated user ID or the asserted user ID) is required. If so, it is used as the task user ID. If it is not required, the link user ID is used as the task user ID.

Inside CICS (during CICS processing)

As part of CICS processing, CICS uses information in some resource definitions to start a task with a specific user ID or to use a specific user ID for authorization for a request. That task is associated with the user ID that is defined on an attribute of the resource. This user ID is known as a resource user ID.

A similar concept is the PLT user ID that is used to start a task to run PLTs.

Types of user ID in CICS

The user IDs are listed alphabetically.

Asserted user ID

A message or a request that is received over a trusted connection or component can contain a user ID that has been previously authenticated by another component. The user ID does not need to be authenticated in CICS® because the other component is trusted. The user ID is therefore asserted. Compare this to an authenticated user ID where the user ID that is associated with the request must also be authenticated.

Authenticated user ID

A CICS connection definition can require that, in addition to a trust relationship of the connection, the user ID that is associated with the request must also be authenticated. The request must then supply credentials that can be authenticated, resulting in an authenticated user ID. Compare this to an asserted user ID where the message or request that is received over a trusted connection can contain a user ID that is previously authenticated by the remote system.

Batch region user ID

A user ID that is used when running batch processes. This user ID is usually configured as a functional user ID.

Certificate user ID

A user ID that is associated with a certificate that is presented to the CICS region during a mutual TLS handshake. This user ID can be used as either a functional user ID, a link user ID, or a task user ID. For more information on how RACF® maps a certificate to a user ID, see Certificate mapping.

CICS default user ID

One of the user IDs that is associated with the CICS region.

The CICS default user ID is used to protect resources in the absence of other more specific user identification. For example, when a 3270 terminal session is started, the session is associated with the CICS default user ID until the user signs on.

You must define the CICS default user ID with no authority to use secured resources. It is recommended that the default user ID is a member of a RACF group that contains only CICS default user IDs. It must not be a member of any other group.

Because the CICS default user ID is key to the running of CICS, it must be protected. It is recommended that this user ID is defined to RACF with the PROTECTED attribute. Protected user IDs cannot be used to log on to the system, and are protected from being revoked through incorrect system access attempts. This setting prevents failed password attempts that cause a denial of service attack.

CICS region user ID

One of the user IDs that is associated with the CICS region.

When you start a CICS region in a z/OS environment, either by submitting JCL or by using a started task, the job or task is associated with a user ID. This user ID is known as the region user ID. When the started job is CICS, it is known as the CICS region user ID. The CICS region user ID accesses the resources that are listed on behalf of the task user. Therefore, the CICS region user ID must have authorization to the following resources:

z/OS log streams
Data sets: CICS system data sets and CICS user data sets, JES spool data sets
Temporary storage data sharing servers
SMSVSAM server
Named counter servers
z/OS Communications Server ACB
Coupling facility data tables
RACF key rings
JVM server and Liberty configuration files and logging directories in zFS

The CICS region user ID is used for authorization in the following cases:

Submitting jobs to the JES internal reader
Authorizing a surrogate for other user IDs used during CICS execution
As a prefix for resource names that are passed to RACF
Running CICS system transactions (also known as Category 1 transactions)
In CICS intersystem communication
In Liberty JVM server, to control registration with the angel process

Recommendation: Because the CICS region user ID is a powerful user ID, it must be protected. This user ID must be defined to RACF with the PROTECTED attribute. Protected user IDs cannot be used to log on to the system, and are protected from being revoked through incorrect system access attempts. This setting prevents failed password attempts that cause a denial of service attack.

Client user ID

An identity that comes from outside of CICS with some credentials to be authenticated. This ID is a RACF-based identity; otherwise, it would be a distributed identity.

Distributed identity

A distributed identity represents user identity information from a different security realm that is flowed into CICS. This user identity information contains a user ID from a different user registry than the RACF registry used by CICS and might be in a different form, such as an X.500 distinguished name. The distributed identity is created and authenticated in one system and is passed to one or more other systems over a network. A distributed identity only ever originates outside CICS. CICS is never the source of a distributed identity but can propagate the distributed identity onwards.

A distributed identity is often associated to a RACF user ID by using distributed identity mapping. For more information, see Identity propagation.

A distributed identity is usually passed to CICS over a trusted connection or passed in a signed third-party authentication token. Distributed identities can be flowed into CICS by using a third-party authentication token, such as a JSON Web Token (JWT) or an Extended Identity Context Reference (ICRX) over trusted IPIC connections.

A distributed identity can also be mapped to a RACF user ID outside CICS, for example by IBM DataPower. In this case, only the RACF user ID is passed to CICS as an asserted user ID.

EDF user ID

Execution diagnostic facility (EDF) can be used to test a transaction. When a transaction is under test in dual-screen mode, the user ID under which EDF runs (the EDF user ID) becomes significant. When authorization checks are made in the transaction under test, the access authority of the EDF user ID is checked in addition to the user IDs that are normally associated with the transaction (when it is not under test).

Execution user ID

In surrogate security, an execution user ID is paired with a surrogate user ID. The execution user ID is typically a functional user ID. A surrogate user is authorized to act for the execution user without authenticating as that user. See Surrogate security.

Functional user ID

A functional user ID is a user ID used by all users of a function instead of identifying individual client user IDs. Typically you can achieve this configuration by using the link user ID as the task user ID.

Java security subject

A Java security subject is used by Liberty to represent a user. The CICS Liberty security feature can be used to synchronize the Java security subject and the CICS task user ID.

Kerberos service principal user ID

One of the user IDs that is associated with the CICS region. If you use Kerberos, you must define a Kerberos service principal to register the CICS region as a service to Kerberos. This user ID must have a password that is associated with it. As a consequence, it cannot be defined to RACF as a protected user ID and it must not be the same as the CICS region user ID.

Link user ID

The link user ID is either passed from the remote system as part of the secure establishment (the bind) of the connection, or it is defined in the resource definition that is associated with the connection. See Resources that have link user IDs for a list of the resources for which this situation applies.

PLT user ID

One of the user IDs that is associated with the CICS region.

PLT programs run during CICS initialization. Requests that are made by second phase PLT programs are associated with the PLT user ID. The user ID is defined by the PLTPIUSR system initialization parameter.

Resource user ID

A resource user ID is a user ID that is defined on a resource definition. Its purpose is either to run a task or to be used in the authorization of a request. See Resources that have user IDs for a list of the resources that are associated with resource user IDs.

Session user ID

A user ID can be associated with a session, such as a 3270 terminal session. This user ID is normally associated with the session when the user signs on to the terminal.

Surrogate user ID

A surrogate user has the authority to start work on behalf of another user (the execution user). The execution user is typically a functional user ID. A surrogate user is authorized to act for the execution user without authenticating as that user. See Surrogate security.

Task user ID

All CICS tasks are associated with a user ID. This user ID is obtained from whoever or whatever started the task.

Technical user ID

Alternative name for functional user ID. The documentation refers to Functional user ID throughout.

User IDs associated with a CICS task

A CICS task can be associated with up to three user IDs:

Task user ID
Link user ID
EDF user ID

The task user ID is the primary user ID. Only the task user ID is displayed in CICS commands that show the user ID that is associated with a task. However, all three user IDs are used in authorization.

When a task is initiated over a connection, it can have an asserted user ID and a link user ID. The connection can be defined so that an asserted user ID is not needed. In this case, the task user ID is the link user ID. This type of link user ID is often known as a functional user ID.

When a task is being debugged by EDF, the user ID that controls the EDF session is known as the EDF user ID.

When a task is started in a CICS Liberty server or links to a program running in a CICS Liberty server, an assertion can be made between the Java security subject and the CICS task user ID. For more information, see CICS Liberty security feature.

Resources that have user IDs

Table 5 lists the resources that have user IDs (excluding link user IDs) associated, their attributes, and the purpose of these user IDs. For more information, see Resource definition attributes.

Table 5. Resources that have user IDs
Resource	User ID attributes	Purpose of user ID
BUNDLE with transaction start EP adapter	USERID in the properties of the transaction start EP adapter.	User ID under which the transaction is started
DB2CONN	AUTHID (used in API requests) AUTHTYPE	For authorization of pool threads
	COMAUTHID (used in API requests), COMAUTHTYPE	For authorization of command threads
	SIGNID	To sign on to IBM Db2 for authorization of pool and DB2ENTRY threads
DB2ENTRY	AUTHID (used in API requests), AUTHTYPE	For DB2ENTRY authorization (not RACF)
MQMONITOR	MONUSERID	Task user ID of the MQ monitor
	USERID	Task user ID associated with messages
TDQUEUE	JOBUSERID	Job user ID for JCL that is submitted by using transient data queues
	USERID	Task user ID of triggered task
URIMAP	USERID	Task user ID for the request

Resources that have link user IDs

Table 6 lists the resources that use associated link user IDs, their attributes, and the purpose of these user IDs. For more information, see Resource definition attributes.

Table 6. Resources that have link user IDs
Resource	User ID attributes	Purpose of user ID
CONNECTION (APPC)	SECURITYNAME	Link user ID
IPCONN	SECURITYNAME	Link user ID
SESSIONS	USERID	Link user ID
TERMINAL	SECURITYNAME	Link user ID
	USERID	Preset user ID