[Article] Introduction to Security Assertion Markup Language 2.0

  • By Kasun Gajasinghe
  • 3 Feb, 2017

What is SAML and how it works

Since SAML is an open standard, you do not face vendor locking when using it for SSO. Simply put, with SAML, a user can login to one system in an environment, and then will be able access to other systems in that environment without needing to login again (until the web browser session is ended).

Let’s take a quick look at a popular use case of SAML - the SAML Web Browser SSO. There are three entities involved with SAML Web Browser SSO - Identity Provider (IdP), Service Provider (SP), and a principal (usually an end-user). The Identity Provider maintains a directory of users and an authentication mechanism to authenticate them. The Service Provider is the target application that a user tries to use. The principal must be registered in the IdP.

  1. User access the Service Provider with SAML secured application
  2. The SP sends a request to a pre-registered IdP for authentication. ‘samlp’ is the SAML 2.0 protocol namespace, ‘urn:oasis:names:tc:SAML:2.0:protocol’
  3. If user is not authenticated yet, IdP interacts with user to authenticate him/her
  4. IdP sends a response to SP with the token for the user

SAML 2.0 defines XML-based assertions and protocols, bindings, and profiles.

For more information on the usage of SAML watch our webinar on

Assertions

Assertions contains statements that the Service Providers use for access-control decisions. Assertions are usually requested from an Identity Provider by a Service Provider. SAML defines three types of statements.

  1. Authentication assertions - The assertion subject was authenticated at a given time via an authentication mechanism
  2. Attribute assertions - The assertion subject is associated with the supplied attributes
  3. Authorization decision assertions - A request to allow the assertion subject to access the specified resource has been granted or denied

Protocols

SAML protocol has evolved in three versions - 1.0, 1.1 and 2.0. SAML 2.0 has introduced considerable improvements and additions over SAML 1.1 and is not backward-compatible. SAML 2.0 core provides the following protocols.

  • Assertion Query and Request Protocol - Messages and processing rules for requesting existing assertions by reference or querying for assertions by subject and statement type
  • Authentication Request Protocol - When a principal/user wishes to obtain assertions containing authentication statements to establish a security context at one or more relying parties, it can use the authentication request protocol to send an message element to a SAML authority and request that it return a message containing assertions
  • Artifact Resolution Protocol - Provides a mechanism by which SAML protocol messages can be transported in an SAML binding by reference instead of by value
  • Single Logout Protocol - Provides a message exchange protocol by which all sessions provided by a particular session authority are terminated
  • Name Identifier Management Protocol - Provides a way to inform the service providers that the names and format of the subject or the issuer are changed
  • Name Identifier Mapping Protocol - To map identity of a user across different SPs with the consent of the issuing authority

Bindings

While the SAML protocols define what is being transmitted, there are several transport bindings that can be used to define how to transfer the data. Some of the popular bindings include - HTTP Redirect (GET) binding, SAML SOAP binding, and HTTP POST binding. The bindings supported by SAML 2.0 are outlined in the Bindings specification - SAMLBinding.

In the case of SAML SOAP binding, the SAML request is wrapped inside the body of a SOAP envelope and is transferred via http. In the case of HTTP POST binding, the SAML protocol messages are transferred via an HTTP post method using HTML forms with base64 encoded content. With HTTP Redirect binding, you can send the SAML protocols messages via HTTP GET requests by setting the message as a query string in the URL.

The HTTP POST binding can be composed with the HTTP Redirect binding and the HTTP artifact binding. Some usual scenarios are where the SAML is sent via the HTTP Redirect binding while the SAML is sent via HTTP POST binding. Since AuthnRequest is smaller in size, it can be included in the URL of the GET request. However, the SAML Response tends to be quite large, so sending it via the HTTP POST binding would be better.

Profiles

