Why saml 2.0

SAML implements a secure method of passing user authentications and authorizations between the identity provider and service providers. When a user logs into a SAML enabled application, the service provider requests authorization from the appropriate identity provider. SAML authorization tells the service provider what access to grant the authenticated user. A SAML provider is a system that helps a user access a service they need.

There are two primary types of SAML providers, service provider, and identity provider. A service provider needs the authentication from the identity provider to grant authorization to the user. Microsoft Active Directory or Azure are common identity providers. Salesforce and other CRM solutions are usually service providers, in that they depend on an identity provider for user authentication.

There are three different types of SAML Assertions — authentication, attribute, and authorization decision. SAML works by passing information about users, logins, and attributes between the identity provider and service providers.

Each user logs in once to Single Sign On with the identify provider, and then the identify provider can pass SAML attributes to the service provider when the user attempts to access those services. The service provider requests the authorization and authentication from the identify provider. Identity provider-initiated SSO is similar and consists of only the bottom half of the flow. Have a how-to question? Seeing a weird error? Ask us about it on StackOverflow.

Found a bug? Submit a support ticket. Have a product idea or request? Madsen, et al. SAML V2. Document ID sstc-saml-exec-overview Hodges et al. Document ID saml-glossary Scavo, et al. Document ID sstc-saml-metadata-ext-query-cd Whitehead et al. Document ID sstc-saml1x-metadata-cd Document ID saml-metadata Document ID saml-profiles Document ID sstc-saml-protocol-ext-thirdparty-cd Hirsch et al.

Document ID saml-sec-consider Randall et al. Document ID sstc-saml-xauthn-attrib-profile-cd Morris et al. Document ID sstc-saml-xpath-attribute-profile-cd Shibboleth Overview and Requirements. Shibboleth project of Internet2. Nadalin et al. Document ID wss-v1. Monzillo et al. Moses, et al. Eastlake et al.

World Wide Web Consortium. This security information is expressed in the form of portable SAML assertions that applications working across security domain boundaries can trust.

The SSTC has produced this technical overview to assist those wanting to know more about SAML by explaining the business use cases it addresses, the high-level technical components that make up a SAML deployment, details of message exchanges for common use cases, and where to go for additional information. Why is SAML needed for exchanging security information? There are several drivers behind the adoption of the SAML standard, inc luding:.

Single Sign-On: Over the years, various products have been marketed with the claim of providing support for web-based SSO. These products have typically relied on browser cookies to maintain user authentication state information so that re-authentication is not required each time the web user accesses the system.

However, since browser cookies are never transmitted between DNS domains, the authentication state information in the cookies from one domain is never available to another domain. Therefore, these products have typically supported multi-domain SSO MDSSO through the use of proprietary mechanisms to pass the authentication state information between the domains. While the use of a single vendor's product may sometimes be viable within a single enterprise, business partners usually have heterogeneous environments that make the use of proprietary protocols impractical for MDSSO.

SAML solves the MDSSO problem by providing a standard vendor-independent grammar and protocol for transferring information about a user from one web server to another independent of the server DNS domains. Federated identity: When online services wish to establish a collaborative application environment for their mutual users, not only must the systems be able to understand the protocol syntax and semantics involved in the exchange of information; they must also have a common understanding of who the user is that is referred to in the exchange.

Users often have individual local user identities within the security domains of each partner with which they interact. Identity federation provides a means for these partner services to agree on and establish a common, shared name identifier to refer to the user in order to share information about the user across the organizational boundaries.

The user is said to have a federated identity when partners have established such an agreement on how to refer to the user. From an administrative perspective, this type of sharing can help reduce identity management costs as multiple services do not need to independently collect and maintain identity-related data e. In addition, administrators of these services usually do not have to manually establish and maintain the shared identifiers; rather control for this can reside with the user.

In particular, the advantage offered by the use of a SAML assertion is that it provides a standards-based approach to the exchange of information, including attributes, that are not easily conveyed using other WS-Security token formats.

The lighter-colored boxes represent non-normative information. Conformance Requirements documents the technical requirements for SAML conformance, a status that software vendors typically care about because it is one measure of cross-product compatibility. Assertions and Protocol defines the syntax and semantics for creating XML-encoded assertions to describe authentication, attribute, and authorization information, and for the protocol messages to carry this information between systems.

