Defining CICS link security

You can define security levels to the transactions and resources in your CICS® system that apply to all intercommunication requests that are received from a particular system. This form of security is known as link security.

To use link security, you must have a security manager. CICS has its own security manager, but if your operating system supports an external security manager that TXSeries for Multiplatforms supports, you can use that instead of, or in conjunction with, the CICS internal security manager. An external security manager is a user-supplied program that allows you to define your system's own security mechanism for preventing unauthorized user access to resources from application programs and the unauthorized initiation of CICS transactions.

The sections that follow help you implement CICS internal security, which uses Transaction Security Level (TSL) and Resource Security Level (RSL) keys to restrict access. For information about using external security managers, see Using an External Security Manager.

The security keys that are defined for link security apply to all requests that are received from a particular remote system. This means that the list of security keys must include all the keys that are needed by every user from the remote system. If the needs of the users from a remote system vary, this list of security keys might give more access to some users than is needed. If this is not acceptable, consider using the security that is described in Providing CICS user security, which allows you to set up security keys based not only on the system that sent the request, but also on the user who is associated with that request also.

If link security is enough, it can be set up as follows:
  1. Set the Communications Definitions (CD) RemoteSysSecurity attribute to local for the connection to the system for which you want link security implemented.
  2. Specify a link user ID for the connection with the CD LinkUserId attribute. This user ID is associated with any request that is received from the remote system that is at the other end of the connection.
  3. Create a User Definitions (UD) entry for the connection's link user ID. Use the UD TSLKeyList and the RSLKeyList attributes to specify the transactions and resources that can be accessed by inbound requests.
An alternative implementation of link security follows:
  1. Set the CD RemoteSysSecurity attribute to local for the connection to the system for which you want link security implemented.
  2. Do not specify a link user ID for the connection with the CD LinkUserId attribute.
  3. Use the CD TSLKeyMask and RSLKeyMask attributes to define the TSL and RSL keys to use for the connection.
These two methods differ as follows:
  • When a link user ID is specified for the connection, the user is logged on as the connection's link user ID, and the keys that are defined for the link user ID are used. This is the preferred method.
  • When a link user ID is not specified for the connection, the user is logged on as the region's default user ID, and the connection's TSLKeyMask and RSLKeyMask keys are used. Any keys that are defined for the region's default user ID are ignored.

In either case, you must have TSL and RSL keys assigned to the resources and transactions for which you want link security applied. For further information, see the discussion of the RSLKey and TSLKey settings in Using CRTE and CESN/CESL to sign on from a remote system.