How SAML Authentication Works, and Why It’s Still Relevant for Enterprise Customers

SAML 2.0 (Security Assertion Markup Language) is an open standard created to provide cross-domain single sign-on (SSO). In other words, it allows a user to authenticate in a system and gain access to another system by providing proof of their authentication.

While SAML has been in use since 2005, it remains popular for identity federation in B2B and B2E applications. This wide adoption has led to its self-perpetuating success. Generally, if you want to provide seamless SSO between businesses and enterprises, you need to be able to handle SAML. In fact, the SAML 2.0 protocol is mainly used for Enterprise and Government applications.

SAML uses XML to represent the user’s identity data and simple HTTP for data transport mechanisms.

In this article, we’ll go over what SAML is and what distinguishes it from other identity standards; we will also look at how an identity management partner such as Auth0 fits into the equation.

SAML is an XML-based authentication protocol in which Identity Providers (IdP) -- entities that manage and store user credentials -- exchange digitally signed XML documents (SAML Assertions) allowing an end-user to access a **Service Provider **(SP), such as the collection of apps that you use every day at work or a website.

The service requesting and receiving data from the Identity Providers (IdP) is known as the Relying Party (RP) and the user identity data, encapsulated in the SAML Assertion, is in the form of attributes, e.g,. email address, name, phone, etc.

A real-world analogy would be the international traveling scenario. Think of a traveler wishing to come from their home country to the USA. When they arrive at the border, they are asked for their passport in order to authenticate and possibly authorize their access. If the traveler has no passport, they are redirected to their home country's government to get one.

Once the traveler has their passport, they can prove their identity to the officers at the border. These check the passport validity and the identity data on it and decide to let the traveler come in or not.

In this scenario:

• the traveler's home country is the Identity Provider
• the officers at the border, representing the USA government, are the Relying Party,
• the USA as a country is the Service Provider
• the passport is the SAML Assertion

Consider that the USA accepts passports only from countries with which it has made preliminary agreements.

You can replicate this real-world scenario in a computer system.

Let's say you work in a company that has multiple applications, but a centralized point for user authentication. Let's say that a company partner has a similar organization, and for a specific project, a few partner's employees need to access one or more of your company's applications. Using SAML, after a preliminary configuration that establishes trust between the two systems, you can replicate the international traveling scenario.

The partner's employee tries to access one of your company's applications. Since that user doesn't belong to your company, your company's system redirects the user to the partner's system to get proof of identity. The partner's system authenticates the user and provides them with a SAML Assertion. Your company's system checks that assertion and lets the user access.

With SAML, the authentication workflow can be initiated by either the Service Provider or the Identity Provider. IdP-initiated authentication might occur if an employee is logged into their corporate dashboard and wants to use a company-purchased tool on an external site. In this case, the IdP would send a SAML assertion via the web browser to automatically log them in.

SP-initiated authentication occurs if an employee tries to log into that external site - the SP- and the site redirects them to their corporate Single Sign On (SSO) login page to enter their credentials and authenticate. After authentication, the employee is redirected back to the external site with a SAML assertion proving their identity.

Developers occasionally question why they should implement the SAML protocol. What makes SAML worth your time? As mentioned in this more technical tutorial, benefits include:

Standardization: Being an open standard, SAML makes systems interoperability possible.

User Experience: Users can access multiple Service Providers by signing in just once, without additional authentication, allowing for a faster and better experience at each Service Provider. This also centralizes password management issues such as reset and recovery.

Loose Coupling of Directories: SAML doesn't require user information to be maintained and synchronized between directories.

Increased Security: SAML provides a single point of authentication, which happens at a secure IdP. Avoiding credentials replication (shadow accounts) and synchronization, SAML reduces the points of attack for identity theft.

Reduced Costs for Service Providers: With SAML, you don't have to maintain account information across multiple services. The Identity Provider bears this burden.

Increased compliance: In the Data Privacy Era, the ability to receive attributes on the fly and forget them when they’re no longer needed reduces your organization’s liability — you no longer need to create shadow accounts to get work done

Developers can attest that attempting to implement SAML 2.0 in-house can be tricky, and it’s easy to inadvertently leave cracks in an XML signature and encryption that leave an app vulnerable to attackers. However, an identity partner like Auth0 can make SAML authentication both simple and secure.

Using Auth0 Universal Login, you can quickly configure SAML and offer it to your enterprise customers. When you use Auth0, you’re getting all the benefits of SAML but offloading the burden and risk of being the sole Identity Provider.

Auth0 can connect to any language or API. It can act as the Identity Provider, Service Provider, or both.

When you implement a SAML SP and are using Auth0 as an Identity Provider, users are redirected to Auth0 to log in, and Auth0 authenticates them. Auth0 is agnostic as to the authentication connection and can use social providers, databases, LDAP directories (such as Active Directory), or other SAML IdPs.

When your application needs to talk to a SAML SP using Auth0, Auth0 translates its requests into a SAML Authentication Request and forwards it to a SAML IdP. No matter the protocol you are using to talk with Auth0.

Using Auth0 as your IdaaS provider enables you to offer users multiple Identity Providers. This way, users from one organization can log in with their G-Suite credentials, while others can use a database connection.

For a SaaS business trying to attract enterprise customers offering SAML 2.0 in addition to other protocols, like OAuth and OpenID Connect, is a simple way to show you’re flexible enough to meet the needs of customers who have been using it for years.

Keep reading at our Intro to IAM page to explore more topics around Identity and Access Management.