SAML profiles define the use of SAML assertions and request-response messages in communication protocols and frameworks. In contrast, the SAML assertions and protocols define the the SAML assertions and request-response protocol messages themselves, and the SAML bindings define bindings of SAML protocol messages to underlying communication and messaging protocols.

There are a vast number of SAML profiles defined in the SAML 2.0 Profile specification. But still the primary use case is the Web Browser SSO.

  • SSO Profiles
    • Web Browser SSO Profile
    • Enhanced Client or Proxy (ECP) Profile
    • Identity Provider Discovery Profile
    • Single Logout Profile
    • Name Identifier Management Profile
  • Artifact Resolution Profile
  • Assertion Query/Request Profile
  • Name Identifier Mapping Profile
  • SAML Attribute Profiles
    • Basic Attribute Profile
    • X.500/LDAP Attribute Profile
    • UUID Attribute Profile
    • DCE PAC Attribute Profile
    • XACML Attribute Profile

The following sub-sections describe the SSO profiles in detail.

Web Browser SSO Profile

In this scenario, a web user accesses a resource at a service provider (SP). The web user authenticates (or has already authenticated) to the identity provider, which then produces an authentication assertion. The SP then consumes the assertion and creates a security context for the user. This profile is implemented with the use of SAML Authentication Request protocol, and a binding as described above. A use case of this is described under the SAML use cases section named “Web based SSO with HTTP POST binding”.

Single Logout Profile

Once a user has authenticated to an identity provider, the authenticating entity may establish a session with the user. The identity provider may subsequently issue assertions to service providers based on this authentication event. In such a situation, the identity provider can act as a session authority and the relying parties as session participants. At a later time, a user may wish to terminate the session he or she started across all service providers. This profile is implemented with the use of SAML Single Logout protocol.

Identity Provider Discovery Profile

This profile defines a mechanism in a which a service provider can discover the identity providers that a principal is using with the Web browser SSO profile. When there is more than one identity provider, the service providers need to discover which identity provider(s) has a principal use. The discovery profile uses a cookie that is written in a domain that’s common to all the identity providers and service providers in a given deployment. The domain that the deployment predetermines is known as the common domain, and the cookie used for this purpose is known as the common domain cookie. This common domain cookie contains the list identity providers that the principal is using.

Enhanced Client or Proxy (ECP) Profile

An enhanced client or proxy (ECP) is a system entity that knows how to contact an appropriate identity provider possibly in a context-dependent fashion.

Name Identifier Management Profile

This profile defines a mechanism to manage principal/user identities that are exchanged between service providers and identity providers. With this profile, the identity providers can notify the service providers of a change in the format or the value that it uses to identify the principal. And, it enables service providers to create a unique alias for principals and notify the identity providers to use that alias instead of the actual principal name. The identity providers and the service providers can also use it notify the other provider that it no longer accepts messages from a particular identifier.

  
https://sp1.example.com.....

Code 1. Sample SAML 2.0 AuthnRequest request

Benefits of SAML

SAML brings a vast set of benefits, especially to medium to large scale environments where there can be thousands of users with several disparate applications. In a corporate environment or government institutions, the employees will be using internally developed applications. And, some companies expose several internet-based services to the public. For example, Google provides several public services such as Youtube, GMail, and Google Drive. It would be too much work if you have to create different accounts in each application, and have to login to each of these separately in order to use it. It will be more convenient and secure if you can introduce one identity to the user, and then do a one-time login for all applications (until a browser session ends). This has been possible due to the introduction of Single-Sign-On protocols like SAML.

Compared to other Single-Sign-On protocols like OpenId, SAML provides some significant advantages. One advantage includes the SAML 2.0 Single Logout profile, which allows users to sign-out from all applications conveniently. OpenId do not yet have a standardized mechanism for single logout, which could be a security risk. There has been a known issue in an OpenId authentication application
where even though user logs out from the application/service provider, another user can re-log-in as the previous user without having to authenticate. Issues like these are not evident in SAML.

