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.
WS-SecureConversation provides session-based security. Session-based security optimizes long message exchanges, as symmetric cryptography can be used to sign and encrypt the message. Typically, symmetric cryptographic algorithm is less CPU intensive than the asymmetric cryptography. Symmetric cryptographic algorithms should provide better performance and throughput when compared to the asymmetric cryptographic algorithms.
The symmetric cryptographic algorithm also provides a means to secure other session-based protocol and exchange patterns, such as Web Services Reliable Messaging (WS-ReliableMessaging).
Security context token for secure conversation
The Web Services Security specification defines the basic mechanisms for providing secure messaging. The Web Services Trust (WS-Trust) specification defines extensions to Web Services Security that provide ways to establish and broker trust relationships between two parties. The WS-Trust protocol defines the syntax of the request that can be sent to a security token service and the corresponding or subsequent response of the security token service. The security token service provided with WebSphere Application Server is called the trust service.
Use the WS-Trust protocol, a party can request the trust service issue a security context token (SCT). Then, this token can be used to establish a secure conversation (WS-SecureConversation). The request for a security token is sent to an application endpoint. The request is intercepted by the WAS and routed to the trust service.
A policy can be defined as the default for all trust issue operations, renew operations, validate operations, or cancel operations. Additionally, a policy can be attached to a specific URL and operation pair.
WS-SecureConversation defines extensions to allow security context establishment and sharing, and session key derivation, which allows contexts to be established and, potentially, more efficient keys, or new key material, to be exchanged. The WAS support for WS-Trust and WS-SecureConversation focuses on the issuing, renewing, validating, and cancelling of the security context token for secure conversation.
Policy set and bootstrap policy
In addition to describing these functions, the OASIS WS-SecureConversation draft submission describes multiple methods of establishing a secure session between the initiator and the recipient of the SOAP messages.
The bootstrap security policy is the security policy for the initiating party to acquire the security token for secure conversation from the trust service using a token-issuing WS-Trust or WS-SecureConversation protocol message. The policy set configuration consists of the security policy for communication with the application service, and the bootstrap policy for communication with the trust service.
If sharing of a policy configuration (using WS-Policy) containing the secure conversation bootstrap policy fails, it may be because the bootstrap request and response policies differ. The message part protection for the bootstrap policy must be the same for both request and response bootstrap messages, because a single policy is published for both request and response.
What is supported for Web Services Secure Conversation
The following list highlights some of the key functions supported in WAS. The list is not exhaustive.
- A security context token (SCT) established between the initiating party and the recipient party.
- The WS-SecureConversation operations supported on the security context token (SCT), such as Issue token, Renew token, and Cancel token. Validate token is supported using WS-Trust protocol.
- A derived key (explicit and implied)
What is not supported for Web Services Secure Conversation
The following list highlights some of the key functions that are not supported in WAS. The list is not exhaustive.
- WS-SecureConversation does not support establishing a security context through the security context token created by an external security token service (trust component). However, WAS supports an internal security token service.
- WAS does not support establishing a security context through the security context token created by one of the communicating parties and propagated with a message.
- WAS does not support amending a security context token.
- WAS does not support a client creating the security context token.
- WAS provides no support for exchange and negotiation.
Secure conversation scenarios
The following scenarios describe the WS-SecureConversation functions that WAS supports:
- WS-SecureConversation
This scenario is based on establishing a security context token with the recipient and using the derived key to sign and encrypt the message. It describes how to establish a security context using session-based security. Session-based security is where the flow of the initiator establishes the security context token using the WS-SecureConversation protocol with the recipient.
- WS-SecureConversation
with WS-ReliableMessaging
This scenario is a composite scenario that includes functions required for the composition scenario of Web Services Reliable Messaging (WS-ReliableMessaging), WS-SecureConversation, and WS-Trust. This scenario describes how to use WS-SecureConversation with WS-ReliableMessaging where the flow is similar to the previous scenario, but which is from the secure conversation prospective. However, the main difference is that the WS-ReliableMessaging sequence is secured with the security context token and scopes the WS-ReliableMessaging sequence to the security context token. This description focuses on the message exchanges that are using the security context token in the overall flow.
Related:
Web Services Secure Conversation
Language specification