Everything you need to know about SAML

To ensure authentication standardization, companies often expect SAAS to be SSO-ready. Just like Sam Gamgee helping Frodo Baggins on his journey, SAML is a precious ally in your quest to become SSO-ready. You will find out more in our article.

What is SAML

The SAML (Security Assertion Markup Language) is used for the sake of communication between identity and service providers. Launched in 2005, it was developed by the Organization for the Advancement of Structured Information Standards (OASIS). This organization works towards standardizing open file formats. Based on XML (EXtensible Markup Language), it serves to communicate data between several parties. Although SAML has been used more and more, alternatives do exist. They allow to set up an SSO (Single Sign-On). They offer a simpler and more seamless authentication experience.

A communication between different players in the Authentication landscape

SAML is mainly used by companies and governments to set up SSO. Indeed, it allows for the exchange of authentication data between parties. To do so, it creates a so-called “trust relationship” between an identity provider (IDP) and a service provider (SP). It is this relationship that will allow to use SAML and to secure the communication of identities.

SAML, a language based on XML

XML (EXtensible Markup Language) is a markup language just like HTML (Hypertext Markup Language). Yet unlike HTML, XML has been conceived and designed to store and transmit data. XML’s initial objective is to facilitate the automated exchange of content between information systems. Moreover, since 1998 and its 1.0 version, it has become a W3C recommendation (World Wide Web Consortium).

Hence in the case of SAML, identity data is expressed in the XML format.

XML Schema Definition (XSD)

XSDs allow to describe the structure of an XML document. In SAML, protocol specifications and assertions are carried out with the help of an XSD. 

An exchange based on SOAP and HTML

HTTP and SOAP (Simple Object Access Protocol) are communication protocols used mainly by SAML. Thus data transfers between different parties (service providers, identity providers and relying parties) use both these protocols. 

SAML, various parties for various communications

In the case of an SSO, several communications are necessary. Most of the time, these will be conducted through SAML. Indeed, identity data is initially converted into XML format. Then the latter will be transmitted between the different parties involved via HTML or SOAP protocols. Their combination makes up the SAML.

First, the user tries to access a resource that requires authentication (service provider). If they haven’t been identified, the service provider will redirect them to the identity provider with an SAML request. Then the user will be invited to enter their login details. The latter will be verified by the relying party, which will send its response to the identity provider. If the information provided by the user is accurate, they will then be redirected and authenticated by the IP towards the requested service.

SAML and OAuth, two protocols that share similarities

When it comes to SSOs, SAML and OAuth are the two alternatives that come up the most. However, the fact that they are used for the same purpose does not mean they are identical.

Indeed, a major difference exists between the two of them: while SAML is mainly used for authentication, OAuth serves for authorization.

To illustrate this point, let’s take the example of a concert, game, or any other large-scale event. To get in, you must show your ID. It will serve to prove that you are the person you are claiming to be. As for your ticket, it will determine where you should be seated (seat number, mosh pit, VIP area…).

In this example, there is an authentication process that goes through your ID (SAML). This authentication will allow you to enter the event. Then, you will have an authorization to access certain services thanks to your ticket (OAuth).

A valuable ally for all parties

SAML allows the use of an SSO. This way, one can do without all user passwords for each service. They are then replaced by a single password. 

On the user’s side, the authentication experience is simplified. With a single ID/password combination, they will be able to access all of their services in just a few clicks. Thus SAML means saving time and simplifying your experience.

For the Identity Provider, this represents a major cut in requests for password resets. Furthermore, ID management is centralized down to a single point, which guarantees reinforced security. Finally, this reduces the complexity that results from the multiplication of SAAS within companies. Thanks to SAML, users can be defined with a single ID. In case of an ID update, it can be rolled out easily to all other services.

Lastly, for the service provider, identity management is no longer a problem. Besides, they will be more attractive and competitive by being compatible with all types of SSOs.

SAML in more detail

First, there is a prerequisite for the use of SAML. An exchange of metadata must take place between the relying party and the identity provider. Without it, the various parties won’t be able to communicate with each other. This metadata exchange will occur in XML format and will serve to specify the information required for communication to run properly (attribute format, connection method…). Thus, both parties will be able to align and set up their systems with the necessary information. 

Once this stage is complete, users will be able to start signing in. To do so, the relying party will send an authentication request (SAML AuthnRequest) to the identity provider. It can be done either via an HTTP POST form (which allows the transmission of SAML protocol messages in HTML format and base64 encoding), or via HTTP redirection with a request (which allows SAML protocol messages to be transmitted via URL parameters). 

These allow both parties to communicate by using an HTTP user-agent as intermediary. In both cases, requests are verified and signed by the relying party.

Then, the identity provider verifies the request. It subsequently identifies the user and sends out an SAML response that contains an SAML assertion. The latter is an XML document that holds the user’s authorization that the IP sends to the service provider or the relying party. It is sent via a POST form. 

SAML responses and assertions are signed by the identity provider, which serves to guarantee their authenticity. 

SAML: a simple and obvious response to the implementation of an SSO.

SAML is the most common method used by companies to set up an SSO. Rolling out an accounting system using SSOs can put some SAAS off given that it represents a higher development cost. However, being compatible with SSOs when you’re a service provider is often a necessity. Therefore, one of SAAS’ main challenges is to become “SSO ready”, i.e. have the capacity to connect with the different types of SSOs and IPs they can encounter among their clients or prospective companies. Thus, meeting this requirement is not only a matter of security but also one of business, in order to expand one’s market and contractualize with clients who have such expectations. With just a few lines of code, Cryptr can make your authentication compatible with all the types of SSOs (SAML, ADFS, OIDC) and identity providers (Okta, Ping Identity, Auth0, OneLogin, Google,...) that you may encounter.

So, are you ready to become SSO-compatible? Find out more on Cryptr.