What is SAML?

posted by HelloID Icon HelloID 23 April 2021

Welcome back to another HelloID blog post. We’re bringing you a brand new, three-part series where we’re talking “What Is?” From SAML to User Account Onboarding, and Single Sign-On, we’re going to be looking at what they are and what exactly they can do for you. So, let’s get started with SAML.

What is SAML?

SAML stands for Security Assertion Markup Language and is a type of Single Sign-On (SSO) standard. It defines a set of rules/protocols that allow users to access web applications with a single login. This is possibly because those applications (referred to as “Service Providers” all trust he systems that verify users’ identities (referred to as “Identity Providers”).

SAML is one of the dominant standards in the world of Federated Identity Management (FIM), offering Single Sign-On capabilities across the web. Other standards include OpenID, OAuth, and JWT (JSON Web Tokens). Each standard was created, and is maintained, by separate organisations. SAML was created by OASIS, for example. Those organisations have different ideas on how best to implement SSO, which technologies and languages to use, and so on. Despite their technical differences, all these standards share at least two common goals:

  1. Provide a pleasant user experience by granting quick and easy access to applications with a single login.

2. Enhance security by eliminating the need for applications to store copies of user credentials in their own databases.

Both are straightforward and worthy goals for the current age of business and technology. Now we’ll discuss how SAML achieves these goals, and how it can play a role in your organisation’s Federated Identity Management strategy.

SAML Providers

In order to fully understand how SAML works, we need to start by exploring the concept of a SAML Provider. A SAML Provider is any server that is involved in the authentication and authorisation of a user during a SAML request. More specifically, there are two types of SAML Providers: Service Providers (SP) and Identity Providers (IdP).

Service Providers are the systems and applications that users’ access throughout the day. Before SSO, each of them would maintain their own database of usernames and passwords. The more applications a person used, the more usernames and passwords they would need to remember and manage. This increase in the number of credentials per user incentivised undesirable password management practices, such as using the same password across multiple websites and service, and even writing passwords down on sticky notes!

The advent of SSO standards like SAML means users don’t need to remember numerous different passwords. They need only to log into their Identity Provider a single time, and then they are granted access to their favourite applications. Authentication from that point on is automatic and transparent to the end user.

An Identity Provider is the system that performs user authentication. This then is the central location where user credentials are stored and validated. Once a user logs into their Identity Provider, they have access to their SSO-enabled applications. When a user opens an application, the Identity Provider and the Service Provider work together to authenticate and authorise the user, and then grant them access if appropriate.

The conversation that happens between the Identity and Service Providers is done through a message called an Assertion. This is an XML document that is created by the Identity Provider and verified by the Service Provider. It is constructed according to the SAML standards laid out in 2005 when the SAML2 standard was finalised by the OASIS consortium.

SAML Assertions

A SAML Assertion is the message that the Identity Provider sends to the Service Provider. It’s an XML document that contains all the relevant details of the end user. This includes their unique identifier, their name, and any additional attributes that may be required by the Service Provider. These attributes are sometimes referred to as “claims”. Both terms can be used interchangeably.

All assertions are signed with an X.509 certificate by the Identity Provider. The service provider has a copy of the certificate’s fingerprint, which it uses to verify the authenticity of the assertion. This then prevents malicious attackers, who do not have the certificate, from forging assertions and gaining unauthorised access.

SAML Authentication Example

Let’s follow a fictional employee, Bob Johnson, from his arrival at work to the launch of his first SSO-enabled application. This will give you a good idea of how SAML, and SSO in general, functions on a day-to-day basis.

After getting his morning cup of coffee, Bob sits down at his desk and logs into his computer. He then opens his browser, whose home page has been set to his employer’s SSO Portal. This portal acts as Bob’s Identity Provider. On the portal, Bob is presented with the numerous applications that he needs to perform his job.

After careful consideration, Bob chooses to open Salesforce by clicking on its icon in the portal. And this is where the SAML authentication process begins.

First, Bob’s request is routed to Salesforce. Salesforce responds, requesting authentication from the Identity Provider. The Identity Provider then builds a SAML Assertion that contains Bob’s user information, such as his email address and name. It then signs it with a certificate that it has on file and sends the assertion back to Salesforce.

Once it receives the SAML assertion, Salesforce uses its copy of the certificate’s fingerprint to verify that the assertion is valid. If it’s valid, and Bob has an active account, he will be logged into Salesforce.

The whole process of authenticating Bob’s identity with the Identity Provider happens in the background in a matter of milliseconds. All Bob experiences his end is the ease of gaining access to his applications with a single click, and the joy of not having to remember numerous different usernames and passwords.

What can SAML do for you?

SAML, and any other Federated Identity technology, services to make the lives of users easier and more secure. Without it, users are forced to manage different credentials for every site that they use. This collection of credentials is not only difficult to manage, but it also opens the users and their organisations up to malicious attackers and identity theft.

By introducing a comprehensive Single Sign-On solution to your organisation, its end users will have streamlined access to the applications they need daily. This then reduces downtimes caused by forgotten passwords and locked accounts, which translates into higher productivity and increased morale. All of this can contribute to a positive effect on a company’s bottom line, making investment into SSO technologies a clear winner in terms of ROI.

We hope you enjoyed this in-depth look at SAML, and what it can do for you. Keep an eye on our blog for the next blog post in the “What Is?” series.

As always, if you have any questions, please do get in touch with us through the “Contact” page on our website. We’ll get back to you as soon as possible.