Security Assertion Markup Language (SAML)

What is Security Assertion Markup Language (SAML)?

Security Assertion Markup Language (SAML) is an open standard for sharing security information about identity, authentication and authorization across different systems. SAML is implemented with the Extensible Markup Language (XML) standard for sharing data. It provides a framework for implementing single sign-on (SSO) and other federated identity systems. A federated identity system links an individual identity to multiple identity domains. This approach enables SSO that encompasses resources on an enterprise network, trusted third-party vendor and customer networks.

The Organization for the Advancement of Structured Information Standards (OASIS) manages the SAML protocol. SAML 2.0, the current version, was published as an OASIS standard in 2005.

OASIS has said that "SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application."

SAML is an important component of SSO systems that enable users to access multiple applications, services or websites from a single login process. Identity and authentication levels are shared across different systems and services using the SAML protocol to request, receive and format that data.

What is SAML used for?

Organizations use SAML both for business-to-business and business-to-consumer applications. It is used to share user credentials across one or more networked systems. The SAML framework is designed to accomplish two things:

1. user authentication
2. user authorization

SAML is most often used to implement 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 implemented 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.

SAML entities

SAML defines three categories of entities:

1. End users. An end user is a person who needs to be authenticated before being allowed to use 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 is 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.

SAML components

SAML incorporates four different types of components:

1. SAML assertions are statements of identity, authentication and authorization information. These are formatted using XML tags specified in SAML.
2. SAML protocols define how different entities request and respond to requests for security information. Like SAML assertions, these protocols are encoded with XML tags specified in SAML.
3. SAML bindings are the formats specified for SAML protocol messages to be embedded and transported over different transmission mechanisms.
4. SAML profiles determine how SAML assertions, protocols and bindings are used together for interoperability in certain applications.

SAML assertions

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. An authentication 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. An attribute 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. An authorization decision assertion indicates whether a subject's request to access a resource has been approved or declined.

SAML protocols

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 defines requests for authentication assertions and valid responses to such requests. This protocol is used when a request sent from a user to a service provider needs to be redirected to an identity provider.
• Single Logout Protocol defines a technique in which all of a user's active sessions can be terminated nearly simultaneously. This capability is important for SSO implementations that require terminating sessions with multiple resources when the user logs out.
• Assertion Query and Request Protocol defines requests for new and existing authentication assertions.
• Artifact Resolution 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 defines a mechanism for an identity provider to manage its name by changing the name identifier and the format of the name identifier or to notify other SAML entities that a name identifier has been terminated.
• Name Identifier Mapping Protocol defines a mechanism for mapping a user identifier across different service providers.

These request/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 depends on several other protocols that are used to format and exchange SAML requests and responses. These include the following:

• XML defines how SAML messages are formatted.
• Hypertext Transfer Protocol (HTTP) is the protocol SAML uses to exchange messages.
• SOAP -- originally standing for Simple Object Access Protocol, though that meaning has dropped off -- is the protocol used to encapsulate 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 that are encoded in SOAP messages. It is 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

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 implement 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.

These profiles can be configured to enable an SSO deployment.

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 another service provider.

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 data being formatted as assertions.

SAML example

A typical SAML authentication process for authentication works this way:

1. The end user initiates a session with an identity or SSO provider by logging in and being authenticated.
2. The end user initiates a session with a service provider -- cloud application or other third-party application -- which is configured to do authentication via SSO.
3. The service provider requests authentication information about that specific user from the end user's identity provider.
4. The identity provider responds to SAML authentication requests with a SAML-formatted, digitally signed response that identifies the end user. The response may include other information indicating that the user is -- or is not -- authenticated and authorized to access restricted resources.
5. The service provider validates the response from the identity provider and authenticates the end user to give them access to restricted resources.
6. The end user accesses the service provider's content or application.

What's the difference between SAML and SSO?

SAML is a platform for requesting authentication. Its most common use is to enable SSO. Some products that implement SSO services using SAML include the following:

• Microsoft Azure AD
• Citrix Workspace
• Entrust Identity
• VMware vSphere

SSOs implement federated identity 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, like OpenID, to manage cross-domain authentication.

SAML vs. OAuth vs. OpenID

In addition to SAML, Open Authorization (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 implement SSO.

Some differences between SAML and OAuth include the following:

• SAML enables authentication of user credentials, while OAuth enables authorization of users that may be authenticated through some other mechanism.
• SAML messages are based on XML formatting, while OAuth uses JavaScript Object Notation to format its messages.
• SAML uses session cookies to manage session state, like authentication tokens, while OAuth uses API calls to manage authorizations.

OpenID

OpenID Connect is a protocol built on the OAuth framework to enable users to use a single existing account to log in to multiple websites. OpenID Connect defines identities using the OAuth 2.0 protocol. It is used by providers, including Facebook, Google, Microsoft and many others, 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 grew from an idea to a mature security protocol quickly:

• 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 implementation and support from SSO vendors.

Understanding how SAML enables SSO is a great first step for anyone involved in rolling out new SSO. The next step could be to learn more about best practices for deploying SSO in the enterprise.