Intercommunication security

Intercommunication security ensures that users of one CICS® system are entitled to run transactions and access resources in another CICS system. Intercommunication security in CICS is concerned with incoming requests for access to CICS resources instead of requests that are sent out to other systems. Security issues with incoming requests arise when a given user at a given remote system tries to access resources of your local system. You need to determine if this access is authorized or whether the access should be rejected.

For connected systems, the same principles of protecting CICS resources, commands, and transactions apply, but you also have to consider the resource definitions for the connections. You need to allow for the fact that users of one CICS system can initiate transactions and access resources in another CICS system. You might have to define a RACF® user profile or group profile more than once: you might have to define these profiles in each CICS system that is using a separate RACF database, and in which a user is likely to want to attach a transaction or access a resource.

When planning the RACF profiles, you must consider all cases in which a user could initiate function shipping, transaction routing, asynchronous processing, distributed program link, distributed transaction processing, or external call interface (EXCI). For descriptions of these methods of intercommunication, see Distributed transaction processing overview.

There are three types of link that you can use between CICS systems:

MRO (Multiregion operation): MRO is a CICS-to-CICS facility that does not require a network connection such as TCP/IP or SNA. MRO can be used between CICS regions that are in the same z/OS® LPAR or in the same z/OS sysplex and joined by the z/OS coupling facility.

IPIC: For communication between CICS and non-CICS systems, or between CICS systems that are not in the same LPAR or z/OS sysplex, a network access method provides the necessary communication protocols. When this protocol is TCP/IP, communication is known as IP interconnectivity or IPIC.

ISC: For communication between CICS and non-CICS systems, or between CICS systems that are not in the same LPAR or z/OS sysplex, a network access method provides the necessary communication protocols. When this protocol is SNA (either LU6.1 or LU6.2), communication is known as intersystem interconnectivity or ISC.
You are recommended to connect systems through IPIC instead of ISC. ISC is listed here only for legacy purposes and no further documentation about it is provided in this section.

There are three elements to intercommunication security:

Bind time security: Bind time security prevents an unauthorized system from connecting to CICS.

Link security: Link security controls what access is authorized over the link between the two systems.

User security: User security controls what the requester is authorized to do.

Bind time, link and user security and how they affect intercommunication security

Requests that run in the local system are security-checked by both the asserted user ID and the link user ID. Both user IDs are optional, depending on how you have configured CICS. If both are available, then the task user ID is derived from the asserted user ID. For information about the different user IDs used in CICS security processing, see How it works: Identification in CICS.

Bind time security

For any communication between systems, the first requirement is a session to be established between the two systems. A session, once established, is usually long-lived. The connection request that establishes the session can, depending on the circumstances, be issued either by the remote system or by your local CICS system.

Your security concern at bind time is to prevent unauthorized remote systems from being connected to your CICS system; that is, to ensure that the remote system is really the system that it claims to be. This level of security is called bind time security. It prevents an unauthorized remote system from connecting to CICS and verifies that the remote system is really the system that it claims to be. Bind time security can be applied when a request to establish a session is received from, or sent to, a remote system.

Table 1. How bind time security is enforced
Link type	Security check
MRO	DFHAPPL profile in the RACF FACILITY class
IPIC	Exchange of TLS client certificate with partner system

You are recommended to connect systems through IPIC instead of ISC.

Link security

Each link between systems is given an authority that is defined by a link user ID. Link security defines the transactions and resources that the remote system is allowed to access across the connection. For information about how the link user ID is set for IPIC, see How it works: IPIC link security.

Users cannot access any transactions or resources over a link that is itself unauthorized to access them. This means that each user's authorization is a subset of the authority of the link as a whole.

Link security works with the other forms of authorization, such as Transaction security or Resource security to govern what the link user ID can access or do in CICS. For example, resource security controls the authority of the link user ID to access resources.

Link authority is established just after the connection (IPIC) or session (MRO) is bound, by sign on of a user ID that is determined by the attributes below.

Table 2. How link security is enforced
Link type	Resource definition	Attributes
MRO	SESSION	USERID
IPIC	IPCONN	LINKAUTH and SECURITYNAME

Remote user security

In addition to the security profile that you set up for the link user ID, you can further restrict each remote user's access to the transactions, commands, and resources in your system. For information for IPIC, see How it works: IPIC user security.

User security works with the other forms of authorization, such as Transaction security or Resource security to govern what the remote user can access or do in CICS. For example, resource security controls the authority of the remote user to access resources in the local system.

Table 3. How remote user security is enforced
Link type	Resource	Attributes
MRO	CONNECTION	ATTACHSEC
IPIC	IPCONN	USERAUTH

When do I use link security and user security?

User security causes CICS® to make a second check against a user, in addition to the link security check. There are use cases for different combinations of link security and user security.

Table 4.
	Link user ID	No link user ID
Authenticated or asserted user ID	If users can enter the system from multiple locations, you can use the link user ID to give different access to different users, depending on their entry point. For example, a user can access a resource if they issue the request at work but not if they make the request from home.	Use this where none of the security checks need to take account of where a request came from. Security is based only on the authenticated or asserted user ID.
No authenticated or asserted user ID	Use this where all user requests are made under a single link user ID, often known as a functional ID. All security checking must be performed by the remote region, or earlier. Although this simplifies the security setup, requests cannot be secured or audited by CICS for different users. Auditing requires tying up information from the local region with information in the remote region and earlier. Security is based only on the link user ID.	This is generally not recommended. It is useful only if no security is required to access resources on the local system. All requests run under the CICS default userid.