What's the difference between WS-Trust, OpenID, and SAML Passive?

Question

Seems that Microsoft ADFSv2 supports WS-Trust, and SAML Passive, but the WIF stack it's built upon doesn't support SAML.

What is the difference between WS-Trust and SAML-P? Do they share the same security vulnerabilities, if so what are they?

Note: There is a similar, but different question here:

SAML vs OAuth

Solution 1

I assume you're referring to [the newly released] ADFS v2?

Yes, ADFS v2 supports WS-Trust (and WS-Federation) and SAML2 passive, and WIF only supports WS-Trust (and WS-Federation) and not SAML2 (neither passive nor active).

WS-Federation uses WS-Trust to perform [browser based] passive federation, and is in many ways similar to SAML2 passive - and in many ways not. A significant difference between WS-Federation and SAML2 passive is that WS-Federation v1.1 (the new version supported by ADFS v2) supports automatic metadata discovery. You only need to provide a metadata endpoint (an URL) in WS-Federation, whereas in SAML you have to exchange metadata documents by some chose method (usb stick, mail, etc.).

I don't know of any actual security vulnerabilities in either protocol, but the approach to metadata exchange can be debated forever. The WS-Federation approach makes many things much easier, such as certificate roll-over, automatic updates, "for-free" automatic provisioning of new members in a federation, etc. However, the "manual" exchange procedure in SAML2 can at least in theory be made more secure.

As to why SAML support is not included in WIF, I can only speculate. A decent guess could be that someone wants sites using WIF to federate with an ADFS, and not directly with some other [third party] IdP :-)

Solution 2

From The SSO Academy, very simple difference,

Many people are confused about the differences between SAML, OpenID and OAuth, but it’s actually very simple. Although there is some overlap, here is a very simple way of distinguishing between the three.

OpenID – single sign-on for consumers
SAML – single sign-on for enterprise users
OAuth – API authorization between applications

Solution 3

An updated and corrected answer for 2015

• OpenID-Connect (or OIDC) - the new single sign-on protocol
  • Is OpenID version 3, not back compatible,
  • Built on OAuth technology
  • Uses JWT (for tokens, as well as the other JSON Web technologies and definitions)
• WS-Federation (or WS-Fed) - the old single sign-on protocol
  • Uses SAML for its tokens

Definitions:

• JWT - JSON definition for the security tokens (in OAuth and OIDC)
  • Pronounced like the word "jot".
• SAML - XML schema and definitions for the security tokens (in the WS-Fed )

---

OAuth

• OAuth - is the set of specifications for delegating authorization from the requesting application (the client) to an authorization service.
  • The authorized usage is given in a "scope"
  • The scope consists of a set of security "claims" and needed "resources"
  • The authorized scopes are returned in a JWT Resource Token
  • The tokens may be returned in several ways. The most common are:
    • Token returned directly: In implicit flow - used for browser based (javascript) applications
    • Token returned in two stages, after receiving an "Access code" - used for server based (REST or web API) calls.
  • In certain cases the human user is shown a UI to agree to authorize all or some of the requested "resources".
  • The tokens may contain the actual info, or be a reference to a server containing the info.

---

OIDC (Open ID Connect)

• Is started by requesting OAth scope with a claim of type OpenID-Connect
• The OP - OIDC provider is an OAuth server complying to the OIDC protocol
• An Identity Token is returned by the OP - the OIDC provider.
  • Identity tokens contain information (claims) about the user
  • In certain cases the human user will be shown a UI to authorize some or all of the requested information and resources.

See Travis Spenscer's OAuth and OIDC article - its an easy read.

If there are no corrections to this, please mark it as the answer. Thanks.

Comments

[makerofthings7]

Is the underlying encryption the same between SAML/WS-Fed? Is comparing SAML2 to WS-Fed better than SAML2 to WS-Trust? Which is more of an "apples to apples" comparison?

[Eugenio Pace]

Given that ADFS also supports SAMLP, it is more likely that the WIF team just didn't have the time to add (and test) that feature. WIF does have the extensibility points to add other protocols/token formats. Even Microsoft doesn't have infinite resources :-)

[Martin Strandbygaard]

@makerofthings7 SAML2 passive profile can be compared to WS-Fed wheras SAML2 active can be compared to WS-Trust (at least on a high level). As far as encryption goes, it depends on protocol configuration. Generally speaking, they support the same algorithms, and in practical terms, the platform (.Net, Java, etc.) will normally be the limiting factor, as they often don't support all the options allowed by the specifications. However, of the protocols "demand" encryption as such, though encryption is a good idea in some situations (e.g. for proof tokens or if privacy is a concern).

[Martin Strandbygaard]

@Eugenio Pace could be though I doubt it :-) However, MS seems to be opening up towards the idea of adding SAML2 support in WIF, as Vittorio has hinted at possible future support many times (even in his Programming WIF book). Given that the oiosaml.net OSS project provides excellent SAML2 support in .Net, the possibility is already there (and there are several paid options as well).