Security Assertion Markup Language (SAML) is an open standard that defines how vendors can provide both authentication and authorization services. Here you will find everything you need to know. […]
What is SAML and what is it used for? The Security Assertion Markup Language (SAML) is an open standard that allows the sharing of security proofs by multiple computers on a network. The standard describes a framework that allows a computer to perform some security functions on behalf of one or more other computers.
Strictly speaking, SAML refers to the XML variant of the language used to encode all this information, but the term can also include various protocol messages and profiles that are part of the standard. Since SAML is an open standard, it can coordinate security measures for different applications and systems from different vendors. Therefore, many security vendors use SAML as the basis for their commercial offerings to ensure interoperability.
SAML 2.0 was introduced in 2005 and is still the current version of the standard. The previous version, 1.1, is now largely outdated. (SAMLDiffs provides a good summary of the differences between the versions [engl.]).
What is Single Sign-on?
Although SAML was developed with a variety of use cases in mind, by far the most common in practice is Single Sign On (SSO). SSO, as the name implies, allows a user to log in once and access several services – websites, cloud or SaaS applications, file shares and so on. In an SSO scenario, all these services outsource their authentication and authorization functions to a single system, which then sends identity information about the user to these services.
Documents written in SAML are a way to transfer single sign-on information. SAML is a particularly attractive candidate for this task due to its openness and interoperability, as customers often want a single sign-on solution that can connect applications from different providers.
Authentication and Authorization
Before continuing, 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 whether users have the right to access certain systems or content
Of course, every SSO platform has to play both roles in order to be able to fulfill its task. An interesting point is that SAML does not necessarily have to be used for both tasks. For example, Microsoft has an SSO implementation that uses SAML for authentication and OAuth (another open standard that we will discuss in more detail later in this article) for authorization.
What is a SAML provider?
In SAML jargon, a provider is an instance – generally a server or other computer – within a system that helps the user to access the desired services and produces or uses the SAML services. In general, the actual programs you want to access, such as SaaS applications or protected file servers, are called the service providers, while the identity providers ensure that the user is really who he claims to be, or that he has the right to access the systems he is trying to access – in other words, they provide authentication or authorization.
It is important that the SAML standard itself does not define how these providers do their work. Instead, it determines which information you need to exchange with each other and how this communication and its process are structured.
What is a SAML assertion?
A SAML assertion is the XML document that is used to transfer all the information we just discussed from one computer to another. Once an identity provider has determined that you are who you claim to be 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 with these services. A SAML assertion can be encrypted to increase security.
For more information on all these terms, see the official OASIS SAML glossary.).
How does SAML authentication work? An example of a SAML flow
Since this all seems a bit abstract, here is an example of how a SAML authentication transaction would proceed. The user agent in most cases will be a web browser.
Imagine that you are the user in a single sign-on environment and are trying to gain access to a resource on a server. The sequence of events then looks like this:
- You are trying to access the resource on the server. The service provider checks whether you are already authenticated in the system. If so, skip to step 7. If not, the service provider will begin the authentication process.
- The service provider determines the appropriate identity provider for you and forwards you to it – in this case to the single sign-on service.
- Your browser sends an authentication request to the SSO service, which then identifies you.
- The SSO service returns an XHTML document that contains the authentication information required by the service provider in a SAMLResponse parameter.
- The SAMLResponse parameter is forwarded to the service provider.
- The service provider processes this response and creates a security context for you, i.e. it logs you in and then tells you where the requested resource is located.
- With this information, you can now request the desired resource.
- The resource will finally be forwarded to you!
If you want to take a closer look at the content of the messages that are sent back and forth in a SAML transaction, see the examples from OneLogin.) to. You can have a look at the full XML code for the types of assertions that are submitted by the identity provider to the service provider in the scenario described above.
Implementation of SAML
You will notice that a lot of things are pretty general here: for example, it doesn’t explain how SAML knows which identity provider is the right one, or how the identity provider determines that you are who you claim to be. This is not just because we are omitting things: as mentioned earlier, the SAML standard does not define how these things work and leaves a lot of leeway for vendors and implementers to set up these things.
Multiple technologies can be used for the actual authentication, and the technologies you choose determine the details of the SAML implementation in your environment. But no matter what choice you make, SAML assertions will transfer authentication and authorization data from one provider to another.
Advantages of SAML Authentication
The most important advantage of SAML as the basis for an SSO solution is that it is an open standard. As we have seen, this means that it can be implemented by a variety of IAM providers and integrated into all-encompassing systems such as Salesforce. It also means that providers from different providers can communicate with each other as long as they adhere to the SAML standard.
Since SAML is an XML dialect, it is also very flexible. All kinds of data can be transferred in a SAML document as long as it can be rendered in XML.
SAML and OAuth: What’s the difference?
OAuth is a slightly newer standard than SAML, which was 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 instead of XML.
What is the difference between SAML and JSON, apart from the not-so-good support for mobile devices? As we have seen, the SAML standard defines how providers can provide both authentication and authorization services. OAuth, on the other hand, only deals with authorization. OpenID Connect is an even newer standard, developed in 2014, which offers authentication services and is based on OAuth.
Another key difference between SAML and OAuth is the use case. While SAML was theoretically designed for use on the open Internet, in practice it is most often used in corporate networks for single sign-on. OAuth, on the other hand, was developed by Google and Twitter for use on the Internet.