Security for a Multi-System Environment › Defining Link Security

Defining Link Security

Link security limits a remote system's authorization to attach your transactions and access your resources. Each time a request is made to access a remote resource, a security check is performed against the userid defined in the session definition or the CICS TOR userid, if userid is omitted. Since security calls are being made against the link, the CICS region userid for the link must have permission to these resources, or have the NORESCHK and NOLCFCHK attributes defined to the ACID.

No signon for the link takes place if the requesting system passes a userid that matches the receiving CICS region's userid. Therefore, if you want to apply effective link security, the userid on one side of an MRO link must not match the userid on the other side.

It is suggested that MRO region ACIDs be set up with the following attributes:

• NOSUBCHK, NORESCHK, NOLCFCHK
• SOURCE(INTRDR)
• FACILITY(BATCH,STC)
• FACILITY(CICS regions connecting to)

Since these CICS region ACIDs are usually created without a password so that the operator does not have to enter the password when the region is started, the CICS region ACID might be compromised. To prevent a user signing on with the CICS region ACID as a user on a facility to which it is authorized, the SOURCE(INTRDR) restriction is recommended. The NORESCHK and NOLCFCHK attributes are necessary because of LINK SECURITY considerations. NOSUBCHK is necessary for correct handling of job submission.

For MRO and ISC

Link security works by signing on to each end of a session (via receive terminals) using the userid specified on the SESSION definition or, if omitted, the default user.

Defining Link Security to CICS

The following figure shows how to define link security for both MRO and ISC connections

RDO definition
   DEFINE
   SESSION
   CONNECTION(connect)
   USERID(userid)

An example of how link security works in MRO and ISC connections is shown in the following figure.

The SESSION ACID should not be identical across the link or the signon is not performed and the link will fail. The SESSION ACID provides a focal point to decide if individual remote transactions and resources are permitted to the local region. For the purpose of link security, the region's permission for remote resources is represented as the SESSION USERID. This user‑acid can be modeled similar to the remote region ACID, but might have more stringent restrictions than the region ACID to prevent specific types of access by all users signed on to the region.

In the previous example, the PAY transaction is being routed to the AOR. Before the transaction is initiated, CA Top Secret issues a link security check against the CICS region ACID specified in the SECURITYNAME definition as CICSTOR. This security check determines if the PAY transaction can run in the AOR region.

The PAY transaction (depending on the mode) is not able to execute in the AOR region if the CICS SESSION ACID USER1:

• Cannot sign on to CICSAOR
• Is not permitted to the PAY transaction in the TOR and AOR environment
• Is not permitted access to PAY resources in the AOR

Link Security Considerations

Link security is checked at the time a remote transaction is about to be executed, or when a remote resource is about to be attached. Link security involves not only the CONNECTION (DFHTCT TYPE=SYSTEM), but also the SESSION definition (DFHTCT TYPE= ).

RDO definition               RDM definition

DEFINE SESSION (   )        DFHTCT TYPE=  (    )

Link security limits the originating region's authorization to attach local transactions and to access local resources. The following CONNECTION considerations are important for link security:

• If the CONNECTION to the originating region does not specify securityname, extra security calls are made on every link request.
• Security calls are made to evaluate transactions and resources against the region ACID of the originating region, as well as the user ACID who originated the transaction. To grant permission for these, NORESCHK or NOLCFCHK should be specified on the originating region ACID, or explicit PERMIT commands are required. The originating region ACID must have access to the destination region's MASTFAC facility.
• The region ACIDs for two linked regions should never be the same. If two linked regions share the same region ACID, the securityname ACID will never be signed on during link security, causing link security to fail.

The following SESSION considerations are important for link security:

• The value OPERSECURITY(1) should be allowed to default.
• The value OPERRSL(0) should also be allowed to default.

Specifying other values will cause link security to avoid signon for the originating region ACID. Link security will then default to the destination region ACID with often paradoxical results.