What is SAML?
The basics of Security Assertion Markup Language
What is SAML and how does it work?
Security Assertion Markup Language (SAML) is a type of Single Sign-On (SSO) standard. It defines a set of rules/protocols that allow users to access web applications with only a single login. This is possible because those applications (referred to as “Service Providers”) all trust the 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 (SSO) capabilities across the web. Others standards include OpenID, OAuth, and JWT (JSON Web Tokens). Each standard was created, and is maintained, by separate organizations. SAML was created by OASIS1, for example. Those organizations have different ideas on how to best implement SSO, which technologies and languages to use, and so on. Despite their technical differences, all of these standards share at least two common goals:
- Provide a pleasant user experience by granting quick and easy access to applications with a single login.
- Enhance security by eliminating the need for applications to store copies of user credentials in their own databases.
Both of these are straightforward and worthy goals for the current age of business and technology. Continue reading to find out how SAML achieves these goals, and how it can play a role in your organization’s Federated Identity Management strategy.
In order to fully understand how SAML works, we’ll start by exploring the concept of a SAML Provider. A SAML Provider is any server that is involved in the authentication and authorization 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 services, and even writing passwords down on sticky notes.
With the advent of SSO standards like SAML, users don’t need to remember numerous passwords. They only need to log into their Identity Provider a single time, and then they are given access to their favorite applications. Authentication from that point on is automatic and transparent to the user.
An Identity Provider is the system that performs user authentication. This is the central location where user credentials are actually 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 authorize 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 finalized by the OASIS consortium2.
A SAML Assertion is the message that the Identity Provider sends to the Service Provider. It’s an XML document that contains all of 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 prevents malicious attackers, who do not have the certificate, from forging assertions and gaining unauthorized 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 us 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 serves 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. 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 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 process of authenticating Bob’s identity with the Identity Provider happens in the background in a matter of milliseconds. All Bob experiences is the ease of gaining access to his applications with a single click, and the joy of not needing to remember many different usernames and passwords.
What can SAML do for you?
SAML, and any other Federated Identity technology, serves 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 difficult to manage, and opens the users and their organizations up to malicious attackers and identity theft3.
By introducing a comprehensive Single Sign-On solution to your organization, its end users will have streamlined access to the applications they need on a daily basis. This reduces downtime caused by forgotten passwords and locked accounts, which translates directly 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.