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.

Comments

  1. Unknown3 April 2018 at 07:10

    agree, client want us to use saml, I am totally in a fog.
    don't know i am dealing with a vendor or a standard.

    ReplyDelete

Post a Comment

Popular posts from this blog

Lessons learned from a connection leak in production

We recently encountered a connection leak with one of our services in production.  Here's what happened, what we did and the lessons learned... Tests and Monitoring detected the issue (silently) Our automated tests (which run in production for this service) started failing soon after the incident occurred.  We didn't immediately realise since they just went red on the dashboard and we just carried on about our business.  Our monitoring detected the issue immediately and also went red but crucially didn't email us due to an environment specific config issue. The alarm is raised A tester on the team realises that the tests had been failing for some time (some time being 4 hours... eek!) and gets us to start investigating. Myself and another dev quickly looked into what was going on with our poorly  dropwizard  app.  We could see from the monitoring dashboard that the application's health check page was in error.  Viewing the page showed us tha...
Read more

How to connect your docker container to a service on the parent host

Recently I needed a docker container to access a service running on the parent host.  A lot of the examples on the internet were very close to what I needed, but not quite. First off, docker's documentation provided an example that (as far as I can see) doesn't actually work.  The following (I think) is meant to inject the src ip address of the parent host's default interface: $ alias hostip="ip route show 0.0.0.0/0 | grep -Eo 'via \S+' | awk '{ print \$2 }'" $ docker run  --add-host=docker:$(hostip) --rm -it debian What it actually does is inject the ip of the default gateway on the parent host which doesn't help us. Michael Hamrah 's blog details the " gateway approach " of getting the parent's host ip from within the docker container.  This works great, although I wanted to inject the ip on container run and not have that logic within my docker image. Inject the src ip of the docker interface I think the best ...
Read more

Client Side vs Server Side Session

Image
We recently looked at replacing our legacy session management system with a new one.  During this analysis, we came close to choosing a client side session but eventually concluded server side was better for us.  Here's why... Client side session In this model, all session state is stored in the client in a cookie.  The benefits of this are you don't need to worry about persisting and replicating state across nodes, session validation is lightning fast since you don't need to query any data store which means it's super scalable.  The session cookie must obviously be tamper proof (to prevent people creating a session of their choice) which is achieved by signing the cookie using asymmetric cryptography. The signing of a cookie value uses the private key, the validation uses the corresponding public key.  Our idea was to try and keep the private key as private as possible by storing it in memory only.  Each node (4 shown below) would create a new priva...
Read more