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.
SAML is one way to implement single sign-on (SSO), and indeed SSO is by far SAML's most common use case. We'll start by discussing SSO to give you a sense of what SAML is used for, then dive into SAML's components and operations.
What is single sign-on (SSO) and what is it used for?
Single sign-on is a way for a user to offer a security token (such as a username/password pair) once and use it to gain access to multiple systems, platforms, apps, or other resources. It helps make things easier for users because they don't have to remember multiple logins and passwords, and it makes things easier for IT because they don't have to consolidate multiple services onto a single server. For instance, an organization might use SSO to allow users to log in to both proprietary web applications running on an internal server and a SaaS-hosted ERP system.
In order for SSO to work, a user must be able to authenticate once and receive authorization, based on his or her confirmed identity, to access multiple other computers. This can also work the other way: a single computer may provide services to users authorized on multiple other computers. The SAML standard defines how all these computers communicate with each other securely.
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.
What is an identity provider?
An identity provider is the entity within the system that makes sure the user really is who they claim to be — it provides authentication. It may also determine what services, if any, that user is authorized to access across various entities in the system. There are various implementations that can provide authentication services in line with the SAML standard — Salesforce can serve this role, for instance, and so can LDAP, RADIUS, or ActiveDirectory.
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 picture 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:
1. You try to access the resource on the server, which in SAML terminology is a service provider. The service provider in turn 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.
2. The service provider determines the appropriate identity provider for you and redirects you to that provider — in this case, the single sign-on service.
3. Your browser sends an authentication request to the SSO service; the service then identifies you.
4. The SSO service returns an XHTML document, which includes the authentication information needed by the service provider in a SAMLResponse parameter.
5. The SAMLResponse parameter is passed on to the service provider.
6. 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.
7. With this information, you can now request the resource you're interested in again.
8. The resource is finally returned to you!
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; whether you choose Salesforce, LDAP, or something else, the SAML assertions will then carry the information that you have in fact been authenticated from one provider to another.
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.
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 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:
- OneLogin outlines how to develop for SAML on five different Web development platforms.
- Amazon explains how to create a SAML identity provider for AWS.
- If you use ZenDesk, you can set up single sign-on using Active Directory with ADFS and SAML
- Learn how SAML can add SSO functionality to your Rails application
- Auth0 provides the nitty-gritty details on how SAML authentication works
More on SAML and identity management: