Download Now

SAML (Security Assertion Markup Language) is an open standard that enables users to access numerous web applications or web services using the same login credentials through identity federation. 

SAML relies upon two parties - an identity provider (IDP) and a service provider (SP). The IDP provides authentication information about the user to the SP. The SP uses this information to provide authorization to the user. The pairing of authentication with authorization allows the user to access the SP's services.

The primary use case for SAML is to facilitate Single Sign-On (SSO). Without SAML, users would need a unique username and password for each web application or web service they use. As organizations continue to adopt a growing number of SaaS applications, it's clear that employees would struggle to manage individual credentials for each service securely. 

SAML enables web browser SSO by allowing users to sign in to apps/services with a single set of credentials. This centralization not only provides convenience to employees but also improves organizational security, among other benefits. 

SAML 1.0 was released by OASIS in 2002 as an Extensible Markup Language (XML) standard, followed by a minor revision in 2003. OASIS announced SAML 2.0 in 2005, a major update to the original and the version used today.

The Role of Users in SAML Authentication

In SAML authentication, a user has an account with the IDP, which contains their login credentials and other information necessary for authentication. The user is typically the employee of an organization (client).

Typically, the user's role in the SAML authentication process is as follows:

  1. The user attempts to log in to the SP directly, e.g., via its URL. 
  2. The SP checks that the IDP has authenticated the user. 
  3. If the IDP has authenticated the user, the SP authorizes the user, granting access to the service. 
  4. If they haven't been authenticated, the SP seeks authentication from the IDP. The IDP authenticates the user by checking existing credentials. 
  5. If authentication is successful, the IDP passes these credentials back to the SP. The SP authorizes the user, granting access to the service. 

The Role of Identity Providers in SAML Authentication

An identity provider (IDP) is the service responsible for identifying and authenticating the user. The IDP sends the SP this authentication along with other information, such as their access privileges. In a SAML configuration, The IDP sits between a user and the SP to provide authentication. 

Common examples of SAML identity providers include Microsoft Azure Active Directory/LDAP, and Okta.

Typically, the IDP's role in the SAML authentication process is as follows:

  • The IDP receives a SAML request from the SP to authenticate a user attempting to log in to the service.
  • The IDP checks the user's existing credentials that are stored in its local active directory. Such credentials could include username and password, two-factor authentication (2FA), or multi-factor authentication (MFA). Learn how to protect MFA against hackers.
  • If authentication is successful, the IDP passes these credentials back to the SP through a SAML response. The SP authorizes the user, granting access to the service.

The Role of Service Providers in SAML Authentication

A service provider (SP) is the web service or application that the user wants to access. In a SAML configuration, the SP communicates with a user through an IDP. The IDP provides user authentication to the SP, allowing the SP to authorize user access.

Common examples of SPs include AWS, Salesforce, Microsoft 365, and G-Suite.

Typically, the SP's role in the SAML authentication process is as follows:

  • The SP receives a login attempt from a user to access its services.
  • The SP sends a request to the IDP to authenticate the user by checking their existing credentials.
  • If authentication is successful, the IDP passes these credentials back to the SP. The SP authorizes the user, granting access to the service. 

How Does SAML Authentication Work?

SAML works by passing a user's authentication information from an identity provider (IDP) to a service provider (SP), who provides authorization to the user. 

The SAML workflow occurs through the following steps.

  1. A user attempts to access the SP by directly accessing its URL/portal.
  2. The IDP recognizes this attempt and uses federated software to authenticate the user.
  3. The IDP creates a SAML assertion.
  4. The IDP sends the assertion to the SP through the user's web browser.
  5. The SP's federated software identifies the IDP's assertion.
  6. The SP authorizes the user to access the service.
  7. The IDP re-uses the assertion for other SAML-enabled SPs.

What is a SAML Assertion?

A SAML assertion is an XML document containing authentication and authorization about the end-user. Assertions are the way the SP communicates to the SP.

There are three types of SAML assertions - authentication, attribute, and authorization:

