Design example: Securing a direct request with TLS client authentication

This scenario shows how TLS client authentication is used to secure a web service request to a CICS® web service provider application. In this example, the web service requester application connects directly to CICS.

Figure 1. TLS authentication in a web service provider scenario
TLS authentication in a web service provider scenario

The TCPIPSERVICE resource in CICS specifies SSL(CLIENTAUTH), which requires the service requester to send a client certificate. It also specifies AUTHENTICATE(CERTIFICATE) so that CICS uses the client certificate to determine the authenticated user ID.

The URIMAP resource specifies the web service, pipeline, and transaction ID for the request. It also specifies SCHEME(HTTPS) to restrict access to the web service to HTTPS requests.

  1. The web service requester application sends a SOAP/HTTPS request to CICS.
  2. A TLS handshake occurs. CICS sends its server certificate and asks the service requester to provide its certificate. CICS validates the chain of trust by checking that the client certificate issuer (signer certificate) is in the RACF® keyring.
  3. CICS also maps the service requester certificate to a RACF user ID (the authenticatedUserid).
  4. CICS finds the URIMAP that matches the request and determines the web service to start and the service provider pipeline to process the request. The URIMAP also determines the transaction ID tranA to run the request.
  5. CICS queries RACF to verify that the authenticatedUserid is authorized to run transaction tranA. This validation is achieved by calling RACF to check that the authenticatedUserid belongs to a group that has READ authority to the member list (memberListA) containing tranA, in the GCICSTRN class.

When AT-TLS is used, the web attach transaction is not required in most situations. In this case, the pipeline alias transaction runs directly with the authenticated user ID.