Thursday, May 6, 2010

WS-Trust with SAML vs. WS-SecureConversation

WS-Trust builds on the framework provided by WS-Security, defining SOAP based mechanisms for brokering trust relationships, requesting and returning security tokens.

WS-Security provides mechanisms for securing a single message in a one-way message exchange. Often interactions between a Web service and a consumer will result in multiple messages being exchanged. While each message could be secured in isolation, it is more efficient to establish some form of context that the Web service and consumer share and use that context to reduce the burden with respect to securing each message exchanged. WS-SecureConversation defines a Security Context Token [SCT] to perform this task.

WS-SecureConversation defines three ways to establish the SCT.

1. Security context token created by a security token service
2. Security context token created by one of the communicating parties and propagated with a message
3. Security context token created through negotiation/exchanges

In [1] and [2] the initiator establishes the security context token (SCT) 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.

In [1], the context initiator asks a security token service to create a new security context token - based on WS-Trust.

In [2], the initiator creates a security context token and sends
it to the other parties on a message using the mechanisms described in this specification and in WS-Trust.

Above explains all about the relationship between WS-Trust and WS-SecureConversation.

In otherwords, WS-SecureConversation uses WS-Trust to establish the SCT.

SAML is an XML-encoded framework for exchanging authentication, subject attribute and
authorization information.

Under the WS-Trust protocol we can add SAML Assertions under the wst:RequestedSecurityToken of the RSTR returned by the STS.

When you use SAML is WS-Trust, that is for identity propagation - When we use WS-Trust with SecureConversation, that is for establishing a SCT.

So, the question is when to use SAML with WS-Trust and when to use WS-Trust with SecureConversation.

If relying party service requires user attributes [claims] in addition to the authentication - then we can use SAML with WS-Trust.

If relying party service requires to establish an authenticated session with the client - then we can use SecureConversation with WS-Trust.



Can you please provide a sample policy file for [2] or [3]? I have seen many samples for [1] and can get that up and running easily. However, I am having trouble configuring my policy file for [2] and [3].

Steve Ash

Are these mutually exclusive? They seem orthogonal from your description-- or is that what youre saying?

Post a Comment