What is SAML (Security Assertion Markup Language)?

Written by Sean Blanton on April 6, 2021

Share This Article

Updated on August 24, 2021

What is SAML? As IT continues to shift towards the cloud and Software-as-a-Service (SaaS) applications, SAML is becoming a hot topic. Let’s explore SAML, how it works, its history and benefits, and how you can use it.

What is SAML?

The Security Assertion Markup Language (SAML) protocol is the go-to for many web application single sign-on (SSO) providers used to connect users to web applications. SAML utilizes Extensible Markup Language (XML) certificates to assert user authentications between an identity provider (IdP) and a service provider (SP) or web application. That’s a lot of acronyms, but they will make more sense as we dive into how SAML works.

How SAML Works

The process of SAML is, in essence, a series of exchanges between the user, a service provider (who hosts the web application the user wants to access) and an identity provider (which is the means by which the user can authenticate). When a user wants to access a web application, they first visit the service via an ‘agent’, which is almost always a standard web browser like Chrome, Firefox, Safari, or Internet Explorer/Edge. The agent then attempts to request access from the SP by logging into the web application. 

The SP has been administratively set to defer its authentication to a specific source of authentication—the IdP or user database, if you will. Login is then securely re-directed via the internet (and through the browser) to request an authentication from the identity provider to verify the user’s identity. From the user’s perspective, this acts as a redirection to another website that contains a simple user interface with a username and password field. The user then enters their IdP credentials, which in turn verifies them against its own records. 

Upon successful verification, the IdP will generate an XML-based certificate, referred to as an assertion. This means the IdP is generating a figurative “hall pass”, claiming it knows the user and they may gain entrance to the application in question. This certificate is relayed back to the user’s browser and then on to the service provider, redirecting the page back to the service so it can ingest the “hall pass” and permit the user to enter. Note that in some more sophisticated flows, more data is returned by the IdP, including attributes, group membership, and more, to help the service provider accurately assign authorization rights as well as provide additional data that the SP may need to better serve the user.  

When broken down visually, the following diagram demonstrates the basic steps of this access transaction via the SAML protocol:

how SAML Works

The History of SAML

SAML was created by the Organization for the Advancement of Structured Information Standards (OASIS) in late 2002. By that time, the traditional Microsoft IdP Active Directory was hitting its stride, becoming one of the most widely used, on-prem directory services in the world. Its dominance made sense, as nearly every office was based around on-prem, Windows systems and applications, so managing them using a solution created by the same manufacturer was ideal.

Just before the creation of SAML, however, another innovation hit the IT scene in a major way: web-based SaaS applications. While they offered advantages by way of accessibility, collaboration, and productivity, SaaS apps had a drawback as well. The main conduit of user identity and access management for IT admins, Active Directory (AD) and the domain controller, worked best with on-prem applications.

Which is precisely why SAML was created: to help bridge that growing gap between AD and the expansive possibilities of the cloud. Because web applications weren’t Windows-based, nor on-prem, they required a different approach for authentication and authorization. The tried and true method of Kerberos that the domain controller leveraged wasn’t going to work well across the public internet. Thus, the creation of SAML.

Benefits of SAML

Besides the obvious one above, there are several other benefits to using SAML. One such benefit is that, because the process uses secure XML communication via SAML directly between the SP and IdP, end users do not need to remember all of the passwords necessary to access their various web apps. This means that end users only need a single set of credentials to access their applications – the same core credentials used by their IdP. They can create a single, strong password to secure their IdP credentials while not having to worry about keeping their web app passwords written out in a document, on a sticky note attached to their monitor or even have to leverage password managers to store credentials. In short, web-based single sign on (or SSO)

With only one identity to worry about for web applications (which can be secured through MFA and other techniques), IT admins generally experience a reduction in password-related help desk tickets in addition to increased security. SSO also reduces the risks of shadow IT, which is when users manage their own access to applications under IT’s radar. End users, having to only worry about a single password, experience less password fatigue with SSO as well.

Over time many SSO providers created web portals where end users could login once and then click on a tile with the application they needed to access. This further entrenched the idea of SAML into organizations. Not only did users not have to remember numerous passwords and IT admins could drive additional layers of security, but the end user experience was better as well.

The Underlying Question

While SAML brings many useful perks, looking at modern SSO solutions – almost exclusively focused on the SAML protocol – begs the question, “can using SAML alone really be called single sign-on?” After all, with the traditional addition of the SAML SSO model to user management, users still need to sign into devices (Mac, Windows, and Linux), networks, cloud infrastructure, on-prem file servers, apps, and more, and their SSO provider in order to access their resources. That’s a handful of passwords still required, which doesn’t really sound like a true single sign-on experience at all.

True Single Sign-On™ would extend beyond simply SAML, using an array of other protocols and authentication methods to extend one set of user credentials to virtually all resources. Thankfully, a next-generation cloud directory service is providing this True SSO experience for modern IT organizations.

True SSO with SAML and More From the Cloud

JumpCloud Directory Platform enables IT admins to manage their users and their access to systems, applications, networks, infrastructure, file servers, and more with just a single set of credentials. As a cloud IdP, JumpCloud has reimagined the partnership that exists between Active Directory and SSO for the modern era, providing practically all of the same capabilities and many others, all from a single cloud admin console.

JumpCloud leverages SAML, along with LDAP and RADIUS (and more), to provide a True SSO experience, meaning IT organizations can use one comprehensive solution instead of a host of others. Beyond that, IT admins can also use JumpCloud to implement Zero Trust security policies, such as multi-factor authentication (MFA), conditional access, password complexity, and more across their organization at scale. 

Try JumpCloud Free

You can experience True SSO with SAML, LDAP, RADIUS, and more yourself, just by simply signing up for JumpCloud Free. Your JumpCloud account automatically includes ten users and ten systems in the platform that you can leverage, and is absolutely free, no credit card required.

Want to dip a toe in before jumping right in? We also offer free, personalized demos of the platform to show you the ropes before you try JumpCloud for yourself. Please contact us if you would like to learn more or hit our in-app chat 24×7 during the first ten days to experience our Premium Support.

Continue Learning with our Newsletter