What is SAML and what is it used for?
The Security Assertion Markup Language (SAML) is an open standard that allows security credentials to be shared by multiple computers across a network. It describes a framework that allows one computer to perform some security functions on behalf of one or more other computers.
Strictly speaking, SAML refers to the XML variant language used to encode all this information, but the term can also cover various protocol messages and profiles that make up part of the standard. Because SAML is an open standard, it can coordinate security measure for different applications and systems from different vendors. As a result, many security vendors use SAML as the basis for their commercial offerings to ensure interoperability.
SAML 2.0 was introduced in 2005 and remains the current version of the standard. The previous version, 1.1, is now largely deprecated. (SAMLDiffs has a great summary of the difference between the versions.)
What is single sign-on?
While SAML was designed with a wide range of use cases in mind, by far the most common one in practice is single sign on (SSO). SSO, as the name implies, allows a user to log in once and access multiple services—websites, cloud or SaaS apps, file shares, and so on. In an SSO scenario, all these services outsource their authentication and authorization functionality to a single system that then sends identity information about the user to those services.
Documents written in SAML are one way that single sign-on information can be transmitted. SAML’s open nature and interoperability make it a particularly attractive candidate for this role, since customers often want a single sign-on solution that can connect applications from multiple vendors.
Authentication vs. authorization
Before we move on, we need to discuss two different roles that SAML can play in an SSO system:
- Authentication: Determining that the users are who they claim to be
- Authorization: Determining if users have the right to access certain systems or content
Obviously any SSO platform will have to play both of these roles in order to do its job. One point of interest is that SAML doesn’t actually have to be used for both. For instance, Microsoft has an SSO implementation that uses SAML for authentication but OAuth (another open standard that we’ll discuss in more detail later in this article) for authorization.
What is a SAML provider?
In SAML lingo, a provider is an entity—generally, a server or other computer—within a system that helps the user access the services he or she wants, and that produce or consume SAML services. Generally speaking, the actual programs you want to get access to, like SaaS applications or protected file servers, are called service providers, while identity providers make sure the user really is who they claim to be or have the right to access the systems they’re trying to access—it provides authentication or authorization, in other words.
An important thing to keep in mind here is that the SAML standard itself does not define how these providers do their jobs; instead, it establishes what information they need to communicate to one another and how that communication and its flow are structured.
What is a SAML assertion?
A SAML assertion is the XML document by which all the information we’ve been discussing is transmitted from one computer to another. Once an identity provider has determined that you are who you say you are and have the right to access the content or services you’re interested in, it sends a SAML assertion to the server that actually can actually provide those services to you. A SAML assertion may be encrypted for increased security.
For more on all these terms, check out the official SAML glossary from OASIS.
How does SAML authentication work? A SAML flow example
This all might seem kind of abstract, so here’s a high-level example of how a SAML authentication transaction would play out. A graphical illustration is provided in Figure 1. The user agent would in most cases be a web browser.
Tom Scavo (CC BY-SA 3.0)Figure 1. A SAML authentication sequence
Imagine you’re the user in an environment with single sign-on and you’re trying to get access to some resource on a server. The sequence of events goes like this:
- You try to access the resource on the server. The service provider checks to see if you’re already authenticated within the system. If you are, you skip to step 7; if you’re not, the service provider starts the authentication process.
- The service provider determines the appropriate identity provider for you and redirects you to that provider—in this case, the single sign-on service.
- Your browser sends an authentication request to the SSO service; the service then identifies you.
- The SSO service returns an XHTML document, which includes the authentication information needed by the service provider in a SAMLResponse parameter.
- The SAMLResponse parameter is passed on to the service provider.
- The service provider processes this response and creates a security context for you—basically, it logs you in—and then tells you where your requested resource is.
- With this information, you can now request the resource you’re interested in.
- The resource is finally returned to you!
If you want a closer look at the guts of the messages being passed back and forth in a SAML transaction, check out the examples here from OneLogin. You can dig into the full XML code for the kinds of assertions being passed from the identity provider to the service provider in the scenario outlined above.
Implementing SAML
You’ll notice that a lot of this is pretty high level: for instance, there’s no explanation of how SAML knows what the appropriate identity provider is or how the identity provider determines that you’re who you say you are. That’s not just us leaving things out: as we touched on above, the SAML standard doesn’t define how these things happen, leaving vendors and implementors lots of leeway on how to set things up. Multiple technologies can be used for the actual authentication piece, and the technologies you choose will dictate the details of how you implement SAML in your environment. But no matter what choice you make, SAML assertions will carry authentication and authorization data from one provider to another.
Benefits of SAML authentication
The most important benefit of SAML as a foundation for an SSO solution is that it is an open standard. As we’ve seen, that means that it can be implemented by a wide variety of IAM vendors and integrated into all-encompassing systems like Salesforce. It also means that providers from different vendors can communicate with one another as long as they adhere to the SAML standard.
Because SAML is an XML dialect, it’s also very flexible. All kinds of data can be transmitted in a SAML document, so long as it can be rendered in XML.
SAML vs. OAuth: What’s the difference?
OAuth is a somewhat newer standard than SAML, developed jointly by Google and Twitter beginning in 2006. It was developed in part to compensate for SAML’s deficiencies on mobile platforms and is based on JSON rather than XML.
Other than SAML’s less-than-stellar mobile support, what’s the difference between the two? As we’ve seen, the SAML standard defines how providers can offer both authentication and authorization services. OAuth, on the other hand, only deals with authorization. OpenID Connect is an even newer standard, developed in 2014, that provides authentication services and is layered on top of OAuth.
Another major difference between SAML and OAuth is their use cases. While SAML theoretically was designed for use on the open internet, in practice it’s most often deployed within enterprise networks for single sign-on. OAuth, by contrast, was designed by Google and Twitter for internet scale.
SAML vendors
SAML is an open standard, and so anyone can create a commercial or open-source implementation that provides authentication services in line with it. In general, this functionality is built into an identity and access management (IAM) product, although that IAM functionality may in turn be bundled into a more all-encompassing system or infrastructure platform. Current providers include:
SAML tutorials: Some good places to learn more about SAML
Ready to learn more? Here are some great, in-depth SAML tutorials:
More on SAML and SSO:
Copyright © 2022 IDG Communications, Inc.
