SAML Explained: How This Open Standard Enables Single Sign-On
What is SAML?
The Security Assertion Markup Language (SAML) is an open standard that allows security credentials to be shared by multiple computers on a network. It describes a framework that allows a computer to perform certain security functions on behalf of one or more other computers:
- Authentication: Determine that users are who they say they are
- Authorisation: Determine if users have the right to access certain systems or content
Strictly speaking, SAML refers to the variant of XML language used to encode all of this information, but the term can also cover various messages and protocol profiles that are 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 obsolete. SAMLDiffs has a great summary of the difference between the versions.
What is SAML used for?
SAML is a way to implement single sign-on (SSO), and indeed SSO is by far the most common SAML use case. Single sign-on, as the name suggests, allows a user to log in once and access multiple services: websites, cloud or SaaS applications, file shares, etc. In an SSO scenario, all of these services outsource their authentication and authorization functionality to a single system, which then sends user identity information to those services. Documents written in SAML are one way to convey information.
What is a SAML provider?
In SAML jargon, a provider is an entity, usually a server or another computer, within a system that helps the user to access the services he wants. Systems that provide or consume SAML services are generically referred to as service providers; the most important type of service provider is a identity provider.
We talked about what an identity provider does in the previous section: it is the entity within the system that makes sure that the user is who they claim to be, in other words, they provides authentication. It can also determine which services, if any, this user is authorized to access through various system entities.
SAML is an open standard, so anyone can create a commercial or open source implementation that provides authentication services that conform to it. Typically, this functionality is built into an identity and access management (IAM) product, although this IAM functionality can in turn be bundled into a more comprehensive infrastructure platform or system. Current suppliers include:
What is a SAML assertion?
A SAML assertion is the XML document by which all of the information we have discussed is passed from one computer to another. Once an identity provider determines that you are who you say you are and that you have the right to access the content or services that interest you, it sends a SAML assertion to the server that can actually provide you these services. A SAML assertion can be encrypted for added security.
To learn more about all of these terms, see the OASIS Official SAML Glossary.
How does SAML authentication work?
This might all sound a bit abstract, so here’s a high-level example of how a SAML authentication transaction would play out. A graphic illustration is provided in Figure 1. The user agent would in most cases be a web browser.
Imagine that you are the user in a single sign-on environment and trying to access a resource on a server. The sequence of events is as follows:
You try to access the resource on the server, which in SAML terminology is a service provider. The service provider checks if you are already authenticated in the system. If you are, go to step 7; if you are 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 required by the service provider in a SAMLResponse parameter.
- The SAMLResponse parameter is passed to the service provider.
- The provider processes this response and creates a security context for you, basically, it logs you in and then tells you where the requested resource is.
- With this information, you can now request the resource you are interested in again.
- The resource is finally back to you!
If you want to take a closer look at the guts of the messages exchanged in a SAML transaction, check out the examples here from OneLogin. You can dig into the full XML for the types of assertions passed from the identity provider to the service provider in the scenario described above.
You’ll notice that a lot of this is pretty high level: for example, there’s no explanation of how SAML knows which Identity Provider is appropriate or how the Identity Provider determines that you are. who you say you are. It’s not just us who forget things: the SAML standard doesn’t define how these things happen, leaving IT a lot of leeway on how to configure things. As noted above, for example, there are several technologies that can be used for the actual authentication element, and the technologies you choose will dictate the details of how you actually implement SAML in your environment. But whatever choice you make, SAML assertions will carry authentication and authorization data from one provider to another.
Benefits of SAML authentication
The most important advantage of SAML as the foundation of an SSO solution is that it is an open standard. As we have seen, this means that it can be implemented by a wide variety of IAM providers and integrated into complete systems like Salesforce. It also means that vendors from different vendors can communicate with each other as long as they adhere to the SAML standard.
Because SAML is an XML dialect, it is also very flexible. All kinds of data can be passed in a SAML document, as long as it can be rendered in XML.
SAML vs OAuth: what’s the difference?
OAuth is a slightly newer standard than SAML, jointly developed by Google and Twitter from 2006. It was developed in part to compensate for the shortcomings of SAML on mobile platforms and is based on JSON rather than XML.
Other than the less-than-stellar mobile support for SAML, what’s the difference between the two? As we have seen, the SAML standard defines how providers can offer both authentication and authorization services. OAuth, on the other hand, deals only with authorization. OpenID Connect is an even newer standard, developed in 2014, that provides authentication services and is overlaid on OAuth.
Another major difference between SAML and OAuth is their use cases. While SAML was theoretically designed for use on the open Internet, in practice it is most often deployed in corporate networks for single sign-on. OAuth, on the other hand, was designed by Google and Twitter for Internet scale.
SAML Tutorials: Some great places to learn more about SAML
Ready to learn more? Here are some great in-depth SAML tutorials:
Learn more about single sign-on and identity management:
Copyright © 2021 IDG Communications, Inc.