What is SAML?
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:
- Authentication: Determining that the users are who they claim to be
- Authorization: Determining if users have the right to access certain systems or content
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.
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 SAML used for?
SAML is one way to implement single sign on (SSO), and indeed SSO is by far SAML’s most common use case. 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 information can be transmitted.
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. Systems that provide or consume SAML services are generically called service providers; the most important kind of service provider is an identity provider.
We touched on what an identity provider does in the previous section: it’s the entity within the system that makes sure the user really is who they claim to be—it provides authentication, in other words. It may also determine what services, if any, that user is authorized to access across various entities in the system.
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:
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?
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.
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, which in SAML terminology is a service provider. 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 again.
- 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.
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: the SAML standard doesn’t define how these things happen, leaving IT lots of leeway on how to set things up. As noted above, for instance, multiple technologies can be used for the actual authentication piece, and the technologies you choose will dictate the details of how you actually 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 tutorials: Some good places to learn more about SAML
Ready to learn more? Here are some great, in-depth SAML tutorials:
More on single sign-on and identity management: