Numerous protocols facilitate Internet communications and interactions. In the identity and access management (IAM) space, protocols are used to exchange identity, authentication, and authorization information. One of these protocols is SAML (Security Assertion Markup Language). This article explores how SAML came about, what SAML is, and how this authentication protocol is used.

SAML: A brief history

The SAML standard was introduced in 2002 as an open standard by the Organization for the Advancement of Structured Information Standards (OASIS). 

SAML 1.0 was the first XML framework for exchanging authentication and authorization information. In 2003, SAML 1.1 was released. Ultimately, SAML 1.1 converged with the Liberty Alliance Identity Federation Framework (ID-FF) and Shibboleth. The OASIS standard, SAML 2.0, was released in 2005. One of the most notable modern use cases of SAML 2.0 is in higher education with the Shibboleth implementation. Shibboleth is widely used for single sign-on (SSO) across educational domains. SAML 2.0 continues to be used for B2B and B2E applications.

SAML terms of reference

Some of the terminology used when discussing SAML and SAML providers is:

SAML identity provider (IdP): The entity that verifies the user's identity. This verification is issued as a response to a request by a service provider.

SAML service provider (SP): When a user attempts to sign in to a service that supports SAML, the SP sends a SAML authentication request to the IdP. 

SAML assertions: A SAML assertion is in the form of an XML (Extensible Markup Language) document. The IdP returns this document to the SP on user authentication.

Attribute: Information used to identify a user with the IdP — for example,  a name or an email address. 

HTTP POST: An option in SAML execution. HTTP POST sends the SAML protocol messages as a POST parameter (known as a "binding option").

HTTP redirect: Another binding option. The SP redirects the user to the IdP, where the login happens; the IdP redirects the user back to the SP.

What is SAML 2.0?

SAML is based on XML, which is both machine and human readable. SAML uses XML as the basis for its identity data format. The XL document is typically digitally signed to improve security. SAML uses HTTP or SOAP as a data transport mechanism to exchange SAML messages. SAML is used to exchange authentication data between an IdP and an SP, using a series of request/response exchanges.

SAML supports federation and SSO. This allows SAML to facilitate the access of multiple apps with a single successful login. SSO improves employee productivity and streamlines access to the many apps and services enterprises use.

In a business context, the SAML protocol redirects the user who is logging in to a corporate app to an IdP after user credentials are entered in the login screen. Once the user credentials (such as a username and a password or a biometric identifier) are entered, the user is redirected to the SAML IdP, which verifies the user's identity. If verification is successful, the IdP then issues a SAML assertion, which is sent back to the app. The assertion is validated, and access is granted or denied.

What is SAML SSO?

SAML was designed to handle SSO. That is, SAML provides the mechanism that allows a user to log in to multiple federated apps or web services through a single login session. This provides fast access to corporate productivity apps and services — because a user has to log in only once. The result is uninterrupted productivity and a better employee experience. Help desk calls to recover accounts are reduced, as users no longer need to remember multiple passwords.

SAML can be complex to implement, and developers typically need to have specialist knowledge or use vendor options. Many vendors offer a SAML identity platform to support the use of SAML supporting service providers.

Read about the limitations of SSO.

SAML flow

SAML is a backend service. The steps below show a classic SAML flow based on an authentication request: 

1. The user navigates to an app or web page (the SP). 

2. The SP initiates a SAML request to identify and authenticate the user. 

3. The browser redirects to the IdP  with the SAML request.

4. The IdP receives the request.

   1. The IdP authenticates the user by prompting them for their login credentials. 

5. A SAML response is generated.

6. The browser redirects this SAML response back to the SP.

7. The SP verifies the digital signature and decrypts the SAML response.

8. If the user is successfully authenticated, the SP can release the resource.  

NOTES:

1. The SP and IdP are part of a trusted ecosystem. To establish trust, a SAML metadata document is exchanged between the two entities.

2. The user flow can be initiated by an IdP rather than using an SP initiated redirect flow.

SAML authentication

SAML 2.0 is used for authentication but not (typically) authorization. However, SAML can be used to create consent screens in a similar manner to those used in OAuth-based systems, like Google sign-in.

SAML assertion

A SAML assertion is an XML document. The SAML assertion is sent by the IdP to the SP on request during the user authentication process. There are three types of SAML assertion:

• Authentication: Verifies the user’s identity, and provides the user login time and the authentication method.

• Attribute: Data that provides information about the user, for instance, their name.

• Authorization decision: Whether the user is authorized to use a service.

SAML 1.x vs. SAML 2.0

The main differences between the two versions of SAML are:

Protocols

SAML 1 only supports protocol queries, whereas SAML 2.0 supports many new protocols. The enhanced support by SAML 2.0 includes assertion queries and requests, authentication requests, name identifier management and mapping, and a single logout profile.

SAML Bindings

SAML 1.1 only supports SAML SOAP binding. SAML 2.0 supports multiple bindings, such as reverse SOAP, SAML URI, and HTTP redirect bindings.

SSO

SAML 1.1 has limited SSO options. SAML 2 Authentication Request Protocol provides support for SP-initiated web SSO exchanges.

A detailed list of differences between SAML 1.1 and SAML 2.0 is hosted by OASIS.

Benefits of SAML 2.0

General benefits of SAML 2.0 include:

• SSO and improved end user experience: Access to multiple applications and web applications with one sign in reduces help desk calls for password reset and recovery.

• Security: SAML 2.0 is a backend system, which reduces the surface for insertion-based attacks. SAML can protect against brute force and phishing attacks by enforcing MFA (multi-factor authentication). SAML attributes are normally encrypted.

• Standardization: SAML 2.0 is a standard protocol supported by many vendors and services.

• Reduced Costs for SPs: The IdP manages end user accounts and credentials This reduces the overhead of identity management for an SP.

Alternatives to SAML

OpenID Connect (OIDC), an open protocol built upon OAuth, is SAML’s main rival. Both SAML and OIDC are authentication protocols. Both protocols support SSO.

SAML is an XML-based protocol, whereas OIDC is a JSON/REST-based protocol.

SAML is a backend system, designed only for Web-based applications, whereas OIDC supports native apps and mobile applications. Implementing SAML is more complex than implementing OIDC. For example, the use of encryption in OIDC outsources encryption to HTTPS or SSL, making it simpler to implement.

What is the SSO tax?

"SSO tax" is the term given to the practice of SaaS vendors charging more to access SSO capabilities. The argument goes that any company with five or more employees should have the benefits of SSO. However, vendors offering identity management tools often provide SSO only in a higher-tier, much more expensive version, effectively levying a burdensome “tax” on smaller organizations that also need SSO.

Read more on SAML vs. OAuth.