What is SAML (Security Assertion Markup Language)?

What is SAML used for?

Organizations use SAML both for business-to-business and business-to-consumer apps. It is used to share user credentials across one or more networked systems. The SAML framework is designed to achieve two objectives: user authentication and user authorization. Additionally, SAML facilitates interoperability between different systems, enabling different identity providers and service providers to communicate effectively, even if they have different technical specifications

SAML is most often used to operate SSO authentication systems that enable end users to log in to their networks once and be authorized to access multiple resources on that network. For example, SSO used with Microsoft Active Directory (AD) can be integrated with SAML 2.0 authentication requests.

Authentication is the process of determining whether an entity is what it claims to be. It is required before authorization, which is the process of determining whether the authenticated identity has permission to use a resource.

SAML authentication depends on verifying user credentials, which, at a minimum, include user identity and password. SAML can also enable support for multifactor authentication.

How does SAML work?

SSO applications use SAML to move information about user identities from an identity provider to a service provider. SAML authenticates end users who are logged in to a primary service provider to access another service provider’s resources.

For example, enterprise users logged in to their primary SSO work network can be authenticated to a third-party cloud application provider through SAML rather than being required to log in separately to the cloud application.

The primary SSO system acts as the identity provider, and the cloud application acts as the service provider. When an end user, already logged in to the identity provider, attempts to open the cloud application, the cloud application identifies the end user. It then points the user — or the user’s browser or other client software — back to the identity provider to be authenticated.

Authentication requests and responses to those requests must conform to the SAML protocols for exchanging information, with SAML authorization data being formatted as assertions.

Here’s a breakdown of how the SAML process works:

1. User initiates a request. A user attempts to access a service provider’s application, such as a web application or a cloud application with an identity or SSO provider.
2. User is redirected to identity provider. If the user is not already authenticated, the service provider redirects the user to the identity provider for authentication. This redirection includes a request for authentication.
3. User is authenticated. The identity provider prompts the user to log in. Once the user successfully logs in, the identity provider generates a SAML assertion, which is a secure token or a digitally signed SAML response containing information about the user’s identity and attributes. The response might include other information indicating that the user is — or is not — authenticated and authorized to access restricted resources.
4. SAML assertion is transmitted. The identity provider sends the SAML assertion back to the service provider, typically through the user’s browser. This assertion confirms the user’s identity and might include additional attributes, such as roles or permissions.
5. Access is granted. The service provider receives the SAML assertion, validates it and grants the user access to the application based on the information contained in the assertion.

SAML entities

A SAML entity refers to any system component that participates in SAML-based communications, specifically in the context of identity and service provision.

SAML defines three categories of entities:

1. End users. An end user is a person who needs to be authenticated before getting access to an application.
2. Service providers. A service provider is any system that provides services, typically the services for which users seek authentication, including web or enterprise applications.
3. Identity providers. An identity provider is a special type of service provider that administers identity information.

SAML’s main purpose is to define the markup language used to standardize the encoding of authentication data for exchange between systems. It also includes all the associated protocols and bindings that use SAML-compliant messages to exchange security assertions among end users, service providers and identity providers.

Benefits of SAML

SAML offers many benefits for both users and service providers, especially over other standards in identity and access management.

Common benefits and use cases of SAML include the following:

• Simplified login credentials. With the SSO aspect of SAML, users can log in once and gain access to multiple applications without needing to remember various usernames and passwords. While users might briefly observe web browser redirects during the SAML process, they don’t need to interact with or configure any underlying technology. SAML operates seamlessly in the background, enabling users to effortlessly enjoy the benefits of simplified login experiences.
• Improved security. SAML shifts the responsibility of storing and managing user credentials to a dedicated identity provider, eliminating the need for individual applications to store sensitive password data and reducing the risk of data breaches. By centralizing authentication, organizations can enforce stronger security measures, such as multifactor authentication, robust password policies and granular access controls, to create a more secure and resilient environment.
• Interoperability. SAML is highly interoperable because it’s an open standard that isn’t owned by any single vendor. The protocol is well defined and extensively documented, which ensures consistent integration across different systems. It also supports federated identity management, enabling organizations to manage user identities across various domains and services. This interoperability simplifies user management and improves collaboration between organizations.
• Reduced password reset and management requests. SAML reduces password reset and management requests by centralizing authentication. Since users are only required to remember one set of credentials, the frequency of forgotten passwords and the need for password resets are significantly decreased. Additionally, centralized identity management means password changes are handled at the identity provider level, further streamlining the process and reducing administrative overhead.
• Cost and time savings. SAML saves time and costs by reducing administrative tasks related to managing multiple accounts and passwords. With SSO, users authenticate once, leading to fewer password resets and help desk support requests. Additionally, centralized identity management streamlines user provisioning and access control, cutting down IT workload and saving on labor and maintenance costs.

