Designing security for CICS web service requesters

Scenario for CICS web service requesters

In Figure 1, the CICS web service requester sends a request to a web service provider.

Security design considerations for CICS web service requesters

Authentication and identification considerations for web service requester security

Will you use transport-based or SOAP message-based authentication?

You can use transport-based security or SOAP message-based authentication, depending on how the web service provider application expects to receive authentication credentials.

Transport-based authentication can be implemented by using HTTP basic authentication or TLS client authentication.

The XWBAUTH global user exit is used to specify the credentials to send. See HTTP client send exit XWBAUTH.

Web HTTPS is used to connect to a web service provider. The web service provider can require CICS to provide a client certificate. See Design example: Securing a web service request with TLS client authentication.

Use SOAP message-based authentication (WS-Security) when the web service provider expects to receive an authentication token in a SOAP header.

• If you choose SOAP message-based security, you can configure the CICS security handler to include one of the following authentication tokens in the security header of outbound SOAP message:
  • Username tokens that contain only a username.
  • X.509 digital certificate

  6.3 Support for X.509 certificate authentication for the WS-Security feature is removed as of CICS TS 6.3.

  If you use other token types, you can configure the CICS security handler to call a Security Token Service (STS). Alternatively you can write your own message handler to use the Trust client interface.

  Recommended: Use TLS to secure the connection to the STS.
• In some scenarios, SOAP message authentication can be used along with transport-based authentication, for example, the RACF® user ID of the CICS task can be flowed in a SOAP security header and the CICS region can be authenticated to the web service provider by using TLS client authentication. See Design example: Securing a web service request with identity assertion.

Confidentiality and integrity considerations for web service requester security

6.16.2

TLS, XML signatures and XML encryption, or non-encrypted?

TLS can be used for integrity and confidentiality for point-to-point connections where no intermediate server is involved, but it does not ensure end-to-end message integrity or encryption because the message is not protected within intermediate servers.

XML signatures and XML encryption can be used to ensure integrity and confidentiality end-to-end, including within intermediate servers. However, this capability is rarely used because the performance overhead of XML signature processing and XML encryption in CICS is significant. As an alternative, these capabilities are often implemented in an intermediate server such as IBM® DataPower® Gateway.

Recommendation: If you need XML signature processing or XML encryption, consider implementing these capabilities in an intermediate server, such as IBM DataPower Gateway, instead of directly in CICS.

6.3 Support for signing and encrypting SOAP messages for the WS-Security feature is removed as of CICS TS 6.3. You can still use Transport Layer Security (TLS) to secure SOAP messages. As a result, the XML Toolkit for z/OS® is no longer required.