What's the difference between ADFS, WIF, WS Federation, SAML, and STS?

Question

These are numerous technologies and buzzwords used for single sign-on with Microsoft services.

Can someone explain ADFS, WIF, WS Federation, SAML, and STS (Security token service), including where and when each is being used.

Solution 1

From a big picture viewpoint:

Assume an ASP.NET browser-based application that requires authentication and authorization.

The application can roll its own or it can outsource it.

WIF is a .NET library that allows ASP.NET to implement this outsourcing.

It talks to an STS (ADFS is an instance of an STS) which authenticates against an identity repository and provides authorization information in the form of claims. An STS provides a set of signed, trusted claims.

The protocol used between WIF and ADFS is WS-Federation.

If the STS was Java based (e.g Ping Identity or OpenAM), then WIF would use the SAML protocol for communication. ADFS also supports SAML to enable federation.

(Federation e.g. allows a user in a Java oriented company A to access the ASP.NET application in a .NET oriented company B by authenticating against A's identity repository. Company A and company B trust each other in a federation sense.)

Solution 2

• ADFS (Active Directory Federation Services) - Off-the-shelf Security Token Service (STS) produced by Microsoft and built on Windows Identity Foundation (WIF). Relies on AD for authentication. Can be used in active (SOAP web services) or passive (web sites) scenarios and supports SAML tokens, WS-Federation, WS-Trust and SAML-Protocol. It can be used as an Identity Provider (against AD) or as a Federation Provider.

  http://technet.microsoft.com/en-us/library/adfs2(v=ws.10).aspx

• WIF (Windows Identity Foundation) - The .NET library used to drive claims-based authentication in .NET applications and relying parties. It can also be used as a WS-Trust client and to a build custom STS.

  http://msdn.microsoft.com/en-us/security/aa570351

• WS-Federation - A protocol used by relying parties and an STS to negotiate a security token. An application requests a security token from an STS using WS Federation, and the STS returns (most of the time) a SAML security token back to the application using the WS Federation protocol. This is usually via HTTP (GETs and POSTs and redirects). Contrast this with WS-Trust, which is completely web service-based.

  http://msdn.microsoft.com/en-us/library/bb498017.aspx

• SAML Tokens (Security Assertion Markup Language) - This is simply the XML format used for security tokens, that typically capture user information (claims) and other relevant security-related data (signatures, token issuer, etc). The token is used by the application to authenticate users and drive application behavior (e.g. authorization). SAML Security Tokens are signed for integrity and optionally encrypted so only RP and STS can see its contents. In ASP.NET web sites using WIF, the token is by default encrypted and chunked into cookies, but this can be changed.

  http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

• STS (Security Token Service) - As described above, the STS is the broker that sits between a relying party application and the user. An STS is an issuer of security tokens. "Issuer" is often a synonym of an STS. STSs are configured in two roles: as identity providers (IdP) when they authenticate users or as federation providers (FP) when they sit in the middle of a trust chain and act as "relying parties" for other IdPs. IdPs need a way of authenticating users. Some (like ADFS) use Active Directory, others use custom databases like SQL Server Membership (not ADFS). If the user properly authenticates, the STS will issue a security token.

  http://msdn.microsoft.com/en-us/library/ff650503.aspx

  http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.html#_Toc212615442

Hopefully this helps. There are a lot of concepts and pieces to understand in claims-based authentication. To get a full understanding, you should check out A Guide to Claims-Based Identity and Access Control.

Solution 3

This post is aimed at clarifying SAML Tokens, supported in ADFS 2.0, and SAML protocol, not supported until ADFS 3.0, the version of ADFS in Windows Server 2012 R2

1) The SAML protocol is not supported prior to ADFS 3.0

2) .net 4.5 based WIF applications require using the WS-Fed protocol and currently do not support SAML-Protocol

3) SAML Tokens are XML based. SAML tokens are supported in ADFS 2.0 and previous versions. ADFS 1.0. 1.1. and 2.0 only support the SAML Tokens, not protocol

4) If you are using WIF, WS-Fed (protocol) is required - so you could do the following:

SAML Protocol <---> ADFS <----> WS-FED <----> WIF (.net 4.5)

From Wiki:

• ADFS 1.0 - Windows Server 2003 R2 (additional download)

• ADFS 1.1 - Windows Server 2008 and Windows Server 2008 R2.

• ADFS 2.0 - Windows Server 2008 and Windows Server 2008 R2 (download from Microsoft.com)

• ADFS 2.1 - Windows Server 2012.

• ADFS 3.0 - Windows Server 2012 R2.

Comments

[Scott T.]

Overall good answer - note though that SAML is not "usually encrypted in a browser cookie". A SAML message is typically transported via request (POST or Redirect) parameter or SOAP, over TLS/SSL and has its message integrity (which is more often the concern rather than confidentiality) secured via digital signatures.

[Garrett Vlieger]

You're correct. I simply meant that in the WIF/ADFS/WS-Federation model, the SAML token ends up being persisted in the user's browser as an encrypted cookie.

[Tiffany Harry]

@Garrett Vlieger: Thanks for the explanation

[dthorpe]

SAML is not tied to Java. We use SAML in a lot of our .NET Windows services.