Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > 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 by 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 Advancement of Structured Information Standards (OASIS) 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 WS-Trust protocol to establish a security context token. The product supports both v1.3, and the draft version, of the WS-SecureConversation specification.
WAS 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 that is 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 
Exchange 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 that is 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 by 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 by 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 by 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.
Security context token
Interoperation with other WS-ReliableMessaging providers: use pattern
Secure requests to the trust service using system policy sets
Enable secure conversation
Web Services Secure Conversation Language specification