What is SAML?
SAML stands for "Security Assertions Markup Language". That should give you a hint that SAML is somewhat based on XML.
All those things I wrote about in part 1 of this series can be done using SAML.
SAML is a familiy of messages and protocols used to implement a identity federation system.
The bit about "messages and protocols" is important. If somebody talks about "SAML" they usually mean the combination of the message syntax and protocols - but in some cases (Microsoft did this in the past but they are cool now) SAML only refers to the message syntax (I'll briefly touch on WS-Federation at a later stage).
There is also a Wikipedia Article that you may want to have a look at.
Participants in a SAML system
There are generally three participants in a SAML transaction:
- Identity Provider (IDP, Asserting Party, the one that issues SAML assertions)
- Service Provider (SP, Relying Party, the one that trusts the IDP and consumes the SAML assertions)
- The Subject (somebody or something which likes to interact with the Service Provider and that can authenticate to the IDP and/or the IDP has profile information about)
Shortcut: The IDP tells the SP something about the the state of a Subject.
The first version was published in 2002 as a OASIS standard. The most common version (2.0) was published in 2005.
SAML 2.0 is especially important as it is a significant feature jump from 1.1. Two other standards (both based on SAML as well) were taken, mixed up and then published as SAML 2.0.
Note that SAML 2.0 - while derived from ID-FF 1.2 and Shibboleth 1.2 - is not compatible with those two. But that is hardly an issue nowadays ID-FF is history and Shibboleth implementations can fall back to SAML 2.0. SAML 2.0 is used for new deployments, and to be honest there aren't a lot of ID-FF or Shibboleth deployments out there anyway. If you are in an academic environment however Shibboleth is used quite a bit - but the rest of the world doesn't care that much.
Here is a diagram showing the history of SAML 2.0:
If you look at a SAML assertion and you are familiar with XML and some surrounding standards (such as XML Digital Signatures) you feel right at home.
Even with just some basic HTML knowledge you are able to read a SAML assertion and make sense of it.
Do you want a taste of how an assertion can look like?
Here is one:
<saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:assertion http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd" ID="_470ee542-ca32-11de-b313-cdf5016ad5a0" Version="2.0" IssueInstant="2009-11-05T17:40:15Z">
EwZDTkFNVFMxCzAJBgNV FAKE ==</X509Certificate>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">John Doe</saml:NameID>
<saml:SubjectConfirmationData NotOnOrAfter="2009-11-05T17:48:15Z" Recipient="http://myServiceProvider"/>
<saml:Conditions NotBefore="2009-11-05T17:38:15Z" NotOnOrAfter="2009-11-05T17:48:15Z">
<saml:AuthnStatement AuthnInstant="2009-11-05T17:26:50Z" SessionIndex="_470ee542-ca32-11de-b313-cdf5016ad5a0">
<saml:AttributeValue>Some kind of Manager</saml:AttributeValue>
It may look confusing but let's break this down into the important bits.
This is everything which helps the IDP and SP to establish trust (like digital signatures) and to control how the assertion is used. That's basically all the rest. Who issued it assertion? "TheBigFatIssuer". Who is it for? "www.service.provider.com". There is a digital signature plus the certificate. The assertion is also only valid within a time window "NotBefore" and "NotAfter" etc.
A SAML assertion will always contain for which subject (=user in many cases) this assertion is for. In the example above "John Doe"
This block may also contain information about how the IDP knows who the user is. For example: What authentication method was used? In the example "SmartCard" was used.
This block is (like many others) optional - it's not needed if the IDP tells the SP just about a user's profile updates.
What does the IDP know about the user besides who she is and how she authenticated? This could be anything else that is part of the user's profile. Address, telefone number etc. The example shows the John's title "Some kind of Manager".
The "What" is optional too - the IDP could just tell the SP that the user is logged on via SmartCard without providing more info about the subject.
The most common use case for SAML (authenticating to a SP) the "Who" and the "Controls" are present.
SAML Protocol, Bindings, Profiles
The SAML Protocol describes how the IDP and the SP and the Clients interact with each other to e.g. request an assertion or how an assertion is sent from A to B. This is like a blueprint of how the participants should interact.
There a number of "Bindings" - transport mechanisms - that tell how the protocol messages are transmitted. For example via a SOAP message, a HTTP POST or a HTTP Redirect.
Then there the combinations of the protocol and the different bindings: the Profiles.
The Web SSO Profile describes how a SP can tell a Subject to go to a IDP, the IDP to authenticate the user and then send the user with a SAML assertion back to the SP.
The next article will into details about the "Who" - how the IDP tells the SP for which Subject the assertion is about. It's not quite es simple as you may think.