is
2017/02/03
3 Feb, 2017

[Article] Introduction to Security Assertion Markup Language 2.0

  • Kasun Gajasinghe
  • Senior Software Engineer - WSO2

What is SAML and how Does SAML Work?

Since Security Assertion Markup Language (SAML) is an open standard, you do not face vendor locking when using it for Single Sign On (SSO). Simply put, with SAML, a user can log in to one system in an environment, and can then access other systems in that environment without needing to login again, until the web browser session ends.

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 a user authentication mechanism. The Service Provider is the target application that a user attempts to use. The principal must be registered in the IdP.

The description below helps understand how SAML authentication takes place:

  1. Users access the SP with a 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 the user is not yet authenticated, theIdP interacts with the user for authentication
  4. The IdP sends a response to the SP with a token for the user

As illustrated in the above figure, 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 contain statements that Service Providers use for access-control decisions. Assertions are usually requested by a Service Provider from an Identity 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 as shown and elaborated below.

  • 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 a message element to a SAML authority and request the authority to return a message containing assertions.
  • Artifact Resolution Protocol - Provides a mechanism by which SAML protocol messages can be transported in a 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 method to inform service providers that the names and format of the subject or the issuer are changed.
  • Name Identifier Mapping Protocol - Used to map the identity of a user across different SPs with the consent of the issuing authority.

Bindings

While SAML protocols define what is being transmitted, there are several transport bindings that can be used to define how to transfer data. Examples of 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, users 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 include where the SAML AuthnRequest is sent via the HTTP Redirect binding while the SAML response 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 is preferable.

Profiles

SAML profiles define how SAML assertions, protocols and bindings can be used for a particular use case.

There are a vast number of SAML profiles defined in the SAML 2.0 Profile specification. But, the primary use case is 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 subsections 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 SAML 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.

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 which a service provider can discover the identity providers that a principal is using with the Web browser SSO profile. When there are multiple identity providers, the service providers need to discover which identity provider(s) is the principal. The discovery profile uses a cookie that is written in a domain common to all identity providers and service providers in a given deployment. The domain that the deployment predetermines is called the common domain, and the cookie used for this is called the common domain cookie. This common domain cookie contains the list of 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 a service provider and an identity provider. With this profile, identity providers can notify the service providers of a change in the format or the value that it uses to identify the principal. This also 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. Furthermore, the identity providers and service providers can use it to notify the other provider that it no longer accepts messages from a particular identifier.

  


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

Benefits of SAML

SAML brings a vast set of benefits, especially for medium to large scale environments where there can be thousands of users with several disparate applications. In a corporate environment or government institutions, 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 for each application, and have to login to each of these separately in order to use them. 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 SSO protocols like 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 enhances security by eliminating identity theft, and reducing possible data breach due to weak passwords.

Other benefits of SAML include:

  • No vendor lock-in - Since SAML is an Open standard, users can switch vendors without impacting the user experience
  • User password never crosses the corporate firewall (in the case of IdP initiated SAML SSO)
  • Reusable - Several SPs can connect to 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. A user logs in to mail at mail.example.com
  2. The user gets authenticated against an identity provider at idp.example.com
  3. The user now attempts 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 the user is already authenticated, idp.example.com sends a SAML assertion confirming the user is verified
  6. docs.example.com let the user log in without asking for identity information again

Example 2) Authorization with SAML

  1. An 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 asserts the maximum 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 whether the user authorization is successful or not, and if so, his/her 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 SSO using HTTP POST binding for the Service Provider’s requests, and the Identity Provider’s response.

Let us review what takes place in the above image,

  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
  5. The service provider requests the Assertion Consumer Service (ACS) at the Service Provider. The 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 SSO. WSO2 Identity Server supports the Web Browser SSO Profile, Single Logout Profile, and the Basic Attribute Profile from the SAML 2.0 Profile specification. The supporting documentation on SAML2-based Single-Sign-On feature provides detailed instructions on how to set up WSO2 Identity Server as a SAML Identity Provider (IdP), and the configuration that needs to be done in the Service Provider (SP). Where applicable, all the products of WSO2 middleware come with in-built functionality as a SP. So, WSO2 products can be configured to use WSO2 Identity Server as the IdP in a simple two-step process. The documentation on this can be found here. In addition to SAML SSO, WSO2 Identity Server supports a wide variety of specifications, including OpenID, OpenID Connect, OAuth 2.0, SCIM, XACML, and Passive Federation.

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

Check out a customer use case of the WSO2 Identity Server below
 

About Author

  • Kasun Gajasinghe
  • Senior Software Engineer
  • WSO2