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.
SAML authentication is widely adopted by enterprises, for several reasons:
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.
Read more about SSO best practices in our detailed guide.
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).
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 protocols for requests and responses include:
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.
A SAML profile defines how SAML bindings, protocols, and assertions combine to enable interoperability. Examples include:
Other profiles include the name identifier management and mapping profiles.
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.
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. We also recommend checking out the top SSO providers in the market today.
Once authentication and user experience go hand in hand, business growth follows. Not sure how it works? Try it out now.
Start For Free