Authentication assertion: Used to verify the user's identity, provide their login time, and their method of authentication, e.g., username and password, 2FA, MFA., etc.

Attribute assertion: Used to pass specific data which contains information about the user that should be the same in both the IDP's and SP's directories.

Authorization assertion: Used to communicate whether the user's authorization attempt was successful or not. Authorization is determined by if their access is permitted and if their authentication was successful. 

What's the Difference Between SAML and OAuth?

While SAML and OAuth are both open standard protocols that enable interoperability, they have notably different functions and are not interchangeable. The key difference is that they form separate parts of the identity and access management (IAM) framework. 

IAM is a framework that manages the digital identities of individuals to ensure they are granted the correct access to digital platforms. Authentication and authorization play essential roles in IAM systems. 

SAML covers both the authentication and authorization processes, whereas OAuth deals exclusively with authorization. 

SAML facilitates SSO; OAuth doesn't. SSO is an authentication process that allows users to log in to many services using a single set of credentials. SAML enables SSO through its User-IDP-SP workflow. 

For example:

  • Employee Jane (User) attempts to access Salesforce (SP) via the login page.
  • Salesforce communicates with Okta (IDP) to request authentication to authorize Jane's access.
  • Okta authenticates Jane with her username, password, and MFA to provide authorization and communicates this information to Salesforce.
  • Salesforce receives this information and authorizes Jane's session. 
  • Jane can log in to any other SAML-enabled web services and applications she needs for her job using the same credentials as they are stored with Okta.

OAuth allows users to directly authorize the sharing of their credentials across services. It also lets the user decide the level of access they grant to the service. 

For example:

  • Bill wants to sign up for WordPress.
  • WordPress offers Bill the option to sign up with his existing Apple ID account.
  • Bill selects the option to sign up with Apple ID.
  • Apple ID asks Bill for permission to share his name and email address with WordPress via Apple ID.
  • Bill authorizes Apple ID to share this information with WordPress to create his account. 
  • Bill can now log in to WordPress using his Apple ID. If he wants to log in to other services using his Apple ID, he will need to set this up through the same process as above.

In terms of which standard to choose between, SAML and OAuth typically have different use cases and can even be used in combination in some scenarios.

OAuth operates best on mobile devices and in situations where users want to individually select which permissions they allow a service. 

SAML is best suited for organizations as it facilitates SSO across multiple platforms, eliminating the need for numerous login credentials.

What are the Benefits of SAML?

SAML offers many benefits to the user, IDP, and SP. These benefits include scalability, improved user experience, administration efficiencies, and more robust security. 

Scalability

As organizations continue to automate and streamline their operations with the help of cloud technologies, SAML can keep up with this demand. Once a user's credentials are entered into an IDP, they can be used to access any of their organization's other SAML-enabled SPs.

Greater User Experience

SAML provides a more user-friendly experience by centralizing the authentication and authorization process. The SAML workflow enables SSO, meaning users only require one set of credentials with the IDP to log in to any SAML-enabled web services or applications they need. This process is a much faster and far more convenient method of access that eliminates issues such as password fatigue.

Administration Efficiencies

Without SAML, employees would need to remember the username and password of every SP they use at work. SAML helps reduce admin time and costs spent assisting employees to recover lost or forgotten credentials through help desks as they only need to remember one set of credentials.

Stronger Security

The use of multiple login credentials across services increases an organization's vulnerability to cyber threats. Using SAML to facilitate SSO eliminates the need for additional credentials. This consolidation helps reduce the risk of human error, e.g., an employee writing their username and password on a piece of paper left at their desk.

SAML assertions allow SPs to make access control decisions based on the level of permitted access the IDP states. Individual employees will only have access to the specific services they need on each platform.

SAML also helps strengthen an organization's security as it means the user logs in fewer times in fewer places, significantly reducing the risk of identity theft and phishing attacks.

Ready to see
UpGuard in action?

Ready to save time and streamline your trust management process?