Enabling secure conversation
Use secure conversation to secure web services application messages.
Before you begin
Applications that contain web services must have been deployed.
About this task
The Organization for the Advancement of Structured Information Standards (OASIS) Web Services Secure Conversation (WS-SecureConversation) draft specification describes ways to establish a secure session between the initiator and recipient of SOAP messages. The WS-SecureConversation draft specification also defines how to use the OASIS Web Services Trust (WS-Trust) protocol to establish a security context token (SCT). For complete information, see the OASIS Web Services Secure Conversation 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 that is required to establish a secured context and to use session-based security.

- 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.
In the WS-SecureConversation specification, a security context is represented by the <wsc:SecurityContextToken> security token. The following example represents the assertion syntax for a <wsc:SecurityContextToken> element.
<wsc:SecurityContextToken wsu:Id="..." ...>
<wsc:Identifier>...</wsc:Identifier>
<wsc:Instance>...</wsc:Instance>
...
</wsc:SecurityContextToken>
The security context token does not support references to it by using key identifiers or key names. All references must either use an ID (to a wsu:Id attribute) or a <wsse:Reference> to the <wsc:Identifier> element.
WebSphere Application Server provides these pre-configured secure conversation-related polices:
- The SecureConveration policy set follows the WS-SecureConversation and WS-Security specifications and provides a policy set with secure conversation enabled and using keys derived from security context token for signing and encrypting the application messages.
- The Username SecureConversation policy set follows the WS-SecureConversation and WS-Security specifications and adds authentication using the Username token.
- The LTPA SecureConversation policy follows the WS-SecureConversation and WS-Security specifications and provides authentication using the Lightweight Third Party Authentication (LTPA) tokens.
In this example, the default SecureConversation policy set, and the default WS-Security binding and TrustServiceSecurityDefault binding are used to achieve the task of enabling secure conversation. The default SecureConversation policy set has both the application policy (symmetricBinding) and the bootstrap policy (asymmetricBinding). The application policy is used to secure application messages and the bootstrap policy is used to secure the RequestSecurityToken (RST) messages.
A trust service that issues a security context token is configured with the TrustServiceSecurityDefault system policy and the TrustServiceSecurityDefault binding. The trust policy is responsible for securing RequestSecurityTokenResponse (RSTR) messages. If the bootstrap policy is modified, the trust policy has to be modified to match both of the configurations.
The Web Services Security (WS-Security) default bindings that are used here contain sample key files and must be customized before use in a production. For the production environment, use of custom bindings is advised. Also note that, if the profile is created by using the choice of Create the server using the development template, you can skip steps 2 and 3.
To configure secure conversation, configure the policy set, and add a policy assertion to the policy, complete the following steps:
Procedure
Results
What to do next
Next, review the example scenario about how to establish a security context token to secure a secure conversation.