CICS Transaction Gateway security classes
The CICS® Transaction Gateway provides the following classes (security exits) for implementing security.
- com.ibm.ctg.security.JSSEServerSecurity
- Use this interface to allow the exposure
of of X.509 Client Certificates when using the JSSE protocol.
See your JSSE, or Java™, documentation for information on using X.509 certificates.
- com.ibm.ctg.security.ServerSecurity
- Use this interface for server-side security classes that do not require the exposure of SSL Client Certificates.
- com.ibm.ctg.security.ClientSecurity
- Use this interface for all client-side security classes.
- com.ibm.ctg.util.RACFUserid
- This class tries to map an X.509 Client Certificate to a RACF® user ID. The certificate must already be associated with a valid RACF user ID.
The JSSEServerSecurity and ServerSecurity interfaces and partner ClientSecurity interface define a simple yet flexible model for providing security when using CICS Transaction Gateway. Implementations of the interfaces can be as simple, or as robust, as necessary; from simple XOR (exclusive-OR) scrambling to use of the Java Cryptography Architecture.
The JSSEServerSecurity interface works in conjunction with the Secure Sockets Layer (SSL) protocol. The interface allows server-side security objects access to a Client Certificate passed during the initial SSL handshake. The exposure of the Client Certificate depends on the CICS Transaction Gateway being configured to support Client Authentication.
An individual JavaGateway instance has an instance of a ClientSecurity class associated with it, until the JavaGateway is closed. Similarly, an instance of the partner JSSEServerSecurity or ServerSecurity class is associated with the connected Java client, until the connection is closed.
- An initial handshake to exchange pertinent information. For example, this handshake could involve the exchange of public keys. However, at the interface level, the flow consists of a simple byte-array, therefore an implementation has complete control over the contents of its handshake flows.
- The relevant ClientSecurity instance being called to encode outbound requests, and decode inbound replies.
- The partner JSSEServerSecurity or ServerSecurity instance,
being called to decode inbound requests and to encode outbound replies.
The inbound request, and Client Certificate, is exposed via the afterDecode() method. For JSSE, the afterDecode() method exposes the GatewayRequest object, along with the javax.security.cert.X509Certificate[] certificate chain object.
ClientSecurity, JSSEServerSecurity, or ServerSecurity class instances maintain as data members sufficient information from the initial handshake to correctly encode and decode the flows. At the server, each connected client has its own instance of the ServerSecurity implementation class.
If you are implementing the security exits you must implement both a client-side security class and server-side security class.
For applications using Java base classes, the security classes are specified using the setSecurity method prior to opening the JavaGateway object. When using a JEE application server, the security classes are specified using the clientSecurity and serverSecurity connection factory properties. For non-managed JCA applications, the security classes are specified using the setClientSecurity and setServerSecurity methods.
The client-side security class must be available on the class path of the application for Java base classes and non-managed JCA applications, or on the class path of the resource adapter when using a JEE application server. The server-side security class must be available on the class path of the Gateway daemon.
To use the com.ibm.ctg.security.ClientSecurity security
classes, you must configure the requiresecurity configuration
parameter available with the TCP and SSL protocol handlers.