Wednesday, 30 April 2014

SAML feels like a missed opportunity

"The nice thing about standards is that you have so many to choose from" - Andrew S. Tanenbaum

This quote is very appropriate for Single-Sign-On and specifically SAML.  Here I will discuss why SAML is a great protocol for point to point integrations, but can get very complicated very quickly once you take it beyond that.

Single Sign On - Why is it so hard?

Single Sign On (or SSO) can be described very simply, to quote wikipedia "...user logs in once and gains access to all systems without being prompted to log in again at each of them". This boils down to three different entities who trust each other directly and indirectly.  A user enters a password (or some other authentication method) to their identity provider (IDP) in order to gain access to a service provider (SP).  User trusts IdP, SP trusts IDP so SP can in-turn trust user.
This seems so simple, however if you are a service provider and want to integrate with many IdPs (e.g. twitter, facebook, educational institute, corporate institute, etc. etc.) the number of standards, protocols, frameworks, custom implementations involved make this very complicated.

I agree with Adrian Cockroft - you should favour open source where possible as it involves no procurement overhead.  With that in mind, we looked into open source options.  However, the problem here is that even the very best open source libraries are going to be very complicated when the problem domain is so complicated.

Companies that provide SSO solutions have a vested interest in presenting the complexities of integrating with many IdPs.  Before looking at open source options I was incredulous of these complexities, however I now find myself agreeing with their sales pitch having looked into the open source alternatives.

Protocols Standards and Frameworks


OAuth feels as new and shiny to me as the social media IdPs that use it.  However it's not a protocol, it's a standard.  Eran Hammer describes OAuth 2.0 as a "designed-by-committee patchwork of compromises".  All of this means "it's not possible to have a generic OAuth sign-in library that will work with any arbitrary site".

OpenID seems like a great idea, but it hasn't been adopted nearly enough to make it a success.  In fact, I only became aware of OpenID through writing this post - admittedly this might be more down to my poor background knowledge on this subject.

SAML on the other hand has a lot going for it...

  • It's a protocol - This obviously means that you can have a generic library that will work with any SAML compliant SP/IdP.
  • Federations make integrating with more than one entity easier - The UKAMF for example provides metadata for each institute member which standardise (and make discoverable) things like URLs, certificates and which specific SAML variants are supported.
  • It has been very widely adopted - Many educational institutes use it (almost all UK Universities for example).  It is also supported by the likes of google and salesforce.


SAML's biggest problem - it's too flexible

The User Flow is flexible.

A user can start his/her journey at the SP, where the user is re-directed to the correct IdP.  This sounds as simple as a 302 redirect but it is also necessary to instruct the IdP which SP to take the user to after authentication, this is achieved by adding an AuthNRequest within the request to the IdP.
A user can start his/her journey at the IdP (bypassing the AuthNRequest detailed above) which results in a unsolicited SAML assertion sent to the SP.  Why do we have to support both of these?

User Data can be sent in different ways

SAML Assertions (user specific data) can be sent from the IdP to the SP via the user's browser in three different ways called Bindings.  
  • HTTP POST Binding - The SAML assertion being submitted in the body of the request.
  • HTTP Redirect Binding - The SAML assertion is encoded as a URL parameter.
  • HTTP Artifact Binding - The user submits a reference to an artifact (via POST or GET) which is then resolved via a back channel.
Clearly, it would be far simpler to just support one of these (preferably not the HTTP Artifact Binding).

SAML assertions can be verified in different ways

An IdP can choose to sign their SAML assertions using Public Key Infrastructure (PKI) or by the direct key model.  The direct key model assumes that you have obtained the IdP's public key through a trusted means.  The UKAMF is currently in the process of dropping support for PKI which is certainly a step in the right direction.

What I'd like to see in future SAML specs

Less.  All of the flexibility included in the SAML spec makes it more complex, harder to implement and reduces its chances of becoming the de-facto standard for SSO.