WAS v8.5 > Secure applications > Secure web services > Secure web services > Administer Web Services Security > Administer message-level security for JAX-WS web services > Secure requests to the trust service using system policy sets > Enable secure conversation
Flow for establishing a security context token to secure conversations
This example scenario describes the flow of how the initiator establishes the security context token (SCT) using the WS-Trust protocol for session-based security with the recipient. After establishing the security context token, derived keys from the security context token are used to sign and encrypt the SOAP message to provide message-level protection. This examples focuses on the message exchanges using the security context token in the overall flow of the SOAP messages.
The Organization for the OASIS Web Services Secure Conversation (WS-SecureConversation) specification describes ways to establish a secure session between the initiator and recipient of SOAP messages. The WS-SecureConversation specification also defines how to use Web Services Trust (WS-Trust) protocol to establish a security context token. WAS v8.5 supports both v1.3, and the draft version, of the WS-SecureConversation specification.
WebSphere Application Server supports the ability of an endpoint to issue a security context token for WS-SecureConversation and thereby provides a secure session between the initiator and recipient of SOAP messages.
The following figure describes the flow required to establish a secured context and to use session-based security.
Figure 1. Displaying the flow between the client and the Web service and security token service
Exchanging messages between the initiator and the recipient
The following figure shows how the messages are exchanged between the initiator and the recipient to establish the security context token. The two WS-Trust protocols, RequestSecurityToken (RST) and RequestSecurityTokenResponse (RSTR), are used to request the security context token from the recipient endpoint.
The bootstrap policy is used to secure the RST and validate the RSTR request, which is typically different from the application security policy.
Figure 2. Using WS-Trust protocols RST and RSTR to establish the SCT between the initiator and the recipient
Scenario describing how to use secure conversation
Typically, to use secure conversation, the following steps are involved;
- The client sends a RequestSecurityToken (RST)
trust request for a security context token to an application endpoint with its secret
key (entropy and target key size) and requests the target service secret key.
This request is typically secured with asymmetric Web Service Security defined in the bootstrap policy.
- The RST is processed by the trust service and, if the request is trusted based on the security policy, the trust service returns
the security context token with the target service secret key using a WS-Trust RequestSecurityTokenResponse (RSTR).
This request is typically secured with asymmetric Web Service Security. The client verifies whether the RSTR can be trusted, based on the bootstrap policy.
- If the RequestSecurityTokenResponse is trusted, the client secures
(signs and encrypts) the subsequent application messages using the session keys.
The session keys are derived from secret of the security context token that is obtained from the initial WS-Trust RequestSecurityToken and RequestSecurityTokenResponse messages that are exchanged between the initiator and the recipient.
- The specification defines an algorithm of how to derive the key based on the initial secret. The target web service calculates the derive key from the metadata contained in the security header of the SOAP message and the initial secret.
- The target web service uses the derived key to verify and decrypt the message based on the application security policy.
- The target web service uses the derived key from the secret to sign and encrypt the response based on the application security policy.
- Repeat of steps 3 through 6 until the message exchange has completed.
Use keys that are derived from the secret of the security context token
After the security context token is established, the application messages are secured with message protection using keys that are derived from the secret of the security context token. The derived keys are used to secure the application messages by signing and encrypting the application messages. The security context token contains a UUID, which is used as identification of a shared secret. The token UUID can be used in the SOAP message to identify the security context token for the message exchanges. The secret must be kept in memory by the session participants (in this case the initiator and the recipient) and protected. Compromising the secret undermines the secure conversation between the participants.
Figure 3. Securing application messages with keys derived
from secret of the security context token
A similar scenario except with Web Services Reliable Messaging (WS-ReliableMessaging) is possible from the WS-SecureConversation prospective. See the example for establishing a security context token to secure reliable messaging.
Related concepts:
Security context token
Interoperation with other WS-ReliableMessaging providers: use pattern
Related
Secure requests to the trust service using system policy sets
Related information:
Web Services Secure Conversation
Language specification