Ingo Schubert

Introduction into Identity Federation Part 2

Blog Post created by Ingo Schubert Employee on Apr 8, 2016

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.

 

SAML History

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:

federationHistory.pngIn short: it was a bit of a mess for a while but all is good now. SAML 2.0 it is. WS-Federation is used sporadically but you are unlikely to find it used in cloud environments for example.

 

SAML Assertions

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">
<saml:Issuer>TheBigFatIssuer</saml:Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_470ee542-ca32-11de-b313-cdf5016ad5a0">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>qLq9x06+oW2m74pa5WpuRWpwJQc=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>WrEyMVpzsuvzSGhJeKQ8IoqcvmxFhtS8RMXPy0tXa6ZWeIAyFgA8LeOoA/sm/FNC
euT3E1B+aegtVI7jzbdHxqZ7uDvHV1swMeteWoHWR2vuzqpce6mhyMB9b/MMun0x
wo9JoLjXafotf3tuZgj2whNcvPEtra6e0ImfqfE9qUU=</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIID2DCCAsCgAwIBAgIBCjANBgkqhkiG9w0BAQUFADBUMSAwHgYDVQQDExdBQyBD
TkFNVFMgVGVzdCBTZXJ2aWNlczESMBAGA1UECxMJMTgwMDM1MDI0MQ8wDQYDVQQK
EwZDTkFNVFMxCzAJBgNV FAKE ==</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
   <saml:Subject>
     <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
John Doe</saml:NameID>
     <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches">
       <saml:SubjectConfirmationData NotOnOrAfter="2009-11-05T17:48:15Z" Recipient="http://myServiceProvider"/>
     </saml:SubjectConfirmation>
   </saml:Subject>
   <saml:Conditions NotBefore="2009-11-05T17:38:15Z" NotOnOrAfter="2009-11-05T17:48:15Z">
     <saml:AudienceRestriction>

          <saml:Audience>http://www.service.provider.com/sso/ACS</saml:Audience>
     </saml:AudienceRestriction>
   </saml:Conditions>
   <saml:AuthnStatement AuthnInstant="2009-11-05T17:26:50Z" SessionIndex="_470ee542-ca32-11de-b313-cdf5016ad5a0">
     <saml:AuthnContext>
       <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:SmartCard</saml:AuthnContextClassRef>
     </saml:AuthnContext>
   </saml:AuthnStatement>
   <saml:AttributeStatement>
     <saml:Attribute Name="title">
       <saml:AttributeValue>Some kind of Manager</saml:AttributeValue>
     </saml:Attribute>
   </saml:AttributeStatement>
</saml:Assertion>

 

It may look confusing but let's break this down into the important bits.

SAMLBlocks (1).png

 

Control

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.

The Who

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.

The What

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.

Outcomes