It has associated schemas, one for assertions and one for protocols. Bindings defines how SAML assertions and request-response protocol messages can be exchanged between systems using common underlying communication protocols and frameworks. Profiles defines specific sets of rules for using and restricting SAML's rich and flexible syntax for conveying security information to solve specific business problems for example, to perform a web SSO exchange.

It has several associated small schemas covering syntax aspects of attribute profiles. Metadata defines how a SAML entity can describe its configuration data e. It has an associated schema. Authentication Context defines a syntax for describing authentication context declarations which describe various authentication mechanisms.

It has an associated set of schemas. This is a non-normative document. Glossary normatively defines terms used throughout the SAML specifications. Where possible, terms are aligned with those defined in other security glossaries. Although the advice offered in this document is non-normative, it is useful as a guide to the likely interpretations used by implementors of SAML-conforming software, and is likely to be incorporated in any future revision to the standard.

This document is updated on an ongoing basis. SAML V1. Defines an extension to the SAML protocol to facilitate requests made by entities other than the intended response recipient. Prior to examining details of the SAML standard, it's useful to describe some of the high-level use cases it addresses. More detailed use cases are described later in this document along with specific SAML profiles. Who are the participants involved in a SAML interaction? In many SAML use cases, a user, perhaps running a web browser or executing a SAML-enabled application, is also a participant, and may even be the asserting party.

An asserting party is a system entity that makes SAML assertions. It is also sometimes called a SAML authority. A relying party is a system entity that uses assertions it has received. A replying party's willingness to rely on information from an asserting party depends on the existence of a trust relationship with the asserting party.

Another example is the attribute authority role where a SAML entity produces assertions in response to identity attribute queries from an entity acting as an attribute requester.

At the heart of most SAML assertions is a subject a principal — an entity that can be authenticated — within the context of a particular security domain about which something is being asserted. The subject could be a human but could also be some other kind of entity, such as a company or a computer. The terms subject and principal tend to be used interchangeably in this document.

Multi-domain web single sign-on is arguably the most important use case for which SAML is applied. In this use case, a user has a login session that is, a security context on a web site airline.

At some point, either explicitly or transparently, he is directed over to a partner's web site cars. In this case, we assume that a federated identity for the user has been previously established between airline. The identity provider site airline. Since cars. This use case is shown in Figure 2 , which illustrates the fact that the user is not required to re-authenticate when directed over to the cars.

This high-level description indicated that the user had first authenticated at the IdP before accessing a protected resource at the SP. While IdP-initiated SSO is useful in certain cases, a more common scenario starts with a user visiting an SP site through a browser bookmark, possibly first accessing resources that require no special authentication or authorization. In a SAML-enabled deployment, when they subsequently attempt to access a protected resource at the SP, the SP will send the user to the IdP with an authentication request in order to have the user log in.

Once logged in, the IdP can produce an assertion that can be used by the SP to validate the user's access rights to the protected resource. SAML supports numerous variations on these two primary flows that deal with requirements for using various types and strengths of user authentication methods, alternative formats for expressing federated identities, use of different bindings for transporting the protocol messages, inclusion of identity attributes, etc.

Many of these options are looked at in more detail in later sections of this document. There are many questions that must be considered when business partners decide to use federated identities to share security and identity information about users. For example:. Do the users have existing local identities at the sites that must be linked together through the federated identifiers?

Will the establishment and termination of federated identifiers for the users be done dynamically or will the sites use pre-established federated identifiers? Do users need to explicitly consent to establishment of the federated identity? Should the identity federation rely on transient identifiers that are destroyed at the end of the user session? Is the privacy of information to be exchanged of high concern such that the information should be encrypted?

Previous versions of the SAML standard relied on out-of-band agreement on the types of identifiers that would be used to represent a federated identity between partners e.

While it supported the use of federated identities, it provided no means to directly establish the identifiers for those identities using SAML message exchanges. First, new constructs and messages were added to support the dynamic establishment and management of federated name identifiers. Second, two new types of name identifiers were introduced with privacy-preserving characteristics. In some cases, exchanges of identity-related federation information may take place outside of the SAML V2.

