SAML 2.0: A Brief Conceptual Overview

This article provides a brief overview of SAML 2.0 — just enough to get an intuition about SAML’s high-level structure, but not enough to understand its subtleties. If you are new to SAML 2.0 and are trying to use it in your project, this might be a good place to start.

For additional details, you might want to refer to Security Assertion Markup Language (SAML) V2.0 Technical Overview by OASIS, which is an excellent reference for understanding the details of SAML 2.0.

Table of Contents:

— 1. Introduction
— 2. SAML Participants/Roles
— 3. Components of the SAML Standard
— — 3.1. SAML Assertions
— — 3.2. SAML Protocols
— — 3.3. SAML Bindings
— — 3.4. SAML Profiles
— 4. Conclusion
— 5. References & Further Reading

1. Introduction

At its core, SAML is a federated identity standard from OASIS that allows identity providers to share authentication and other security information about a subject (a user or a program) with applications (relying parties) that service the subject’s requests.

SAML is typically used when the identity providers (IdP) and the applications are on separate trust domains — either within a company or across multiple companies (business-to-business (B2B)).

Within an organization/company, SAML may be used by various internal applications (relying parties) to delegate user authentication to a central IdP, and to source additional details about the user for authorization and other purposes (as we’ll see later). Relying on an IdP frees up the relying parties from having to manage users’ identities, their attributes (such as user roles), and authentication. For the users, the main benefit is that they can use one set of credentials to access multiple applications, freeing them from having to set up and memorize credentials (such as usernames, passwords, etc.) for each application. Besides, if Single Sign-On is used, a user may login once and access multiple applications without having to login once per application.

Similarly, using SAML, third-party SaaS applications running available on the Internet may delegate authentication to the central IdP of the company. This a B2B usage scenario. In this case, the users not only use the same credentials to access multiple internal applications, but also external applications running outside the corporate network.

2. SAML Participants/Roles

Figure 1 below illustrates the key participants in a SAML interaction, namely a) the subject, b) the relying party, and c) the asserting party.

Note: It shows Active Directory Federation Services (ADFS) being used for enabling SAML for the application, but keep in mind that ADFS is just one of the many technologies available for doing so and that ADFS is not part of SAML itself.

Figure 1: Service Provider initiated Web SSO Example (Using ADFS)

The key participants involved in a typical SAML interaction are:

1. SAML Subject: The subject may be a person or a program and has an identity. The credentials of the subject, as well as other identity attributes, are managed by the asserting party/IdP.
2. SAML Asserting Party (AP): This is the party that makes assertions about the subject. As described later, assertions contain one or more statements about the subject.
3. SAML Relying Party (RP): This is the party/application that relies on the AP for authentication and uses assertions made by the asserting party about the subject, for authorization and other transactions.

A SAML AP is sometimes also called SAML authority or SAML responder [3]. In Federated Identity speak, it is often referred to as Identity Provider (IdP), or Claims Provider (CP). A SAML RP is sometimes also called a SAML requester. In Federated Identity wold, it is also called a Service Provider (SP) or Claims Consumer (CC). You’ll find detailed descriptions of some of these terms in this previous article about Federated Identity. In other words:

• Asserting party (AP) = Identity Provider (IdP) = SAML Responder = Claims Provider (CP)
• Relying party (RP) = Service Provider (SP) = SAML Requester = Claims Consumer (CP)

We’ll use the term Identity Provider (IdP) to refer to SAML asserting party (AP) in the rest of the article, as the term IdP more precisely represents the role of an asserting party in typical implementations, and is, therefore, easier to remember.

3. Components of the SAML Standard

The key elements of the SAML standard are: a) assertions, b) protocols, c) bindings, and d) profiles. The following subsections describe them briefly.

3.1. SAML Assertions

In SAML, the information about the subject is expressed in what is called assertions. Assertions are made by the IdP, and they contain one or more statements about the subject. The RP consumes the assertions.

Assertion statements can be of three types [2, 3]:

• Authentication statement: It states that the subject is authenticated using given means at such and such time. For example: “jdoe authenticated with a password at 6:00 AM”.
• Attribute statement: It states that the subject has such and such attributes. For example: “jdoe is a procurement manager with a $1000 spending limit”.
• Authorization decision statement: It states that the subject is authorized to perform an action. For example, “jdoe is permitted to buy office stationery”.

SAML v2.0 Executive Overview [4] — an OASIS document — explains the structure of the SAML assertion as follows:

The outer structure of an assertion is generic, providing information that is common to all of the statements within it. Within an assertion, a series of inner elements describe the authentication, attribute, authorization decision, or user-defined statements containing the specifics.

Figure 2: SAML Assertion Structure and Sample Values

The above depicts the logical structure of an assertion. An assertion can have statements of multiple types. SAML assertions are XML-encoded structures. See this example from Wikipedia to understand how this logical structure looks like physically when encoded to XML.

3.2. SAML Protocols

SAML Protocols can be used by relying parties to[5]:

• Ask the IdP to authenticate the subject
• Request the IdP to log out all sessions of the subject (“Single logout”)
• Request or query for assertions
• Etc.

Specifically, they define requests that relying parties and subjects should send, and responses that the IdPs should return, for achieving the goal of the interaction. See an example of an authentication request protocol here (Wikipedia).

3.3. SAML Bindings

SAML bindings describe how SAML protocols map onto supported messaging and communication protocols [3]. For instance, SAML SOAP binding explains how SAML messages are to be placed in SOAP messages.

3.4. SAML Profiles

SAML Profiles define the use of assertions, protocols and bindings to support a specific use-case, and constraints that apply to them.

SAML 2.0 has several profiles. Some of them are:

• Web Browser SSO Profile
• Assertion Query/Request Profile
• Identity Provider Discovery Profile
• Name Identifier Mapping Profile, etc.

When someone says my application/product supports SAML 2.0, a good question to ask back is, “which profile(s)?”.

To get an intuition of what a SAML profile looks like, you might want to explore the Web Browser SSO profile, which is perhaps the most commonly used SAML profile. It supports Web Single Sign-On (SSO), and supports use cases where you login to an IdP and are able to then access one or more applications/relying parties. A use-case that this profile supports is described in this OASIS SAML documentation. You might also want to look at the detailed description of the profile provided here.

4. Conclusion

This brings us to the end of this article. I hope you got a basic understanding of SAML 2.0. Of course, we only scratched the surface here, and there is a lot more to know about SAML 2.0 before you can get started with actually using it. If you’d like to know more about SAML 2.0 standard itself, I’d recommend you read up this article from OASIS.

Note that you don’t need to fully understand all the nitty-gritty of the SAML standard for being able to use SAML, especially if you are going to use SAML-based products like ADFS or Shibboleth for setting up IdPs and SPs. Most SAML products mask many of the SAML specification details. You can find a listing of SAML products here (Wikipedia).

In many cases, you’ll already have an IdP deployed in your environment that supports SAML 2.0, and you will want to make your application rely on the IdP for authentication and for fetching other identity attributes. To do so, you’ll need to make your application play the role of a relying party (RP)/service provider (SP) with the help of a SAML product.

5. References & Further Reading

1. https://en.wikipedia.org/wiki/SAML_2.0
2. http://saml.xml.org/assertions
3. http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html
4. SAML V2.0 Executive Overview, 2005, retrieved from here in December 2019
5. http://saml.xml.org/protocols
6. https://www.samltool.com/generic_sso_res.php
7. Rich Graves, “Implementing a Shibboleth SSO Infrastructure”, SANS Institute — Information Security Reading Room, November 2014