SAML Simplified

Learning a new technical topic is a journey, and the journey usually starts by seeking a high-level overview of what the technology is all about. Once this bird’s eye view is achieved and the basic concepts are internalized, more specific, relevant aspects of the technology can be delved into.

Most technical blog posts jump into the weeds of a topic, which is great for someone familiar with the topic, but not so much for a newbie. A lot of value could be delivered to many readers by just simply giving them a simple overview. There is definite value in the macro.

The goal of this post is to give you, the reader/SAML newbie, a high-level overview how SAML is setup and the life-cycle of a SAML request.

What is SAML

SAML is a standardized way of authenticating a user to a resource. The service that performs the authentication is known as the Identity Provider, or IdP for short. The resource being granted to is commonly known as the Service Provider or SP. The Identity and Service Provider are completely decoupled from each other.

The architecture of SAML offers a number of benefits:

  1. The Service Provider and Identity Provider do not need to directly talk to each other. In fact, both could be behind a firewall preventing all network communications between the two sides and things would still work.
  2. It supports Single-Sign On, meaning authenticating to a single IdP can grant access to multiple SPs.
  3. It is standardized and widely supported.

SAML Setup

Setup of SAML involves doing a configuration data exchange between the Identity Provider and Service Provider. Each side’s configuration data is encapsulated in an XML metadata file.

The IdP’s metadata file will typically include:

  1. Entity ID — a URL or URN that uniquely identifies the IdP.
  2. Single Sign On URL — the IdP endpoint that the SP should direct Single Sign On requests.
  3. Single Logout URL — the IdP endpoint that the SP should direct Single Logout requests.
  4. X.509 Public Key Certificate — the IdP’s base-64 encoded public key certificate, which is used by the SP to sign SAML authorization requests.

The SP’s metadata file will typically include:

  1. Entity ID — a URL or URN that uniquely identifies the SP.
  2. Attribute Consume Service URL — the SP endpoint where the IdP should direct SAML responses.
  3. Single Logout Service URL — the SP endpoint where the IdP should redirect to after performing single logout.
  4. X.509 Public Key Certificate — the SP’s base-64 encoded public key certificate, which is used by the IdP to sign SAML authorization responses.

Walking through a SAML Request/Response

  1. A user attempts to access the Service Provider.
  2. The SP determines that the user is not authenticated so it creates a SAML Authentication request, which it signs using the IdP’s Public Key (obtained through the metadata exchange). The request is HTTP redirected to the IdP Single Sign On URL.
  3. The IdP parses the request, verifies the signature using its private key, and authenticates the user.
  4. The IdP generates a SAML response, signs it with the SP’s public key, and redirects to the Attribute Consume Service URL.
  5. The SP verifies the response, including the digital signature using its private key, and allows the user access to the service.

Summary

This was a quick, high-level overview of SAML. I truly hope you found it helpful!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.