Understanding Security Assertion Markup Language (SAML)

The Security Assertion Markup Language (SAML) provides two important features: cross-domain single sign-on (SSO) and identity federation. Many enterprises have adopted SAML 2.0 because it allows applications used by employees, customers, and partners to delegate user authentication to a centralized enterprise identity provider. The enterprise was now able to manage and control identities centrally.

A large enterprise customer might expect your application to support SAML 2.0 authentication.

SAML is an XML-based framework for exchanging security information between online business partners. With SAML, applications can delegate authentication to a remote entity known as an identity provider. Assertions with information about the authenticated user and authenticated events are returned by the identity provider to the application.

Similarly, if the user accesses another application that delegates authentication to the same identity provider, the user won’t have to log in again. It is referred to as single sign-on (SSO).

SAML also provides a mechanism for applications and identity providers to exchange information about a user using a commonly shared identifier. This is known as federated identity. The federated identity can use the same identifier across systems or it can use an opaque, internal identifier that is mapped to the identifier used by the user in each system.

SAML Terminology

SAML defines the following terms:

Subject — The entity about which security information will be exchanged.
SAML Assertion — Security information about a subject is contained in XML-based messages.
SAML Profile —Specification for using SAML messages for business use cases, such as cross-domain single sign-on.
Identity Provider — An identity provider is a server that issues SAML assertions about an authenticated subject, in the context of cross-domain single sign-on.
Service Provider — A service provider delegates authentication to an identity provider and relies on information about an authenticated subject in a SAML assertion issued by an identity provider in the context of cross-domain single sign-on.
Trust Relationship — An agreement between a SAML service provider and a SAML identity provider where the service provider trusts assertions issued by the identity provider.
SAML Protocol Binding — A description of how SAML message elements are mapped onto standard communication protocols, such as HTTP, for transmission between service providers and identity providers.

How SAML Works

One of the most common SAML scenarios is cross-domain web single sign-on. In this scenario, the subject is a user who wishes to use an application. The application acts as a SAML service provider. The application delegates user authentication to a SAML identity provider that may be in a different security domain. After authenticating a user, the identity provider returns a security token, known as a SAML assertion. The SAML assertion provides information about the authentication event and the authenticated subject.

Organizations owning service providers (applications) and identity providers exchange metadata in order to enable cross-domain web single sign-on. The metadata information includes URL endpoints and certificates for validating digitally signed messages. Messages can be exchanged between the two parties using this data. A trust relationship must be configured and set up between the service provider and the identity provider before the identity provider can authenticate users for the service provider.

As soon as the mutual configuration of providers has been set up, the service provider (application) redirects the user’s browser over to the identity provider with a SAML authentication request. A SAML authentication response message is sent back to the application after the identity provider authenticates the user. In the response, a SAML assertion is contained with information about the user and the authentication event, or an error is contained if an error condition occurred.

Application (Service Provider) Initiated SSO

A user visits a service provider (application).
The user’s browser is redirected to the identity provider with a SAML authentication request.
During authentication, the identity provider interacts with the user.
The user authenticates, and the identity provider validates the credentials.
With the SAML response, the identity provider redirects the user’s browser back to the service provider. The response is sent to the Assertion Consumer Service URL of the service provider.
As soon as the service provider receives the SAML response, it consumes and validates it and responds to the user’s original request.

Single Sign-On

In the previous section, we saw the user accessing a single application. It is possible for multiple service providers to delegate user authentication to the same identity provider. In this case, a user can access the first application and authenticate to the identity provider to establish an authentication session. By using the same browser, the user can access a second application relying on the same identity provider, and the identity provider will recognize the user already has a session and won’t ask them to authenticate again. With a successful SAML authentication response, the identity provider will simply redirect the user’s browser back to the application. This is called single sign-on.

Identity Provider Initiated Flow

The earlier section showed an interaction sequence with the user starting at the service provider. It is called SP-Initiated because the user initiates the interaction.

SAML also defined another flow, known as IdP-initiated flow where the user starts at the identity provider. Identity providers redirect the user’s browser to the service provider in this case without the service provider sending an authentication request. Enterprise environments with corporate portals use this flow when users access applications.

When a user first accesses the corporate portal, they are redirected to the corporate identity provider. Upon logging in, the user sees a menu of application links on the portal. Upon clicking one of these links, the user is redirected to the identity provider, with the application URL as a parameter. As in the SP-initiated case, the identity provider detects that the user already has an authenticated session and redirects the user’s browser to the application. In enterprises, the IdP-initiated flow with a portal is useful because it enables single sign-on and ensures users are directed to the correct URL for each application, which reduces the possibility of phishing.

A user visits a corporate portal.
The user’s browser is redirected to the identity provider with a SAML authentication request.
In order to authenticate the user, the identity provider interacts with the user.
Credentials are validated by the identity provider after the user authenticates.
A SAML response for the portal containing an authentication assertion is returned by the identity provider to the user’s browser. A list of applications is displayed to the user once the user logs into the portal.
An application link is clicked by the user in the portal. The user’s browser is directed to the identity provider with a parameter specifying the desired service provider application. IdPs check the user’s session.
The user’s browser is redirected to the service provider’s Assertion Consumer Service URL with a new SAML response.
Assuming the user’s identity and privileges are sufficient, the service provider renders an appropriate page for the user based on the SAML response and authentication assertion.

Identity Federation

In SAML, an agreed-upon identifier is used between a service provider and an identity provider to refer to a subject. It allows a service provider to delegate authentication to an identity provider and receive back an authentication assertion with identity claims that include an identifier for the authenticated subject that is recognizable by the service provider.

A service provider’s identity can be linked to an identity provider’s identity in different ways. Typically, the user’s email address is used as the identifier by both the service provider and identity provider, but this can be problematic since the user may need to change their email address, and it may conflict with privacy requirements. In a request, an identifier attribute can be dynamically requested, or a service provider can be configured to send an identifier. Users’ profiles can also be mapped on both sides by an opaque, internal identifier for the user, which can be used to exchange information between identity providers and service providers. Each federation has its own unique identifier, which prevents the correlation of user activity and protects privacy. When the two parties exchange metadata and configure their infrastructure, they establish a relationship (often called a federation in practice) between the service provider and the identity provider.

Authentication Brokers

Applications can easily support multiple authentication protocols and mechanisms with authentication brokers. In the event that you are building a new application that uses OIDC for authentication, you may receive requests to support SAML from business customers who wish to authenticate their users through their corporate SAML identity provider.

With an authentication broker, you can implement a newer identity protocol like OIDC and communicate with various identity providers via different protocols.

Summary

The SAML 2.0 standard provides an industry-standard solution for single sign-on and identity federation on the web. As a result of these key features, enterprises were able to use cloud applications and still maintain centralized control over their identities. By using SAML, users can avoid exposing static password credentials to applications and benefit from single sign-on convenience.

Compared to OIDC, SAML is an older protocol. Currently, modern applications built around APIs will benefit from implementing OIDC and OAuth 2.0, which support both authentication and authorization, respectively. Identity providers that support these protocols are available for both consumer and corporate scenarios.

References

Book — Solving Identity Management in Modern Applications