Adding SAML-based web SSO is cost effective too. Currently, in larger companies, the help desk has to spend too much time on password-related queries from its employees. With SAML, except for the first authentication step, you can make the login to other applications transparent to the user. This also makes it possible to have one identity per employee with strict password requirements. This increases security by eliminating identity theft, and reducing possible data breach due to a weak password.

Some of the benefits of SAML are listed below

  • No vendor lock-in - Since SAML is an Open standard you can switch vendor without an impact to the user experience
  • User password never crosses the corporate firewall (in the case of IdP initiated SAML SSO)
  • Reusable - Several SPs can connect one IdP for authentication, and one SP can connect to several IdPs
  • Better accessibility
  • Eliminates additional credentials, which eliminates opportunities for identity theft
  • Eliminates phishing opportunities by reducing the number of times the user needs to log in
  • Eliminates the administration and development cost of implementing a proprietary SSO solution
  • Example uses of SAML

    Example 1) Single-Sign-On

  1. User logs in to mail at mail.example.com
  2. User got authenticated against an identity provider at idp.example.com
  3. The user now tries to log in to docs.example.com
  4. docs.example.com sends a samlp:AuthnRequest to the idp.example.com and asks to authenticate the user
  5. Since user is already authenticated, the idp.example.com sends a SAML assertion saying the user is authenticated
  6. docs.example.com let the user log in without asking for identity information again

Example 2) Authorization with SAML

  1. Administration officer at work.example.com wants to order a set of desktop machines from its official dealer at computers.example.com
  2. computers.example.com needs to verify whether the said officer is authorized to perform this operation, and assert the maxium spending limit
  3. computers.example.com sends a SAML assertion request to work.example.com to verify the above information
  4. work.example.com responds with a SAML assertion specifying the officer is authorized or not, and if so, his spending limit

SAML Use cases

Web-based SSO with HTTP POST binding

The following flow diagram shows a simple deployment of SAML 2.0 web-based Single-Sign-On using the HTTP POST binding for the Service Provider’s requests, and Identity Provider’s response.

  1. The principal requests a target resource at the service provider
  2. The service provider send a POST via user agent to the SSO Service at the identity provider
  3. The user agent issues a POST request with the SAML 2.0 AuthnRequest to the SSO service at the identity provider
  4. The SSO service validates the request and responds with a document containing an HTML form. The HTML form has a hidden parameter called SAMLResponse which contains the <samlp:Response>
  5. Request the Assertion Consumer Service (ACS) at the Service Provider. The <samlp:Response> is sent along with to the ACS
  6. The assertion consumer service processes the response, creates a security context at the service provider and redirects the user agent to the target resource
  7. The user agent requests the target resource at the service provider
  8. Since the user is authenticated, SP returns the resource to the user

Identity Implementations

WSO2 Identity Server (IS) provides support to SAML Web-based Single-Sign-On. WSO2 IS supports the Web Browser SSO Profile, Single Logout Profile, and the Basic Attribute Profile from the SAML 2.0 Profile specification. The IS documentation on SAML2-based Single-Sign-On feature provides detailed instructions on how to setup WSO2 IS as an Identity Provider (IdP), and the configuration that is needed to be done in the Service Provider (SP). Where applicable, all the products of WSO2 middleware comes with in-built functionality as a SP. So, WSO2 products can be configured to use the IS as the IdP in a simple two-step process. The documentation on this can be found here. In addition to SAML SSO, IS supports a wide variety of specifications, including OpenID, OpenID Connect, OAuth 2.0, SCIM, XACML, Passive Federation.

In addition to WSO2 IS, there are several other open-source and commercial solutions available for SAML 2.0 Web-based SSO. It includes - Shibboleth, PicketLink from JBoss, IBM Tivoli, Oracle Identity Management etc.

Check out a customer use case of the WSO2 Identity Server in our case study on

About Author

  • Kasun Gajasinghe
  • Senior Software Engineer
  • WSO2