Security Assertion Markup Language (SAML) is an open standard that enables software systems to share security credentials across networks. It allows one system to perform certain security functions, typically authentication and authorization, on behalf of one or multiple other systems. The authentication process determines the user’s identity, while the authorization process determines whether the user has access rights.
This is a part of an extensive series of guides about Access Management.
SAML 2.0 is the current version of the SAML standard, designed to facilitate the exchange of authentication and authorization identities between security domains. It enables web-based, cross-domain single sign-on (SSO) to help minimize the authentication tokens used per user. This XML-based protocol uses security tokens with assertions to pass information about a certain principal (typically an end-user). The protocol passes this information between a SAML authority (Identity Provider) and a SAML consumer (Service Provider).
SAML 2.0 builds on several established standards:
SAML 2.0 was ratified as an OASIS Standard in 2005, replacing SAML 1.1. Many collaborators helped create it, including Liberty Alliance, which donated its Identity Federation Framework (ID-FF) specification to OASIS.
SAML single sign-on (SSO) is a mechanism that allows users to log into multiple web applications after initially logging in to an identity provider. Users only need to log in once, providing a faster and smoother user experience.
From the user’s point of view, SAML SSO is simpler and more secure. Also, some applications will not require credentials at all (provided the user signed in to the identity provider), enabling easier access. Another benefit of SAML SSO is that the IT admin team only needs to manage one password per user, which reduces the need to handle password reset and other account-related requests.
The following diagram illustrates how SAML SSO works. When users attempt to access a website or application that requires authentication, they are redirected to the SSO service, which integrates with an identity provider. Each user provides one set of credentials for any app, and the SSO authenticates them with the central identity provider. Typically, the user receives an authentication token that allows them to continue accessing the application without logging in again, until the token expires.
SAML SSO transfers a user’s identity from the identity provider to the service provider by exchanging digitally-signed XML documents. Here is an example of how this process works:
SAML defines XML-based protocols, profiles, bindings, and assertions. SAML Core is the general SAML assertion semantics and syntax. It includes the protocol used for requesting and transmitting assertions between system entities. It defines bare assertions and elements of SAML requests and responses. SAML is the transmission content (“the what” rather than “the how”).
The binding determines the mechanism of transmission. SAML Core defines “bare” SAML assertions along with SAML request and response elements.
SAML providers are the systems that enable users to access the services they need. The two main types of SAML providers are identity providers (IdPs) and service providers (SPs). Identity providers authenticate end-users to verify their identity and forward the user identity data and access permissions to service providers. Service providers require authentication from an identity provider to authorize a user and grant access to a requested service.
SAML flows are triggered when users initiate SSO processes on their browser. The two types of flows supported – IdP-initiated and SP-initiated flows. IdP-initiated flows involve the identity provider authenticating and redirecting the user to the service provider and the SAML assertions. SP-initiated flows involve the service provider redirecting the user to the identity provider for authentication, after which the IdP redirects the user back to the SP.
A SAML assertion is a message telling the service provider that a user has signed in. It contains all the necessary information for the SP to confirm the user’s identity, including the assertion’s source, the time of issue, and the conditions for the assertion to be valid.
SAML assertions are akin to a job reference, which includes details such as when a candidate worked with the referee, in what capacity, and for how long. Companies evaluate job candidates based on such references, allowing them to hire confidently. Likewise, SaaS applications and cloud services refer to SAML assertion to grant or deny access to a user.
SAML protocols describe how SAML elements such as assertions are packaged in SAML requests and responses. They provide the processing rules for SAML entities to follow when consuming or producing the specified elements. SAML protocols mostly act as simple request and response protocols.
Queries are the most important SAML protocol requests—service providers make queries directly to an identity provider via secure back channels. Query messages are usually SOAP-bound. The three query types corresponding to the three SAML statement types are authentication queries, attribute queries, and authorization decision queries. Attribute queries result in SAML responses containing an assertion, which contains an attribute statement.
SAML 2.0 significantly expands the protocol concept. Its core describes several additional protocols, including the assertion query and request, authentication request, artifact resolution, name identifier management, single logout, and name identifier mapping protocols.
SAML bindings map SAML protocol messages onto standard communications protocols or messaging formats. For instance, the SAML SOAP binding defines how SOAP envelopes, bound to HTTP messages, encapsulate SAML messages.
SAML SOAP is the only binding specified in SAML 1.1. However, there are implicit precursors to other bindings in Web Browser SSO, including the HTTP POST, HTTP redirect, and HTTP artifact bindings. While not explicitly specified, these bindings are available when used with SAML 1.1 Web Browser SSO.
The binding concept is more advanced in SAML 2.0, with bindings separated from the underlying profile. SAML 2.0 offers a new binding specification, defining several standalone binding options, such as the SAML SOAP (similar to 1.1), Reverse SOAP (PAOS), HTTP redirect (GET), HTTP POST, HTTP artifact, and SAML URI bindings.
SAML 2.0 thus offers greater flexibility. For example, with SAML 2.0 Web Browser SSO, service providers have four binding options (HTTP POST, HTTP, redirect, and two types of HTTP artifact bindings). Identity providers have three options (HTTP POST and two types of HTTP artifact bindings). In total, the Web Browser SSO profile has twelve deployment options.
SAML profiles provide detailed descriptions of how SAML protocols, bindings, and assertions come together to support specific use cases. The Web Browser SSO profile is the most significant example.
In SAML 1.1, there are two forms of Web Browser SSO: the browser/POST and the browser/artifact profile. The first profile passes assertions based on value, and the second profile passes assertions based on reference (which requires backchannel SAML exchanges over SOAP). Each flow begins with an IdP request, and there are proposals for proprietary extensions to standard IdP-initiated flows.
In SAML 2.0, there is a fully refactored Web Browser SSO profile. SAML 2.0 profiles use a plug-and-play binding design, making them more flexible than their SAML 1.1 equivalents. Each SAML 2.0 browser flow begins with an SP request—this increases flexibility but creates an IdP discovery issue.
New profiles introduced in SAML 2.0 include:
Both SAML and OAuth are federated identity management protocols, whose development was driven by the growth of software-as-a-service (SaaS) applications, and the need to integrate authentication platforms for improved management and security. The key difference between SAML and OAauth is that SAML handles the authentication process while OAuth handles authorization. In other words, SAML verifies the user’s identity and OAuth verifies the user’s access rights.
Both SAML and OAuth serve the following use cases:
Related: OAuth vs SAML
The Lightweight Directory Access Protocol (LDAP) is a lightweight software protocol that enables anyone on a network (whether public or private) to find data about organizations, individuals, and resources such as files and devices. LDAP and SAML SSO serve a similar purpose—helping users connect to IT resources. Both protocols are very widely used in the identity management industry.
Here are some of the key differences between LDAP and SAML SSO:
OIDC is an authentication protocol designed with web and mobile apps in mind. It’s designed to be easy to adopt and use, built as an extension of OAuth 2 that uses JSON formatted (JWT) data structures and a simple HTTPS transport flow.
It uses authentication tokens that are digitally signed and can be encrypted if needed. Traditionally SAML was the primary option for large enterprise and government identity verification. However, many large organizations are starting to adopt authentication systems based on OIDC.
Here are some of the key differences between OIDC and SAML:
With Frontegg, SAML authentication is available out of the box for any SAML provider. We took the SAML configuration experience to the next level by providing a complete self served drop-in Admin Portal for your end customers to configure the SAML on their own. From determining the SAML configuration, through the allowed domains all the way to self-served SAML claims mapping.
We believe that authentication and user experience must go hand in hand for best results. Don’t take our word for it. Check it out now.
Start For Free
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of access management.
Authored by Frontegg
