Difference between WS-Trust, WS-Fed and SAML 1.1/ 2.0 protocols

Question

What's the difference between WS-Trust, WS-Fed and SAML 1.1/ 2.0 protocols?

My understanding on these protocols gets confused when SAML is used as a security token in WS-Trust and WS-Fed protocols.

Interested in knowing in which scenario these protocols used and what makes them different. Your answers will be easy to understand if NO commercial product/ technology references used.

Hubbs

Answer 1

At a high level, WS-* protocols traditionally were used by Microsoft.

SAML-P (P for protocol) was used by the open source movement and hence Java.

WS-Fed has two profiles - active and passive. Active is for WCF (WS-Trust), passive is browser based (WS-Fed via login page).

Both of these use SAML tokens.

Functionally, both WS-Fed and SAML do the same thing wrt. federation

If you federate two ADFS (Microsoft IDP) together you use WS-Fed. If you add in Sharepoint, it also uses WS-Fed. The tokens passed are in the SAML token format.

If you have a Java application that uses Spring, then that will hook in to ADFS via SAML-P. The tokens passed are in the SAML token format.

Doubleton

Thanks. Is my understanding correct? 1. WS-Trust used for Active apps, WS-Fed used for Passive & Web-browser apps and SAML-P used for Web-browser apps only. 2. All these protocols could use SAML as security token. (SAML1.1 in WS-Trust & WS-Fed and SAML2.0 in SAML-P) – Hubbs

Pretty much. There are a large number of profiles in SAML-P - browser is just one of them. – Doubleton

My current company, Vouched, is looking for help on WS-Security and WS-Trust. Appreciate a pointer to a knowledgeable person. Thanks! – Rancourt

You can contact me on Twitter - same name! – Doubleton

Answer 2

this question is old but i struggled finding a correct answer online.

A lot of online posts say, that 'passive / browser' clients use WS-Fed and 'active / smart' use WS-Trust. That is probably because the active use case uses by default a url like '/ws-trust/2005' or '/ws-trust/v1.x/'. This does not seem to be 100% accurate. The great and free book: Claims-based Identity, Second Edition helped me with the issue and I finally found a satisfying answer:

The goal of many of these architectures is to enable federation with either a browser or a smart client. Federation with a smart client is based on WS-Trust and WS-Federation Active Requestor Profile.

These protocols describe the flow of communication between smart clients (such as Windows-based applications) and services (such as WCF services) to request a token from an issuer and then pass that token to the service for authorization.

Federation with a browser is based on WS-Federation Passive Requestor Profile, which describes the same communication flow between the browser and web applications. It relies on browser redirects, HTTP GET, and POST to request and pass around tokens.

SAMLP is just a different protocol when it comes to how things are communicated such as the redirection URL and so on, but the differences are not relevant (in most cases) and simply depend what the client supports (e.g. Java will use SAML). The biggest difference is in my opinion that SAMLP allows an Identity Provider initiated Use Case (which is the most secure one in my opinion), where the User starts on the Identity Provider (e.g. the Web Proxy of your ADFS Server, =Claims Provider in MS terms), instead of starting at the Web Service and then getting redirected to the Service Provider (=Relaying Party in MS terms). Also when we are talking about SAML we usually mean SAML 2.0 while WS-Fed uses SAML 1.x Tokens (and MS calls them Tokens, SAML calls them Assertion... its just a signed and possibly encrypted XML, I think theoretically you could use other Tokens in WS-Fed then SAML but i have never heard of anybody actually doing that).

Kinswoman