SAML components

SAML consists of several key components that work together to facilitate the secure exchange of identity, authentication and authorization information between different entities.

The four different types of SAML components include assertions, protocols, bindings and profiles.

SAML assertions

SAML assertions are statements of identity, authentication and authorization information. These are formatted using XML-based tags specified in SAML.

According to the SAML core protocol specification, a SAML assertion is a unit of information that supplies zero or more statements made by a SAML authority. SAML authorities are any system that generates SAML authentication assertions. SAML identity providers are examples of these authorities.

SAML specifies three types of assertions:

1. Authentication assertion. This assertion indicates that the subject of the assertion has been authenticated. It includes the time and method of authentication as well as the subject being authenticated.
2. Attribute assertion. This assertion associates the subject of the assertion with the specified attributes. A specified SAML attribute is one that refers to a defined piece of information relating to the authentication subject.
3. Authorization decision assertion. This assertion indicates whether a subject’s request to access a resource has been approved or declined.

SAML protocols

SAML protocols define how different entities request and respond to requests for security information. Similar to SAML assertions, these protocols are encoded with XML tags specified in SAML.

SAML defines its own generalized protocols for request/response interactions between systems and the entities that can be authenticated — either principals or subjects. SAML 2.0 protocols include the following:

• Authentication Request Protocol. This protocol defines requests for authentication assertions and valid responses to such requests. It is used when a request sent from a user to a service provider needs to be redirected to an identity provider.
• Single Logout Protocol. This protocol defines a technique in which all of a user’s active sessions can be terminated nearly simultaneously. This capability is important for SSO executions that require terminating sessions with multiple resources when the user logs out.
• Assertion Query and Request Protocol. This protocol defines requests for new and existing authentication assertions.
• Artifact Resolution Protocol. This protocol defines how to request and transmit SAML protocol messages using an identifying value or artifact. This approach simplifies the exchange of specific protocol messages.
• Name Identifier Management Protocol. This protocol defines a mechanism for an identity provider to manage its name by changing the name identifier and its format or to notify other SAML entities that a name identifier has been terminated.
• Name Identifier Mapping Protocol. This protocol defines a mechanism for mapping a user identifier across different service providers.

These request and response protocols are defined as part of SAML to enable systems to request authentication, respond to authentication requests and exchange SAML assertions. These protocols are independent of the networking protocols that SAML messages are bound to for network transport.

SAML bindings

SAML bindings are the formats specified for SAML protocol messages to be embedded and transported over different transmission mechanisms.

SAML depends on several other protocols that are used to format and exchange SAML requests and responses. These include the following:

• XML, which defines how SAML messages are formatted.
• Hypertext Transfer Protocol (HTTP), which SAML uses to exchange messages.
• SOAP, which originally stood for Simple Object Access Protocol (though that meaning has dropped off), encapsulates SAML messages.

SAML bindings define how SAML protocol messages are transmitted. They use the transport protocols that enable communication between SAML entities. SAML 2.0 defines the following bindings:

• HTTP Redirect Binding. Defines a format for exchanging SAML authentication messages in HTTP redirect messages.
• HTTP POST Binding. Defines a format for exchanging SAML authentication messages in HTML forms.
• HTTP Artifact Binding. Defines a format for exchanging SAML artifacts in HTML forms or in a string added to a URL.
• SAML SOAP Binding. Defines a format for exchanging SAML authentication messages in SOAP messages.
• Reverse SOAP (PAOS) Binding. Defines a mechanism for a web browser client to respond to SAML messages encoded in SOAP messages — sometimes referred to as PAOS, which is SOAP in reverse.
• SAML URI Binding. Defines a mechanism for retrieving a SAML assertion using a Uniform Resource Identifier.

SAML bindings enable authenticating systems to exchange SAML assertions and requests using widely supported protocols.

SAML profiles

SAML profiles determine how SAML assertions, protocols and bindings are used together for interoperability in certain applications.

A SAML profile consists of SAML assertions, protocols and bindings. SAML profiles are used to define specific applications.

Profiles defined for SAML 2.0 include the following:

