Introduction to SAML

1. Introduction

Security Assertion Markup Language (SAML) is an open federation identity standard for exchanging authorization and authentication data between providers. The data can be shared between many SAML-enabled applications and security domains. Thus, SAML is mainly used for SSO purposes. In this article, we’ll dive deeply into SAML fundamental concepts. We’ll relate to the latest version SAML 2.0.

2. What Is SAML?

SAML is an XML-based markup language for sharing security data between an identity provider and a service provider. An identity provider is a party that authenticates the user and sends the user’s identity with its authorization level data to the service provider.

On the other hand, the service provider trusts the identity provider and allows the user to access the resources based on its authorization level. Therefore, SAML provides a standardized way of exchanging security data between providers.

SAML contains security assertions that are used by providers to make access-control decisions. Moreover, SAML can provide protocol messages, protocol messages bindings, and profiles. We’ll elaborate on them in later sections.

3. Workflow

As we’ve already noted, the main use case of SAML is SSO. Thus, the user can log in once and get access to many independent services without a need to log in separately to them. Let’s see an example of SAML workflow:

1. The user requests a resource from the service provider. The service provider performs security checks (for example, checks session cookie if exists). If security checks pass go to point 8. If not go to the next point.
2. The service provider redirects the request to the SSO service of the identity provider. It informs the identity provider that it’s a SAMLRequest using a query parameter. The parameter is a decoded and deflated <samlp:AuthnRequest> element.
3. The user agent performs the GET request on the redirected URL. The SSO service processes the AuthnRequest and identifies the user,
4. Next, the SSO service responds with an XHTML form, like below:

   <form method="post" action="some-action-url" ...>
       <input type="hidden" name="SAMLResponse" value="some-response-value" />
       ...
       <input type="submit" value="Submit" />
     </form>

   The value of SAMLResponse is an encoded <samlp:Response> element.

5. The user requests an assertion consumer service of the service provider with the XHTML form.
6. The assertion consumer service processes the XHTML form, creates a security context for the user, and redirects to the requested resource from step 1.
7. The user requests the resource again. Now, the valid security context exists, so the resource can be returned.
8. The service provider responds with the requested resource.

Now, let’s see a visual representation of the workflow:

To summarize, the service provider needs a security context from the identity provider to see if the user can access a specific resource. If the context is present, the resource can be returned immediately. Otherwise, a SAML-specified request is sent to the identity provider to create the security context.

With the security context, the user can access multiple services that trust this specific identity provider without having to log in separately.

4. Architecture

In this section, we’ll briefly introduce SAML elements. The full specification can be found on the official SAML Specifications page. Here, we’ll focus on four elements — assertions, protocols, bindings, and profiles. Those are the core elements that SAML can use.

4.1. Assertions

First of all, as we can read in the official specification:

An assertion is a package of information that supplies zero or more statements made by a SAML authority.

Assertion data is placed between the following tags:

<saml:Assertion ...>
   ..
 </saml:Assertion>

There are three types of SAML 2.0 assertion statements:

1. Authentication – inform the service provider that the specific user authenticated at a specific time using a specific authentication method.
2. Attribute – passes user’s related attributes to the service provider. An attribute is a name-value pair of data containing some information related to the user.
3. Authorization – informs the service user if the user can access the demanded resource.

An assertion can contain one or more of the above elements. Based on these elements, providers can perform control-access decisions.

4.2. Protocols

The second type of SAML element is protocols. They describe how specific elements should be packed and consumed within a request and response. SAML 2.0 provides a variety of protocols:

• Assertion Query and Request Protocol
• Artifact Resolution Protocol
• Single Logout Protocol
• Authentication Request Protocol
• Name Identifier Management Protocol
• Name Identifier Mapping Protocol

Each of the protocols is elaborated in the specification. Thus, we won’t go into the details here.

4.3. Bindings

The third important type of element is bindings. They inform about the mechanism and mapping of SAML messages. For example, a SAML message can be encapsulated in a SOAP envelope. SAML 2.0 provides several bindings:

• SAML SOAP Binding
• Reverse SOAP (PAOS)
• Binding HTTP Redirect (GET) Binding
• HTTP POST Binding
• HTTP Artifact Binding
• SAML URI Binding

4.4. Profiles

Last, but not least, there are SAML profiles. A profile represents how assertions, bindings, and protocols cooperate to handle a specific use case. We can read in the specification:

Generally, a profile of SAML defines constraints and/or extensions in support of the usage of SAML for a particular application – the goal being to enhance interoperability by removing some of the flexibility inevitable in a general-use standard.

There are a variety of SAML profiles, although the primary one is Web Browser SSO.

5. Conclusion

In this article, we talked about the SAML 2.0 standard. We described its workflow and core architecture. To sum up, the most important use case of the SAML standard is the SSO mechanism.