Security Assertion Markup Language (SAML) is an XML-based protocol that was developed to facilitate the exchange of authentication and authorization information between applications or entities.
The protocol was created in November 2002 by an organization known as OASIS (Organization for the Advancement of Structured Information Standards). OASIS still maintains the standard and the latest version of the protocol is SAML 2.0 (March 2005).
The SAML specification has multiple versions and use cases. For this series I will focus on the latest revision, SAML 2.0, and the web browser based single sign-on (SSO) use case.
Single sign-on (SSO) refers to an experience where a user, or ‘principal’, can move between applications that do not share session information, without having to reauthenticate to each individual application.
The framework provided by the SAML protocol is widely used to support a single sign-on (SSO) experience across web browser-based applications by integrating multiple applications with a common identity provider. The identity provider is responsible for maintaining a common user session/context, allowing a user to move between applications without having to reauthenticate to each individual service.
In addition to supporting a single sign-on experience between an institution’s resources, the SAML protocol provides a framework for ‘federated identity’ that can be used to provide SSO between distinct organizations.
The full SAML 2.0 specification can be downloaded from the OASIS website.
How Does it Work?
SAML web SSO applications typically fall in to one of two roles:
- Identity Providers (IdP) – The identity provider (IdP) is responsible for authenticating the user, establishing the SSO session and providing identity information to service providers.
- Service Providers (SP) – The service provider (SP) is responsible for protecting its resources and relies on information from the IdP to establish a user’s identity.
For example, an institution’s e-mail platform could be a service provider with user e-mails representing the protected resource. Users are required to authenticate themselves to the IdP before they can access their mailbox.
The IdP validates the user’s identity by authenticating user credentials, which could take the form of a username/password combination, an encrypted token, or some other method. The user authentication process is handled entirely by the IdP and is completely transparent to the SP. Once the user’s identity is established, the IdP collects any additional user information the service might need and sends the user back to the SP.
Upon receiving an ‘authentication success’ response, the SP evaluates the authorization identity information from the IdP’s response against its own internal access controls to determine what resources a user can access, if any.
It is possible for an application to function as both an IdP and an SP. This is common in an architecture where multiple IdPs are present and one IdP must delegate user authentication to another IdP that a trust has been established with.
Metadata
To establish the trust relationship between two entities, it is necessary to exchange some basic application information, such as application name, expected username format, supported protocols, endpoint URLs, etc.
This information is often collected into an XML-formatted document known as ‘metadata.’ The metadata document summarizes the application configuration details and describes how to interact with it.
Not all applications generate or consume metadata files. It may be necessary to create a service provider or identity provider metadata file for your application or it may be necessary to manually enter the values from a metadata file into a configuration file or administration console.
The format of the metadata document is governed by the SAML 2.0 metadata specification.
The full metadata specification can be downloaded from the OASIS website.
Assertions
The IdP and the SP applications communicate by exchanging XML-formatted messages that contain SAML 2.0 assertions. In web based SSO implementations, these messages are passed back and forth between the IdP and SP through the user’s web browser. This is accomplished by encoding the message contents into a HTTP response and issuing a redirect (HTTP code 302) to the browser, as illustrated below.
While there are multiple ways to initiate an SSO transaction in SAML 2.0, the most common is an SP-initiated authentication request. This occurs when a user attempts to access a SAML 2.0 protected resource without an existing SSO session. The SP generates an ‘Authentication Request’ assertion, encodes it in a message and forwards the user to the configured IdP to authenticate.
After authenticating the user, the IdP will generate an ‘Authentication Response’ assertion, encode the message and then redirect the user back to the SP with the assertion. The SP reads the assertion and determines whether the user should be permitted to access the requested resource.
Summary
- SAML 2.0 protocol supports authentication between identity providers and service providers.
- One of the most common use cases is web browser based SSO.
- Trust is established by exchanging application details, which often takes the form of metadata.
- With web browser based SSO, authentication request and response messages are transmitted through the user’s browser. The IdP and the SP do not need to communicate directly.
- These request and response messages consist of assertions, which contain details about the operation and/or the user.
- The IdP is responsible for validating user credentials and establishing the user’s identity. This process is unknown to the SP.
- Keep an eye out for the next post in this series – Working with SAML 2.0 Metadata, which will take a more detailed look at the format, types and key elements that make up a SAML 2.0 metadata document.
To learn more about how SIG can assist your efforts in SAML protocol, contact us to discuss more, or visit our website to learn more.
