Security Assertion Markup Language, commonly known as SAML, is an open standard used to confirm the identity of a user by exchanging authentication and authorisation data.
SAML works by a flow between three entities – the Principal, Service Provider (SP), and Identity Provider (IdP). In the example of a Single Sign-On System, the Principal is typically a user wishing to access the Service Provider. The Service Provider then obtains a SAML assertion from the Identity Provider, confirming the identity of the Principal and authorising their access.
SAML was first developed in 2001 by OASIS, a global non-profit consortium. Since version 1.0 was released in 2002, two new versions have been released, the most recent of which is 2.0, ratified in 2005. Since then, SAML has seen widespread adoption, with older versions very rarely supported today.
The three roles in SAML
SAML defines three roles – the Principal, Service Provider, and Identity Provider. In order to understand these roles and the process of SAML, it’s important to first understand the typical three-stage sign-on process, comprising of identification, authorisation and authentication.
Identification
The point at which the user presents their claim to their identity to the IdP and requests authorisation.
Authentication
The point at which the IdP verifies the user and confirms their identity.
Authorisation
The point at which the SP allows the user access to the service appropriate for their identity and corresponding level of clearance.
These three steps are delegated between the three roles that exist within the SAML process.
Principal
The Principal is usually a human user, who ultimately wishes to gain access to a service offered by the service provider. For example, they may be a user who wishes to access a cloud app.
Service Provider (SP)
As the name suggests, the SP provides the service that the Principal wishes to access. In this example, they would be the company who operates and hosts the cloud app the user wishes to access.
Identity Provider (IdP)
The Identity Provider is a third party to which the role of authenticating users is delegated. This may be done in a variety of ways, from a simple username and password to biometrics and physical tokens. The specific method of this initial process of authentication at the Identity Provider is not important within the SAML framework, and is left unspecified.
SAML use cases
The most common use for SAML is to provide Single Sign-On (SSO) solutions and federated access management. This allows users to use a single identity to access multiple SPs without having to re-enter different credentials for each SP they wish to access.
Why is SAML superior to usernames and passwords?
As well as providing a smoother and quicker experience for the user, who does not need to waste their time entering and resetting passwords, the overwhelming advantage of SSO is its security.
Usernames and passwords provide significant points of weakness for malicious attacks, with brute force attacks, credential stuffing, social engineering and phishing all used to compromise user identities. According to the Verizon Data Breach Investigations report, 81% of hacking-related data breaches took advantage of stolen, weak or unchanged passwords. With the passwords replaced by a secure SAML assertion from a trusted domain the potential for accounts to be hacked is greatly decreased.
By delegating authentication to a single IdP, not only are users more secure, but data breaches are much easier to detect and stop. The IdP allows user activity to be easily monitored as part of a system of Access Management, with unusual and malicious actions much easier to spot.
How does SAML work?
SAML works using one of two processes – IdP-initiated login and SP-initiated login. The flow for these two is similar, but depends on the method used to start the process.
SP-initiated
SP-initiated login begins when the Principal makes a request to access the SP, such as by clicking on a link or launching an app. This sends a SAML request back to the user’s browser, which includes a parameter called RelayState, making sure the correct IdP is found and that the Principal is ultimately directed to the correct URL of the SP they were trying to access.
The IdP then confirms the identity of the user, sending the SAML request back to the SP, which then authorises the user to access the resource if their identity permits them the requisite clearance.
Idp-initiated
As well as access from the SP, SAML also allows for IdP-initiated access. The Principal again starts by authenticating themselves with the IdP, but accesses the resource directly through the IdP. Often, this will be through a portal in the IdP User Interface (UI) itself showing all available SPs. The SP then receives the SAML assertion directly.
While this can be the only method available for some apps, it is generally considered less secure and vulnerable to ‘man-in-the-middle’ attacks, since the SP has no way of knowing if the SAML assertion was not intercepted.
Configuring SAML for Salesforce
SAML is typically straightforward to implement for enterprises. As an example, we’ll look at how to set it up for Salesforce, a market leader for CRM applications.
1. Obtaining certificates and metadata from IdP
This exact method for this step will vary depending on the specific IdP used, but in order to set up Salesforce, two things are required: certificates and metadata. These first need to be downloaded from the IdP.
2. Enabling SAML on the SP
In Salesforce, this is done by navigating to Setup -> Identity -> Single Sign-On Settings then clicking on ‘edit’ and the checkbox which enables SAML.
3. Creating a new SAML connector
First, click on “New from Metadata File” and then upload the metadata that was downloaded in step one. Most of the fields relevant will be filled in automatically, but others may need to be entered manually. To have full SP-initiated SSO, Change “Service Provider Initiated Request Binding” must be changed to “HTTP Redirect”.
4. Sending metadata back to IdP
After this is done and saved, a new button will allow downloading of the metadata from the SP. This can be uploaded to the IdP, in a similar way to step 3.
5. Provisioning users
After this step is completed, the SAML connector can be assigned to a user to allow for testing, before being rolled out to all relevant users.
SAML vs OIDC VS OAuth
SAML is not the only security standard used for SSO available. Another increasingly common standard is OpenID Connect (OIDC), which is an authentication layer built on the OAuth authorisation framework. Like SAML, these are also open standards, and have very similar process flows, but there are some key differences.
OIDC transmits data between parties in JSON format rather than XML, and also has slightly different terminology – OIDC refers to the data sent as ‘claims’ rather than SAML assertions, and also refers to the SP as the Relying Party. It is built on the OAuth framework, which is an open standard for authentication. Unlike SAML, both OAuth and OIDC also facilitate the exchange both via the client, such as a web browser, in addition to allowing the two servers to communicate directly.
Ultimately, the two also have slightly different use cases. SAML is a more feature-rich standard which includes the ability for IdP-initiated access and dynamic specification of proxy IdPs, neither of which is supported by OIDC. However, as the more lightweight standard designed for internet-scale networks, OIDC is usually preferred for mobile use and single landing pages. In contrast, SAML is more frequently used in environments such as banking, government identification and enterprise authentication.
| SAML | OIDC | OAuth | |
| Used for | Authentication | Authentication | Authentication |
| IdP-initiated | Yes | No | No |
| SP-initiated | Yes | Yes | Yes |
| Data format | XML | JSON | JSON |
| Server-sever facilitation | No | Yes | Yes |
How My1Login enables SAML implementation
My1Login serves as an IdP to provide SSO and Access Management for enterprises, leveraging SAML (and OIDC) to achieve passwordless authentication for applications. My1Login delivers the most-widely compatible Identity Management integration, providing authentication through token-based authentication (e.g. SAML), but also Secure Web Authentication, enabling compatibility with all application types, from modern web applications to legacy Windows desktop applications and mainframes.
My1Login’s provision of SAML authentication does not require the organisation to change their existing directory (e.g. Active Directory). Instead, My1Login complements this, integrating with the existing corporate directory to provide a seamless experience for users. The user simply authenticates with their corporate directory and My1Login delivers seamless authentication into all application types.
My1Login utilises SAML (and OIDC) to replace passwords with token-based authentication, enabling organisations to move away from passwords and to passwordless authentication. Where the SP does not yet support passwordless authentication protocols, My1Login’s Secure Web Authentication can be used to provide a passwordless experience, even for cloud applications which have non-standard login pages.
My1Login leverages token-based authentication where available by the service provider, and where not yet available, performs Secure Web Authentication to remove the need for end-users to know, manage or enter application passwords. At an organisational level My1Login eliminates the most common sources of data breaches, while at a user level, a frictionless working experience increases both efficiency and productivity.
