Enable secure conversation
Use secure conversation to secure web services application messages.
Applications containing web services must have been deployed.
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 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
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.
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 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 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 following steps are to be used only in development and test environments.
The Web Services Security (WS-Security) default bindings 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 using the choice of Create the server using the development template, we can skip steps 2 and 3.
To configure secure conversation, configure the policy set, and add a policy assertion to the policy...
- Make a copy of a default secure conversation policy so we can customize the policy set for our own environment.
- Launch the console, and click Services > Policy sets > Application policy sets.
- Select the check box next to an existing policy set that follows the WS-SecureConversation specifications. For example, you might click the check box next to SecureConversation. This policy set is one of the pre-configured secure conversation-related application policy sets that is listed in the table. The SecureConversation policy set has a bootstrap policy to match the default policy set for the trust service to issue and renew tokens.
- Click Copy.
- Enter a unique name for the new copy of the SecureConversation application policy set. For example: CopyOfSCPolicySet
- Optional: Change the description, as needed, for the customized version of this policy set.
- Attach the policy set and binding to the application.
- Click Applications > Application Types > WebSphere enterprise applications > application name.
- Click either Service provider policy sets and bindings or Service client policy sets and bindings to attach resources to the CopyOfSCPolicySet policy set. The general binding is assigned automatically as the default.
- We can use the Attach Policy Set and Assign Binding menu lists to select a different policy set or binding.
Results
After completing these steps, you have configured secure conversation.
What to do next
Next, review the example scenario about how to establish a security context token to secure a secure conversation.
Subtopics
- Web Services Secure Conversation
Web Services Secure Conversation (WS-SecureConversation) provides a secured session for long running message exchanges and leveraging of the symmetric cryptographic algorithm.
- Scoping of Web Services Secure Conversation
Web Services Secure Conversation supports two scoping mechanisms: the default and the JAX-WS client service level.
- Secure conversation client cache and trust service configuration
For both distributed and local clients, the WAS secure conversation client cache stores tokens on the client.
- Derived key token
After establishing the security context and after the secret have been established (authenticated), derived keys can be used to sign and encrypt the SOAP message to provide message level protection. We can then use derived keys for each key used in the security context.
- Enable secure conversation in a mixed cluster environment
When Web Services Security applications using secure conversation run in a mixed cluster environment, an interoperability property must be set for the WAS v8.5 nodes.
- Enable distributed cache and session affinity when using Secure Conversation
WebSphere Application Server provides message-level protection in a cluster environment. We can use Web Services Secure Conversation (WS-SecureConversation) for message-level protection of Java API for XML Web Services 2.0 (JAX-WS) Web services in a cluster environment.
- 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.
- Flow for establishing a security context token to secure reliable messaging
This example scenario includes functions required for the composite scenario of Web Services Reliable Messaging (WS-ReliableMessaging), WS-SecureConversation, and WS-Trust. The scenario describes how to use WS-SecureConversation with WS-ReliableMessaging, the scenario is described from the WS-SecureConversation perspective.
- Enable the distributed cache using synchronous update and token recovery
To support secure conversation in a cluster environment, the distributed cache stores the shared state information. Version 7.0 and later of WAS uses MBeans to improve synchronous update of the cache across the cluster. In addition, persistent token support is provided by storing the token data in a database.
- Configure the token generator and token consumer to use a specific level of WS-SecureConversation
Use the console to configure the token generator or token consumer to use a specific level of the WS-SecureConversation OASIS specification standard. Select one of the two levels of token types supported: Secure Conversation Token v200502, or Secure Conversation Token v1.3.
- Web Services Secure Conversation standard
Web Services Secure Conversation (WS-SecureConversation) is a proposed Organization for the Advancement of Structured Information Standards (OASIS) standard that defines mechanisms for establishing and sharing security contexts, and deriving keys from security contexts, to enable a secure conversation.
Related concepts
Flow for establishing a security context token to secure conversations Flow for establishing a security context token to secure reliable messaging Security context token SecureConversation default policy sets Interoperation with other WS-ReliableMessaging providers: use pattern
Related tasks
Secure requests to the trust service using system policy sets Example: Install a web services sample with the console Enable secure conversation
Related information:
Web Services Secure Conversation Language specification