Authentication using a Security Token Service
CICS® can interoperate with a Security Token Service (STS), such as Tivoli® Federated Identity Manager, to provide more advanced authentication of web services.
An STS is a web service that acts as a trusted third party to broker trust relationships between a web service requester and a web service provider. In a similar manner to a certificate authority in an SSL handshake, the STS guarantees that the requester and provider can "trust" the credentials that are provided in the message. This trust is represented through the exchange of security tokens. An STS can issue, exchange, and validate these security tokens, and establish trust relationships, allowing web services from different trust domains to communicate successfully. For more details, see the Web Services Trust Language specification.
CICS acts as a Trust client and can send two types of web service request to an STS. The first type of request is to validate the security token in the WS-Security message header; the second type of request is to exchange the security token for a different type. These requests enable CICS to send and receive messages that contain different security tokens from a wide variety of trust domains, such as SAML assertions and Kerberos tokens.
You can either configure the CICS security handler to define how CICS interacts with an STS or write your own message handler to use a separately provided Trust client interface. Whichever method you select, use SSL to secure the connection between CICS and the STS.
How the security handler calls the STS
- In a service provider pipeline
- In a service provider pipeline, the security handler supports
two types of actions, depending on the way you configure the security
handler:
- Send a request to the STS to validate the first instance of a security token, or the first security token of a specific type, in the WS-Security header of the inbound message.
- Send a request to the STS to exchange the first instance of a security token, or the first security token of a specific type, in the WS-Security header of the inbound message, for a security token that CICS can understand.
If the STS encounters an error, it returns a SOAP fault to the security handler. The security handler then passes a fault back to the web service requester.
- In a service requester pipeline
- In a service requester pipeline, the security handler can request
only to exchange a token with the STS. The pipeline configuration
file defines what type of token the STS issues to the security handler.
If the request is successful, the RACF ID is placed in the DFHWS-USERID container and the token is included in the outbound message header. If the STS encounters an error, it returns a SOAP fault to the security handler. The security handler then passes the fault back through the pipeline to the web service requester application.
The security handler can request only one type of action from the STS for the pipeline. It can also exchange only one type of token for an outbound request message, and is limited to handling the first token in the WS-Security message header, either the first instance or the first instance of a specific type. These options cover the most common scenarios for using an STS, but might not offer you the processing that you require for handling inbound and outbound messages.
If you want to provide more specific processing to handle many tokens in the inbound message headers or exchange multiple types of tokens for outbound messages, use the Trust client interface. Using this interface, you can create a custom message handler to send your own web service request to the STS.