Designing security for IPIC

Security design considerations for IPIC

Authentication and identification

When to use links with password authentication?

When you use client-to-CICS IPIC connections, you can choose to authenticate with either password or passphrases by setting the USERAUTH(VERIFY) attribute on the IPCONN resource definition. This method is best used with transport security to provide confidentiality for the nonencrypted password..

When to use trusted connections with USERAUTH(IDENTIFY)?

USERAUTH(IDENTIFY) on an IPCONN resource definition requires incoming attach requests to specify a user ID. Both CICS-to-CICS IPIC connections and client-to-CICS IPIC connections can use a trusted connection with USERAUTH(IDENTIFY). When you use trusted IPCONN connections, the task user security context is established without any password or certificate authentication mechanism. This method is designed for scenarios where the local system can authenticate the caller by using its own user registry and is restricted to trusted connections as documented in Table 1 in How it works: IPIC user security. Examples of this kind of scenario include a CICS web owning region, or a WebSphere® Application Server with a local user registry.

Recommendation: When you use trusted IPCONN connections, it is recommended that you apply further security to the connection by using either of the following techniques:

• Transport security with client authentication so that the server can confirm the authenticity of the client.
• Link security to restrict the resources that any authenticated user can access. Link security can also be integrated with TLS client authentication because the link user ID can be established by using the identity of the distinguished name in the client certificate.

Each client can have a dedicated signer certificate. You can permit access to a partner CICS region by adding the public key from each client's signer certificate to the key ring of the partner CICS region.

When to use link security?

Link security provides an additional way of authorizing access to transactions and other resources in the receiving system. It is especially useful if you need to restrict authorization based on the connection into the CICS region. For instance, from a specific trusted web owning region or from a trusted IPIC client connection.

Authorization

When to configure the CICS task in the remote CICS region to run with the RACF® user ID of the user?

Configuring the IPCONN in the remote CICS region with USERAUTH(IDENTIFY) enables fine-grained authorization and auditing of each request, based on the supplied security context.

Do you need to limit the authority of requests from specific connections?

Using link security and IPIC user security allows you to ensure that no request that is made through a specific IPCONN can have more authority than that is granted to the link user ID, whatever authority the flowed user ID has.

Do you want to limit access to CICS resources to a specific, functional user ID?

Instead of configuring the IPCONN to run requests under the user’s identity, requests can be allowed to run under the link user ID. This configuration can either be set by the SECURITYNAME attribute on IPCONN or mapped from the TLS client certificate that is associated with the IPCONN definition.

Confidentiality and integrity

What TLS implementation to use?

You can implement TLS by using System SSL or AT-TLS. However, CICS IPIC is an AT-TLS unaware application, which means that a client cannot use a certificate to authenticate with CICS using IPIC.

What TLS version and cipher suite to use?

You are recommended to use the most recent version of TLS that is also supported by the partner system. The most recent version of the TLS specification includes fixes to previous versions and brings enhancements like support for stronger cipher suites. To control the TLS version that is supported by CICS, you can set MINTLSLEVEL and MAXTLSLEVEL SIT parameters. To set the list of ciphers that are supported, you can modify the contents of the ciphers XML files that are used in the IPCONN or TCPIPSERVICE resource.

Trust considerations for systems that connect through IPIC

TLS client authentication can be used so that the partner system provides a client certificate that is validated by CICS. Successful client authentication requires that the certificate authority (CA) that signed the client certificate is considered trusted by CICS. To be considered trusted, the certificate of the CA must be in the CICS key ring.

Audit considerations for IPIC security