IPIC user security

User security causes a second check of the received security context that flows from the requestor and under which the transaction operates. The received security context usually contains the user ID of the user running the client.

The security context might identify one of the following types of user:

A user signed onto a terminal in a TOR
A user ID of the transaction issuing the DPL request
A client user of an ECI request

For IPIC connections, the USERAUTH attribute on the IPCONN resource definition specifies the sign-on requirements for incoming requests. It has no effect on requests that are issued by your system to a remote system; these are dealt with by the remote system. The equivalent attribute for MRO and SNA connections is the ATTACHSEC attribute. For more information about the ATTACHSEC attribute and specifying user security with other intercommunications methods, see Specifying user security in link definitions.

For IPIC connections, you can specify the following types of user authentication:

LOCAL: CICS® does not accept a user ID or password from clients. All requests run under the link user ID or the default user ID if there is no link user ID.
IDENTIFY: Incoming attach requests must specify a user ID. Enter IDENTIFY when the connecting system is trusted to pre-authenticate users, for example, if it is another CICS or CICS TG system.; SSL client authentication must be in use or the connecting system must be in the same sysplex.
VERIFY: Incoming attach requests must specify a user ID and password. Specify VERIFY when connecting systems are unidentified and cannot be trusted.
DEFAULTUSER: CICS does not accept a user ID and password from the partner system. All requests run under the default user ID.

For outbound requests, the level of user security is specified by the USERAUTH attribute of the IPCONN definition installed in the partner system. CICS sends a user ID when USERAUTH(IDENTIFY) is specified, but not when USERID(LOCAL) is specified. Because CICS does not send passwords to remote systems, USERAUTH(VERIFY) is not supported for communication between CICS TS for z/OS® systems.

Note: CICS uses password verification to verify a user ID during the processes described here. CICS enforces a full verification request once a day for each user ID that is used to log on to the CICS region. The full verification request using the RACROUTE REQUEST=VERIFY macro makes RACF® record the date and time of last access for the user ID, and write user statistics.

Establishing a trust relationship when using USERAUTH(IDENTIFY)

Defining an IPCONN resource with USERAUTH(IDENTIFY) means that you are prepared to accept unauthenticated, or asserted, user identifiers on the connection; that is, you are trusting the partner system to transmit only user IDs that have already been authenticated in the partner system. CICS identifies two types of partner, with differing degrees of trust:

The partner is outside the local sysplex

If the partner is outside the local sysplex, CICS does not directly trust the partner to assert unauthenticated user IDs unless it identifies itself with a trusted digital certificate. Connections from such partners are therefore only accepted using a secure socket layer connection with client authentication. This type of connection is specified by the attribute SSL(CLIENTAUTH) on the TCPIPSERVICE definition.

If you do not require encryption over the connection, you can suppress the normal encryption that SSL provides by specifying four-character cipher suites that do not perform encryption, such as 003B, C001, C006, C00B, and C010, on the CIPHERS attribute of the TCPIPSERVICE definition. For a complete listing of cipher suite definitions supported by z/OS, see Cipher suite definitions in z/OS Cryptographic Services product documentation. To use any of these cipher suite definitions in CICS, you must set up an SSL cipher suite specification file as described in Creating an SSL cipher suite specification file.

The partner is in the local sysplex

If the partner is in the local sysplex, CICS trusts the partner to assert unauthenticated user IDs without requiring a digital certificate. Connections from these partners are permitted without requiring an SSL connection.

Configure the TCP/IP network so that there is no proxy between CICS and the partner system. If there is a proxy, CICS might not be able to correctly detect if a partner is in the same sysplex. It is strongly recommended that you configure the netaccess security zones to control which other systems within the same sysplex are allowed to communicate with CICS.

For further information on network access control, see the z/OS Communications Server: IP Configuration Guide. For further information on the NETACCESS configuration parameter, see the z/OS Communications Server: IP Configuration Reference.