A brief introduction to SAML

 

SAML, or Security Assertion Markup Language, is an protocol used to exchange authentication and authorization data. It is XML based and allows the sharing of identity between multiple organizations and applications.

SAML is one of the fundamental cloud identity security standards.

The primary use case of SAML is Internet Single Sign On (SSO).

Disclaimer: I put these notes together pretty quickly, mostly for my own benefit and it is a work in progress.

There are many other, frankly much better, sources on SAML out there, including:

• Introduction to SAML 2.0
• SAML 2.0

And some videos:

OK, with disclaimers out of the way…

Example use case

Before we dive into the What or How, let’s start with the Why. Why would you consider using SAML?

Let’s say you work for a company called Acme Corp. As part of your work for Acme, you need to access a large number of apps out on the internet, such as email (e.g. from Microsoft Outlook online, or Gmail), CRM tools (e.g. Salesforce), expense report tools (e.g. Expensify or Concur) etc. You get the idea.

If you need to remember usernames and passwords to all those sites it is a) cumbersome and b) security vulnerability and c) hard for Acme to track.

So, instead Acme has a repository of user credentials for its employees, such as their usernames and passwords. In SAML terminology, this is called the Identity Provider, or IdP. These credentials could be stored in LDAP or in a database, for example.

SAML allows the owners of the apps you are trying to access (Service providers, or SPs in SAML terminology, and Google, Salesforce etc in the examples above) to redirect to an agreed IdP, which is ACME in this example.

This allows you to use your “company” credentials to access the apps, instead of using app specific credentials every time. In other words, you authenticate once against Acme’s credentials, and you then can access all supported apps using the concept of SSO.

 

SAML Terminology

There are 3 entities involved with SAML

1. User
2. IdP (Identity Provider)
3. SP (Service Provider)

The IdP is an organization that maintains a directory of users, and an authentication mechanism.
The SP is an organization that hosts an application, such as a SAS app, like a CRM.

The user has an account at the IdP and wants to use an application hosted by the SP.
The Idp and SP are related because they want to federate identities.

IdP

If the IdP is hosted locally at your enterprise, it provides that secure advantage that that user passwords never cross the firewall. Additionally, this brings a centralized point for AAA (access control, authentication, and accounting), and the security, risk and compliance benefits that brings.

 

How does SAML work?

The process works as follows:

• A users access the SP’s app, for example by going to www.theapp.com
• The SP asks for credentials.
• These crendentials are passed on to the IdP
• The IdP validates the credentials, and constructs a message about that user (a SAML token), which is passed back to the SP
• The SP creates a session for the user, allowing the user access to the app

This diagram from hungreyweasel shows the flow:

 

Downsides to SAML

SAML 2.0 is quite complex technology, and its specification is large and split over multiple documents. (The latest, at time of writing, is v2.0, approved as an OASIS Standard in March 2005).

Outstanding questions

Is it possible to use SAML for just Auth, without using SSO?

Tags: authentication, authn, authorization, authz, saml, singlesignon, sso