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

Question

It seems that Microsoft ADFSv2 supports WS-Trust and SAML Passive, but the WIF stack built on it does not 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

Answer 1

I assume you mean the [recently released] ADFS v2?

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

WS-Federation uses WS-Trust to perform browser-based passive federation and is very similar to passive SAML2 in many ways - and in many ways it is not. The significant difference between WS-Federation and SAML2 passive is that WS-Federation v1.1 (newer version supported by ADFS v2) supports automatic metadata discovery. You only need to specify the metadata endpoint (URL) in WS-Federation, while in SAML you need to exchange metadata documents using the selected method (USB-Stick, mail, etc.).

I do not know any real security vulnerabilities in any protocol, but the approach to the exchange of metadata can be discussed forever. The WS-Federation approach makes it much easier, for example, certificate switching, automatic renewal, “free” automatic provision of new members to the federation, etc. However, the “manual” exchange procedure in SAML2 can, at least in theory, be safer.

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

Answer 2

From SSO Academy , a very simple difference,

Many people are confused by the differences between SAML, OpenID, and OAuth, but it is actually very simple. Although there is some overlap, here is a very simple way to distinguish between three.

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

Answer 3

Updated and revised response for 2015

• OpenID-Connect (or OIDC ) - New Single Sign-On Protocol
  • This is an OpenID version 3 version that is not compatible with it,
  • Built-in OAuth technology.
  • Uses JWT (for tokens, as well as other web technologies and JSON definitions)
• WS-Federation (or WS-Fed ) - Old Single Protocol
  • Uses SAML for its Tokens

Definitions:

• JWT - JSON definition for security tokens (in OAuth and OIDC)
  • Pronounced as the word "jot".
• SAML - XML ​​Schema and Definitions for Security Tokens (in WS-Fed)

---

OAuth

• OAuth is a set of specifications for delegating authorization from the requesting application (client) to the authorization service.
  • Authorized use is indicated in the area
  • the area consists of a set of “ claims ” and requires “ resources ”
  • Allowed Areas Returned to JWT Resource Icon
  • Tokens can be returned in several ways. The most common are:
    • Token is returned directly: in an implicit stream - used for browser-based applications (javascript)
    • The token is returned in two stages after receiving the "access code" - it is used for server-based calls (REST or web API).
  • In some cases, the user-user demonstrates the user interface to agree to allow all or some of the requested "resources".
  • Tokens may contain actual information or be a link to a server containing information.

---

OIDC (Open ID Connect)

• Launched by querying an OAth scope with a requirement of type OpenID-Connect
• The OIDC OP provider is an OAuth server that conforms to the OIDC protocol
• The identity identifier is returned by the OP provider OIDC.
  • Identification marks contain information (claims) about the user
  • In some cases, the user will be shown a user interface to authorize some or all of the requested information and resources.

See Travis Spenscer OAuth and the OIDC article - it's easy to read.

If there is no amendment to this, mark it as an answer. Thanks.