Subsequently, the user's federated identity may be used in a SAML assertion and propagated between providers to implement single sign-on or to exchange identity attributes about the user. Alternatively, identity federation may be achieved purely by a business agreement that states that an identity provider will refer to a user based on certain attribute names and values, with no additional flows required for maintaining and updating user information between providers.

The high-level identity federation use case described here demonstrates how SAML can use the new features to dynamically establish a federated identity for a user during a web SSO exchange. Most identity management systems maintain local identities for users. These local identities might be represented by the user's local login account or some other locally identifiable user profile. These local identities must be linked to the federated identity that will be used to represent the user when the provider interacts with a parter.

The process of associating a federated identifier with the local identity at a partner or partners where the federated identity will be used is often called account linking.

This use case, shown in Figure 3, demonstrates how, during web SSO, the sites can dynamically establish the federated name identifiers used in the account linking process. One identity provider, airline. The example assumes a user is registered on all three provider sites i. At airline. The sites have established an agreement to use persistent SAML privacy-preserving pseudonyms for the user's federated name identifiers.

John has not previously federated his identities between these sites. John books a flight at airline. John then uses a browser bookmark or clicks on a link to visit cars.

This site sees that the browser user is not logged in locally but that he has previously visited their IdP partner site airline. So cars. John consents to the federation and his browser is redirected back to airline. The pseudonym is linked to his johndoe account. Both providers agree to use this identifier to refer to John in subsequent transactions. John is then redirected back to cars.

Since this is the first time that cars. Thus, John must log in at cars. Then cars. After reserving a car, John selects a browser bookmark or clicks on a link to visit hotels. The federation process is repeated with the IdP airline. John is redirected back to the hotels. The SP requires John to log into his local johnd user account and adds the pseudonym as the federated name identifier for future use with the IdP airline.

In the future, whenever John needs to books a flight, car, and hotel, he will only need to log in once to airline. The airline. Each SP will locate John 's local user account through the linked persistent pseudonyms and allow John to conduct business after the SSO exchange. This section provides a brief description of the key SAML concepts and the components defined in the standard. SAML consists of building-block components that, when put together, allow a number of use cases to be supported.

The components primarily permit transfer of identity, authentication, attribute, and authorization information between autonomous organizations that have an established trust relationship. The core SAML specification defines the structure and content of both assertions and protocol messages used to transfer this information.

SAML assertions carry statements about a principal that an asserting party claims to be true. Assertions are usually created by an asserting party based on a request of some sort from a relying party, although under certain circumstances, the assertions can be delivered to a relying party in an unsolicited manner. Profiles typically define constraints on the contents of SAML assertions, protocols, and bindings in order to solve the business use case in an interoperable fashion.

There are also Attribute Profiles, which do not refer to any protocol messages and bindings, that define how to exchange attribute information using assertions in ways that align with a number of common usage environments e. Figure 4 illustrates the relationship between these basic SAML concepts. Metadata defines a way to express and share configuration information between SAML parties. In a number of situations, a service provider may need to have detailed information regarding the type and strength of authentication that a user employed when they authenticated at an identity provider.

A SAML authentication context is used in or referred to from an assertion's authentication statement to carry this information. An SP can also include an authentication context in a request to an IdP to request that the user be authenticated using a specific set of authentication requirements, such as a multi-factor authentication.

There is a general XML schema that defines the mechanisms for creating authentication context declarations and a set of SAML-defined Authentication Context Classes, each with their own XML schema, that describe commonly used methods of authentication. It should be noted that the story of SAML need not end with its published set of assertions, protocols, bindings, and profiles.

It is designed to be highly flexible, and thus it comes with extensibility points in its XML schemas, as well as guidelines for custom-designing new bindings and profiles in such a way as to ensure maximum interoperability. In practical terms, what SubjectConfirmation says is "these are the conditions under which an attesting entity somebody trying to use the assertion is permitted to do so". The entity trying to use the assertion, or the "wielder", is attesting to its right to do so, usually by implying a relationship with the subject.

An assertion can have any number of SubjectConfirmation elements, but an attesting entity only has to satisfy one of them.