• Web browser SSO profile. Defines how SAML is used to enable SSO on web browsers.
• Enhanced client and proxy profile. Specifies how specialized clients or gateway proxies operate using SOAP or PAOS bindings.
• Identity provider discovery profile. Defines a technique to give service providers access to identity providers a user previously visited.
• Single logout profile. Shows how the Single Logout Protocol works with SAML bindings.
• Assertion query/request profile. Specifies how SAML entities receive SAML assertions over a synchronous binding like SOAP.
• Artifact resolution profile. Defines how SAML artifacts are exchanged over specific protocols.
• Name identifier management profile. Defines how SAML Name Identifier Management Protocol works over specific protocols.
• Name identifier mapping profile. Defines how SAML Name Identifier Mapping Protocol works over specific protocols.
• Attribute query profile. Outlines how a service provider can request supplementary user attributes from an identity provider following the initial authentication process.

These profiles can be configured to enable an SSO deployment.

What’s the difference between SAML and SSO?

SAML and SSO are related concepts in the realm of authentication and identity management, but they serve different purposes and have distinct characteristics.

The key characteristics that differentiate SAML and SSO are as follows:

• SAML is a platform for requesting authentication. Its most common use is to enable SSO. Some products that utilize SSO services using SAML include Microsoft Azure AD, Citrix Workspace, Entrust Identity and VMware vSphere.
• SSOs uses identity federation management to enable multiple domains to authenticate users using one set of credentials. SSO can use SAML protocols to exchange authentication information, or it can use some other protocol, such as OpenID, to manage cross-domain authentication.
• SAML provides the technical framework and protocols necessary for executing SSO. It specifies how authentication requests and responses should be formatted and exchanged between the identity provider and service provider.
• SSO is the end-user experience that results from using protocols such as SAML. When a user logs in once, they can access various services without needing to reenter their credentials.
• SAML is often used in enterprise environments where secure, cross-domain authentication is required. It’s particularly effective for web-based applications and services.
• SSO is typically executed using various protocols, including SAML, Open Authorization (OAuth) and OpenID Connect.
• SAML is based on XML and uses assertions to transmit authentication information.
• SSO can use different technologies, such as cookies, tokens and various authentication protocols, including SAML.

SAML vs. OAuth vs. OpenID

In addition to SAML, OAuth and OpenID are two important specifications that enable SSO.

OAuth

OAuth 2.0 Authorization Framework protects user credentials while using those credentials to gain access to third-party applications. As a framework, OAuth can be used with either SAML or OpenID Connect to enable SSO.

The following are some differences between SAML and OAuth:

• SAML enables authentication of user credentials, while OAuth enables authorization of users that could be authenticated through some other mechanism.
• SAML messages are based on XML formatting, while OAuth uses JavaScript Object Notation (JSON) to format its messages.
• SAML uses session cookies to manage session state, such as authentication tokens, while OAuth uses API calls to manage authorizations.
• SAML secures data exchange through digital signatures and encryption, whereas OAuth depends on HTTPS encryption and bearer tokens for security.

OpenID

Published in 2014, OpenID Connect is a relatively newer protocol built on the OAuth framework to enable users to use a single existing account to log in to multiple websites. It was specifically designed for web and mobile applications.

OpenID Connect defines identities using the OAuth 2.0 protocol. It uses industry-standard JSON Web Tokens and relies on secure HTTPS communication, making it a flexible and user-friendly option for authentication and authorization. Various providers, including Meta, Google and Microsoft, use it to enable access to third-party websites using the providers’ credentials.

History of SAML

As the world started doing business on the internet at the turn of the century, the need grew for cross-domain authentication and authorization. At the time, the Kerberos authentication protocol was established for use inside enterprise networks, but it fell short on authentication across domains. Microsoft released AD along with Windows 2000 Server edition, but that wasn’t enough. It was clear that an open standard was needed.

SAML 1.0 was released in 2002, offering a basic framework for authentication and authorization. SAML 1.1, released in 2003, addressed some limitations but still had restricted capabilities. In 2005, SAML 2.0, which is still its latest version, was introduced with significant improvements, including support for metadata, enhanced single sign-on and better attribute exchange. Since then, SAML 2.0 has had widespread adoption as an authentication standard.

Here’s a brief historical timeline of SAML:

• 2001. The first meeting of the OASIS Security Services Technical Committee. This committee was tasked with creating an XML framework for authentication and authorization.
• 2002. Publication of SAML 1.0 specification as an OASIS standard.
• 2003. SAML 1.1 published as an OASIS standard.
• 2005. SAML 2.0 published as an OASIS standard.

Since 2005, the history of SAML has largely been one of adoption and support from SSO vendors.

User authentication is crucial for protecting sensitive information and systems from unauthorized access. Discover six key authentication types to enhance network security.