What Is SAML 2?
SAML 2.0 (version 2.0 of the Security Assertion Markup Language) is an open standard that allows organizations to set up single sign on (SSO) across multiple websites and applications. It allows a user to authenticate once and gain access to multiple systems, by providing proof of prior authentication.
SAML represents identity data using an XML token, and transfers data using HTTP, making it easy to operate in almost any environment. SAML 2.0 replaced SAML 1.1 in March 2005,
SAML 2.0 was ratified as a standard in March 2005, replacing SAML 1.1. The standard is managed by the OASIS Open organization. Key differences between SAML 1.1 and SAML 2.0 include support for new protocols, including assertion queries and requests, authentication request, artifact resolution, name identifier management, name identifier mapping, and single logout protocols.
Benefits of SAML
SAML is widely adopted by enterprises, for several reasons:
- Improves the user experience, because users only need to sign in once and can access multiple applications.
- Reduces the risk of weak passwords because users only have one password for all systems.
- Enables secure interoperability between services, because a service provider does not need to store user credentials, relying on the identity provider for this function.
- Moves the responsibility for authentication to the identity provider, which has the ability to invest in multiple layers of security such as multi-factor authentication (MFA).
- Reduces IT help desk costs, because users have less access issues and need less help resetting passwords.
Differences Between SAML Versions
SAML 2.0 is the second revision (and first major upgrade) of SAML 1.0. SAML 1.1 is similar to SAML 1.0, but SAML 2 significantly differs from both. SAML 1 only specifies queries, while SAML 2 introduces many new protocols, including the assertion query and request, authentication request, artifact resolution, name identifier management, name identifier mapping, and single logout protocols.
SAML 1.1 only explicitly defines the SAML SOAP binding but also has precursors to the HTTP POST, HTTP redirect, and HTTP artifact bindings. SAML 2.0 expands the concept of bindings by fully separating bindings from underlying profiles. Examples include the reverse SOAP, SAML URI, and HTTP redirect (GET) bindings.
SAML 1.1 offers two web browser SSO options: the browser/artifact and browser/POST profiles. SAML 2 offers a fully refactored web browser SSO profile, offering greater flexibility due to its plug-and-play design. The SAML 2 browser flow begins with a request initiated by the SP—one drawback is the IdP discovery problem. SAML 2.0 also introduces other profiles, including SSO, artifact resolution, name identifier mapping, and SAML attribute profiles.
SAML 2 Architecture, Concepts and Components
The SAML architecture consists of components that together support various use cases. They enable the transfer of data about identity, attributes, authentication, and authorization information. The SAML specification defines the content and structure of protocol messages and assertions.
A SAML assertion carries a statement about an entity or user (principal)—an XML schema defines the assertion’s structure. Asserting parties create assertions, usually based on requests from relying parties. They use SAML protocol messages to make requests and return responses (a protocol XML schema defines their contents and structure).
SAML bindings define the transmission of protocol messages. SAML profiles define constraints on assertions, bindings, and protocols for specific business use cases (attribute profiles define the exchange of attribute information with assertions).
SAML 2 Assertions
Assertions package the information supplying a SAML authority’s statements. They usually refer to a subject. SAML authorities can create three assertion statements: authentication, attribute, and authorization decision statements.
SAML 2 Protocols
SAML protocols for requests and responses include:
- Authentication request protocol—specifies how a principal requests assertions with authentication (and sometimes attribute) statements.
- Single logout protocol—specifies a universal logout mechanism across a principal’s active sessions.
- Assertion query and request protocol—specifies queries to obtain SAML assertions. A request form can require the asserting party to refer to existing assertions’ IDs, while a query form defines how relying parties can request assertions.
- Artifact resolution protocol—specifies the mechanism for passing SAML protocol messages by referencing artifacts (fixed-length values). An artifact receiver can request that message creators dereference artifacts and return actual protocol messages.
- Name identifier management protocol—specifies how to modify the name identifier’s format or value. The request’s issuer can be an identity or service provider. This protocol can also terminate a name identifier’s association.
- Name identifier mapping protocol—specifies the programmatic mapping of SAML name identifiers into others, permitting an SP to request an identifier from an IdP.
SAML 2 Bindings
A SAML binding details how transport protocols transfer a SAML protocol message. Examples include the HTTP redirect, HTTP POST, HTTP artifact, SAML SOAP, reverse SOAP, and SAML URI (uniform resource identifier) bindings.
SAML 2 Profiles
A SAML profile defines how SAML bindings, protocols, and assertions combine to enable interoperability. Examples include:
- Web browser SSO profile—specifies how SAML entities use the SAML response messages and Authentication Request Protocol to enable single sign-on (SSO) on web browsers.
- ECP profile—specifies an enhanced SSO profile for clients and proxies.
- Identity provider discovery profile—provides a mechanism for SPs to learn about a user’s IdPs.
- Single logout profile—specifies using the single logout protocol with certain bindings.
- Assertion query/request profile—specifies the use of the query and request protocol to obtain a SAML assertion.
- Artifact resolution profile—specifies how to obtain artifact-referenced protocol messages over synchronous bindings.
Other profiles include the name identifier management and mapping profiles.
SAML 2 Metadata
Metadata is important for several SAML uses, including providing the information needed for a service provider to know the IdP is legitimate and letting the identity provider know the SP is legitimate. It also tells the SP where to send users requesting authentication. For example, SPs and IdPs have metadata lists of trusted providers.
Metadata enables secure transactions between identity providers and service providers. It makes it easier to share trust-building information and improve interoperability.
SAML 2 with Frontegg
With Frontegg, plug-and-play SAML 2 authentication is available for any provider. Additionally, we are enhancing the configuration experience by providing a self-served Admin Portal for your end customers. They can configure the SAML 2, define allowed domains, and do their claims mapping alone, without any need for technical support.
Once authentication and user experience go hand in hand, business growth follows. Not sure how it works? Try it out now.