The Ins and Outs of SAML


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.

What Is SAML 2.0?

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:

  • Extensible Markup Language (XML)—SAML typically expresses exchanges in a standardized XML form. It is the basis for the name, Security Assertion Markup Language (SAML).
  • XML Schema (XSD)—SAML assertions and protocols are specified (in part) using XML Schema.
  • XML Encryption—SAML 2.0 uses XML Encryption to provide elements for encrypted attributes, name identifiers, and assertions. SAML 1.1 does not offer encryption. XML Encryption has significant security issues.
  • XML Signature—SAML (1.1 and 2.0) uses XML Signature-based digital signatures to authenticate and maintain message integrity.
  • Hypertext Transfer Protocol (HTTP)—SAML uses HTTP as the primary communications protocol.
  • Simple Object Access Protocol (SOAP)—SAML uses SOAP 1.1.

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. 


How SAML Authentication Works: A Sample Workflow

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:

  1. An end-user is logged into a system that serves as an identity provider. The user wants to log in to a remote application (the service provider).
  2. The end-user attempts to access the remote application via an intranet link or a bookmark, and the application loads.
  3. The application attempts to identify the end user’s origin via application subdomain, user IP address, or other methods.
  4. After the application identifies the origin, it redirects the end-user to the identity provider and asks for authentication. 
  5. The end-user can use an active browser session or establish a new one by logging in to the identity provider.
  6. The identity provider builds an authentication response—an XML document that contains the end user’s email address or username. Next, the identity provider uses an X.509 certificate to sign the document and posts this information to the service provider.
  7. The service provider retrieves the authentication response and uses the certificate fingerprint to validate the response.
  8. The end user’s identity is now established. The user is granted access to the application.

SAML In Depth: Concepts and Components

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

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

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. 

SAML Assertions

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

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

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

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:

  • SSO profiles (Web Browser SSO, Enhanced Client or Proxy (ECP), Identity Provider Discovery, Single Logout, Name Identifier Management).
  • Artifact resolution.
  • Assertion query/request.
  • Name identifier mapping.
  • SAML attribute profiles.

SAML vs OAuth 

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:

  • Improving user experience—both SAML and OAuth allow users to access multiple applications with a single sign-in.
  • Enhanced security—both SAML and OAuth enable IT admins to enforce SSO, strong passwords, and multi-factor authentication (MFA).
  • Centralized management of identities—both SAML and OAuth allow IT administrators to integrate and centralize authentication and authorization processes. This simplifies the onboarding process for new users and reduces maintenance overhead for identity management.

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:

  • LDAP is used for core directory services, SAML-based SSO enables centralized authentication for web applications.
  • LDAP is mainly focused on local authentication, SAML extends user credentials to the cloud and other web applications.
  • LDAP server implementations typically focus on trusted identity providers or identity sources. In SAML implementations, a SAML service is not always a trusted source of information, but acts as a proxy to a directory service and translates its authentication process into a SAML-based process.

SAML vs OpenID Connect (OIDC)

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:

  • Because OIDC is a relatively new protocol, it is lagging behind SAML in functionality. For example, it does not fully support dynamic specification of proxy identity providers. 
  • OIDC is easier to use than SAML and requires less processing (it uses JSON tokens instead of XML). OIDC can provide superior performance in many use cases, especially for applications that have basic identity data requirements.
  • OIDC is highly suited for mobile applications and single page web applications that are difficult to integrate with SAML.

SAML with Frontegg

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. Want to check it out? Start for free now.

Notify of
Inline Feedbacks
View all comments
image description image description

Open a free account.