Single Sign On: WS-Fed and SAML

This is the second in the series of articles on authentication & SSO. The first one can be accessed here:
Back to Basics – Authentication & SSO

In this series we will look into the various protocols and mechanisms used for authentication. You might have heard of one or more or all of the following names:

• WS-Federation, SAML, OAuth, Open ID, Open ID Connect etc.

Well, what exactly are these? At a high level all these are federated validation mechanisms. But why so many protocols? Let us start by looking at two veterans in this area – WS-Federation & SAML (Sorry KerberosL)

Web Service Federation was created in 2003 as a part of the larger WS- Security Framework which includes WS-Authorization, WS-Trust, and WS-Policy etc.

First let us understand WS-Trust before looking at WS-Federation (as both are connected).
WS-Trust provides the foundation for federation by defining a service model, the Security Token Service (STS), and a protocol for requesting/issuing these security tokens which are used by WS-Security and described by WS-SecurityPolicy. STS model defined by WS-Trust is shown below:

To quickly explain this diagram, STS issues a token that is trusted by resource provider and hence requestor has to validate itself with STS to get a token and then ask the resource provider for a resource along with the claim/token. Hope that is not too short an explanation J

What if the requestor from one organization needs access to resource in another organization? Then as per WS-Trust, the requestor should validate itself to STS. But the STS doesn’t know this user as he is another realm. That’s where WS-Federation steps in. The objective of WS-Federation is to build on the STS model and make it extensible across realms i.e., cross-realm communication and interoperability.

It just extends the basic premise of WS-Trust (protocol & mechanism) across the realm boundaries.

The key component in WS-Federation is Federation Metadata (FM). FM is shared across STS by following the WS-Federation model for document format & discovery. Once that trust is established, then cross federation is achieved.

Summary: WS-Trust & WS-Federation provides a protocol for creating a token (Claims) based security model across resource providers and across organization boundaries. It does not enforce the token format but defines the request/response mechanisms of the protocol. What token to send, what to include in the token, how to establish cross federation trust etc. are not covered in detail but direction setting is provided thereby making the protocol more generic.

Security Assertion Markup Language (SAML) is very similar to WS-Federation and is an older protocol compared to WS-Fed. The approach in protocol, the metadata, sign-out, authentication types etc. are very similar in both protocols. In fact WS-Fed in most cases, uses a SAML Assertion token which creates even more confusion! The key here is that SAML from a protocol perspective is similar to WS-Fed but SAML also has a token format. SAML token is a data format for exchanging identity and access information across parties. SAML token is basically a collection of XML tags. SAML tokens have versions and not every SAML token version is compatible with every protocol. For example, WS-Fed 1.3 (protocol) uses SAML 2.0 (token type) and SAML 1.1 (protocol) uses SAML 1.1 (Token type) and so on!

I know…I know… I was here to simplify things and now I’m confusing the heck out of you right? J

Let’s move on from SAML as a protocol to SAML as a token. What exactly does this XML token contain?

It contains the following:

1. Who issued the token

• Issuer & signature

2. The Assertion

• The subject for whom this token is issued (principal name)
• Any other attributes (key-value) that defines the subject
• How long is this token valid
• Who is this token intended for? (Audience)
• How was the client authenticated? (Password, Multi factor etc.)

Since this is the key piece of a token I am including a snippet of an assertion below:

<saml:Assertion Version=”2.0″ ID=”_e91ef7a4-98eb-46d7-9542-c9a32fa2c9a4″ IssueInstant=”2013-05-28T00:18:47.025Z”>

<saml:Issuer>https://test.ilink.com/Authset/SSO/Trust/site</saml:Issuer>

<Signature>

<!– snip –>

</Signature>

<saml:Subject>

<saml:NameID>ratheeshc@ilink-systems.com</saml:NameID>

<saml:SubjectConfirmation Method=”urn:oasis:names:tc:SAML:2.0:cm:bearer”>

< saml:SubjectConfirmationData NotOnOrAfter=”2017-01-28T08:18:47.025Z” Recipient=”https://login.salesforce.com” />

</saml:SubjectConfirmation>

</saml:Subject>

<saml:Conditions NotBefore=”2017-01-27T16:18:47.025Z” NotOnOrAfter=”2017-01-28T22:18:47.025Z”>

<saml:AudienceRestriction>

<saml:Audience>https://login.salesforce.com</saml:Audience>

<saml:Audience>https://saml.salesforce.com</saml:Audience>

</saml:AudienceRestriction>

</saml:Conditions>

<saml:AuthnStatement AuthnInstant=”2017-01-28T00:18:47.025Z”>

<saml:AuthnContext>

<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>

</saml:AuthnContext>

</saml:AuthnStatement>

<saml:AttributeStatement>

<saml:Attribute Name=”DisplayName”>

<saml:AttributeValue>Ratheesh KrishnaGeeth</saml:AttributeValue>

<saml:Attribute Name=”Location”>

<saml:AttributeValue>Atlanta</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

</saml:Assertion>

3. Finally, there is a signature to prevent tampering. This signature can apply to the assertion, the message shell, or both.

Summary: SAML as a protocol is very similar to WS-Fed. SAML also has a XML token mechanism which gets signed and sent to the relying party. SAML tokens has multiple versions and they are used by different protocols to send tokens.

A final point – SAML & WS-Fed are similar protocols and the decision to use is dependent on your specific requirements and organizational environment. For example, if you are in a Microsoft ecosystem using Active Directory, ADFS etc. it supports both WS-Fed and SAML but Microsoft was one of the pioneers of WS-* hence it’s a bit easier to configure WS-Federation. Also from a developer standpoint, Windows Identity Foundation (WIF) was developed by Microsoft to enable building claims aware .NET application on top of WS-Fed protocol. It provides developers with the ability to build STS & claims aware application. But there is a catch here – fast forward to Azure era, WS-* is not something that Microsoft uses on its cloud architecture. We will come to that in the next blog.