SAML2 is a way to securely determine who a user is according to a previously agreed upon and trusted 3rd party. SAML is just one way to solve the problem of authenticating users without having to store or know their credentials (username/password). Oauth2 is another way of achieving a similar thing, but goes about it in a completely different way.

SAML is a type of Single Sign On (SSO).

In addition it is a way to get additional information aka attributes about the user.

An Analogy

Imagine Bob wants to convince Alice that he is indeed Bob but he doesn’t trust her well enough to show some piece of government ID, like a passport. One way they could resolve this is by Bob finding someone to vouch for him and his identity. For this to satisfy Alice it has to be someone that she also trusts and not just some stranger. Let’s call this trusted person Clive. Bob could go to Clive and say, ‘Will you vouch for my identity so Alice will talk to me?’.

Clive says, ‘Sure, I can do that. Here is a piece of paper’. Bob trusts Clive so he shows him his ID and in return Clive hands Bob this note:

Dear Alice,

I vouch that as of today, 2018-06-01 the bearer of this note is indeed Bob.
Furthermore here's some things you might like to know about Bob.
    * His date of birth is 1999-01-01
    * His email is bob@example.com.

Signed,

Clive

Bob takes this note and goes to Alice. He presents her with Clive’s note. But Alice is careful, she doesn’t just take the note at face value. Instead she checks the note carefully.

First she checks that she is indeed the intended recipient of the note. If the note was meant for someone else then she shouldn’t trust it.

Secondly she looks at when the note was written. If the note is old, there is a good chance that it has fallen into the wrong hands so she should be weary about trusting that the person presenting the note is the same person that Clive vouched for.

Thirdly she jumps to the signature. She compares the signature with a copy of Clive’s signature that she keeps for reference. If the signatures don’t match then she cannot trust that it actually came from Clive.

Now she is convinced that she can trust that the note came from Clive, is recent and was intend for her. She reads on to learn that the bearer is indeed Bob and she learns when his birthday is and what his email address is. She can proceed to interact with Bob with confidence without ever seeing his government issued ID.

How it works

In this example:

  • Clive acts as the Identity Provider. e.g. some web application like Twitter
  • Alice acts as the Service Provider e.g. OneLogin, Okta
  • Bob is the subject of the authorization request
  • The note is the SAML Response to the authorization request
  • Instead of being written in plain text, the note is actually an XML document
  • Instead of a hand signature, we use public/private key cryptography to sign the note
  • The facts about Bob are known as assertions and the details within them are attributes
  • Instead of physically transferring a note, the document is issued via http POST redirect

How does Alice know she can trust Clive

Alice needs to know ahead of time who Clive is and what his signature (public key) looks like in order to handle Bob’s request. This is achieved by sharing Clive’s Metadata (another XML file) with Alice ahead of time. It is the responsibility of the service provider account holder to set this up ahead of time as part of a SAML integration. This essentially says to Alice, ‘Look Alice, some people are gonna want to talk to you, but only trust them if Clive sent them’.

A word about encryption

You’ll notice that the note was signed but it was not encrypted in the example above. This means that anyone who intercepts the note from Clive before it reaches Alice can also read the note and learn something about Bob. This may or may not be a problem if the note contains personal information, like how many STIs Bob has. This is where encryption comes into play. SAML supports encryption of the entire document, or individual assertions within it. In this arrangement, Clive encodes his note with Alice’s public key so that only she can read it. This obviously requires that Clive be told about Alice’s public key ahead of time. This is usually achieved by sharing Metadata.

Initiation

There are two ways in which the process may be initiated. Firstly, Bob could go to Alice, and then Alice redirects him to Clive and then Clive redirects Bob back to Alice with the note. This would be Service Provider Initiated. Alternatively, Bob may begin at Clive, and be like ‘I want to go speak to Alice, can you vouch for me?’. In this case, Clive redirects Bob to Alice with the note. This would be Identity Provider Initiated and is the more common case. It is analogous to clicking an app icon in OneLogin or Okta and being taken straight to the application and signed in.