Designing security for CICS web service providers

Two primary scenarios are possible for a CICS® web service provider: a direct request to a CICS web service provider or a request through an intermediate server that uses a third-party authentication server. To secure each of these scenarios, consider the implications for different aspects of security and decide which options are the best for you. Examples illustrate some recommended options.

For the equivalent considerations for web service requester applications, see Designing security for CICS web service requesters.

For more information, see Configuring security for CICS web services.

Scenarios for CICS web service providers

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

Figure 1. Direct request to CICS web service provider
Direct request to CICS web service provider

In Figure 2, the web service requester calls an intermediate server, which authenticates the request with a third-party authentication server, then passes the identity of the client to the CICS web service provider.

Figure 2. Request from an intermediate server
Request through an intermediate server

Security design considerations for CICS web service providers

When you design security for CICS web service provider scenarios, consider the implications for:

These considerations are explored further in this document.

Authentication and identification considerations for web service provider security

Who authenticates the web service requester? Is it CICS or an intermediate server?
CICS can authenticate a web service requester directly, or an intermediary can provide an authentication service to CICS. In this case, the intermediate server authenticates the client and then passes the identity of the client to CICS across a trusted connection. The client's identity can be passed to CICS as an asserted user ID or a distributed identity.
Will you use transport-based or SOAP message-based authentication?

Transport security is recommended for point-to-point requests where no intermediate server is involved. If you use transport-based authentication, you can configure HTTP basic authentication or TLS client authentication.

Use basic authentication only with HTTPS because the credentials are sent as cleartext and are vulnerable to packet sniffing. TLS client authentication is more secure than basic authentication because a client certificate is signed.

Use SOAP message-based authentication (WS-Security) when security credentials need to flow in the SOAP message through a number of intermediaries. If you use SOAP message-based security, you can configure the CICS security handler to authenticate with one of the following types of token:
  • Username tokens that contain only a username.
  • Username tokens that contain a username and password.
  • X.509 digital certificate
  • ICRX token.

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

If other token types are used, you can configure the CICS security handler to call a Security Token Service (STS) or you can write a custom security handler to do your own, customized security processing.
Recommended: Use TLS to secure the connection to the STS.

For more information about the types of authentication token that can be used with CICS web services, see How it works: Authentication for CICS with SOAP message security .

In third-party authentication scenarios, SOAP-message authentication is often used along with transport-based authentication. The client’s identity is flowed in a SOAP security header and the intermediate server is authenticated by using TLS client authentication.

Do you need to implement different authentication mechanisms for different services or different types of client?
Instead of having a general rule for the application, the type of authentication mechanism can be decided for specific services. It might be appropriate to run read-only services with a generic user ID, where more sensitive services might need the requester to authenticate. In CICS, this split can be made by running secured services on a different pipeline to unsecured services.

Authorization considerations for web service provider security

Will you configure the CICS task in the web service provider to run with the RACF® user ID of the end user?
Configuring the CICS task in this way enables fine-grained authorization and auditing.
  • Where no intermediaries are used, CICS authorization processing can be based on the RACF user ID that is used to authenticate, or a RACF user ID that is associated with the security token that is used to authenticate.
  • Where intermediaries are used, CICS authorization processing can be based on the asserted RACF user ID or the distributed identity that is passed by the intermediary. CICS can resolve a distributed identity that is contained in an ICRX identity token to a RACF user ID.

Use Surrogate security to ensure that the intermediary has the correct authority to start work on behalf of the asserted identity.

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

Instead of configuring the CICS task in the web service provider to run with the RACF user ID of the end users, you can specify a RACF user ID in a URIMAP for the pipeline alias transaction.

If the web service does not need to be secured, requests can be allowed to run under the CICS default user ID.

Confidentiality and integrity considerations for web service provider 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 by using either the TLS support in CICS or AT-TLS. However, TLS does not ensure end-to-end message integrity or encryption because the message is not protected within intermediate servers, as illustrated in Figure 2.

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.

If SOAP messages do not contain critical data, or if the messages are only transmitted within an internal secure network, then it is reasonable to flow requests over non-encrypted HTTP connections.

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.

Trust considerations for web service provider security

How do you ensure that the intermediate server is a trusted server?
TLS client authentication can be used so that the intermediate server 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.
How do you ensure that the authentication token is trusted?
An authentication token, for example a SAML token, can be signed. The signature is used to verify the issuer of the SAML token and to ensure the integrity of the token.

6.3 Support for SAML using the CICS Security Token Service is removed as of CICS TS 6.3.

Audit considerations for web service provider security

Does the web service request need to be audited in CICS?
Typically, you need to capture the RACF user ID that is used for running the CICS task. This information is recorded in the CICS SMF in type 110, subtype 01 records. When identity propagation is used, the distributed identity from the ICRX is also recorded.
Will you create an audit trail in CICS or in an intermediate server, or both?
You might need an audit trail in all the servers that are involved in processing a request. IBM DataPower Gateway is an ideal place to capture audit information because it provides a configurable solution that supports multiple format log records that can be stored on the appliance or transferred off-device.

Review these design examples that offer different configurations.