SAML 2.0

Security Assertion Markup Language 2.0 is a version of the SAML standard for exchanging authentication and authorization identities between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal between a SAML authority, named an Identity Provider, and a SAML consumer, named a Service Provider. SAML 2.0 enables web-based, cross-domain single sign-on, which helps reduce the administrative overhead of distributing multiple authentication tokens to the user.
SAML 2.0 was ratified as an OASIS Standard in March 2005, replacing SAML 1.1. The critical aspects of SAML 2.0 are covered in detail in the official documents SAMLCore, SAMLBind, SAMLProf, and SAMLMeta.
Some 30 individuals from more than 24 companies and organizations were involved in the creation of SAML 2.0. In particular, and of special note, Liberty Alliance donated its Identity Federation Framework specification to OASIS, which became the basis of the SAML 2.0 specification. Thus SAML 2.0 represents the convergence of SAML 1.1, , and .

SAML 2.0 assertions

An assertion is a package of information that supplies zero or more statements made by a SAML authority. SAML assertions are usually made about a subject, represented by the element. The SAML 2.0 specification defines three different kinds of assertion statements that can be created by a SAML authority. All SAML-defined statements are associated with a subject. The three kinds of statements defined are as follows:

Authentication Assertion: The assertion subject was authenticated by a particular means at a particular time.
Attribute Assertion: The assertion subject is associated with the supplied attributes.
Authorization Decision Assertion: A request to allow the assertion subject to access the specified resource has been granted or denied.

An important type of SAML assertion is the so-called "bearer" assertion used to facilitate Web Browser SSO. Here is an example of a short-lived bearer assertion issued by an identity provider to a service provider. The assertion includes both an Authentication Assertion and an Attribute Assertion , which presumably the service provider uses to make an access control decision. The prefix saml: represents the SAML V2.0 assertion namespace.

Example of SAML

xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
ID="_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
https://idp.example.org/SAML2
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...

Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
3f7b3dcf-1674-4ecd-92c8-1544f346baf8

Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
InResponseTo="aaf23196-1773-2113-474a-fe114412ab72"
Recipient="https://sp.example.com/SAML2/SSO/POST"
NotOnOrAfter="2004-12-05T09:27:05Z"/>

NotBefore="2004-12-05T09:17:05Z"
NotOnOrAfter="2004-12-05T09:27:05Z">

https://sp.example.com/SAML2

AuthnInstant="2004-12-05T09:22:00Z"
SessionIndex="b07b804c-7c29-ea16-7300-4f3d6f7928ac">

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
x500:Encoding="LDAP"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
FriendlyName="eduPersonAffiliation">
xsi:type="xs:string">member
xsi:type="xs:string">staff

Note that in the above example the element contains the following child elements:

a element, which contains the unique identifier of the identity provider
a element, which contains an integrity-preserving digital signature over the element
a element, which identifies the authenticated principal
a element, which gives the conditions under which the assertion is to be considered valid
a element, which describes the act of authentication at the identity provider
a element, which asserts a multi-valued attribute associated with the authenticated principal

In words, the assertion encodes the following information:

The assertion was issued at time "2004-12-05T09:22:05Z" by identity provider regarding subject exclusively for service provider.

The authentication statement, in particular, asserts the following:

The principal identified in the element was authenticated at time "2004-12-05T09:22:00Z" by means of a password sent over a protected channel.

Likewise the attribute statement asserts that:

The principal identified in the element is a staff member at this institution.

SAML 2.0 protocols

The following protocols are specified in SAMLCore:

Assertion Query and Request Protocol
[|Authentication Request Protocol]
[|Artifact Resolution Protocol]
Name Identifier Management Protocol
Single Logout Protocol
Name Identifier Mapping Protocol

The most important of these protocols—the Authentication Request Protocol—is discussed in detail below.

Authentication Request Protocol

In SAML 1.1 Web Browser SSO Profiles are initiated by the Identity Provider, that is, an unsolicited element is transmitted from the identity provider to the service provider.
In SAML 2.0, however, the flow begins at the service provider who issues an explicit authentication request to the identity provider. The resulting Authentication Request Protocol is a significant new feature of SAML 2.0.
When a principal wishes to obtain [|an assertion containing an authentication statement], a element is transmitted to the identity provider:

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="aaf23196-1773-2113-474a-fe114412ab72"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z"
AssertionConsumerServiceIndex="0"
AttributeConsumingServiceIndex="0">
https://sp.example.com/SAML2
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>

The above element, which implicitly requests an assertion containing an authentication statement, was evidently issued by a service provider and subsequently presented to the identity provider. The identity provider authenticates the principal and issues an authentication response, which is transmitted back to the service provider.

Artifact Resolution Protocol

A SAML message is transmitted from one entity to another either by value or by reference. A reference to a SAML message is called an artifact. The receiver of an artifact resolves the reference by sending a request directly to the issuer of the artifact, who then responds with the actual message referenced by the artifact.
Suppose, for example, that an identity provider sends the following request directly to a service provider :

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_cce4ee769ed970b501d680f697989d14"
Version="2.0"
IssueInstant="2004-12-05T09:21:58Z">
https://idp.example.org/SAML2

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...
AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8=

In response, the service provider returns the SAML element referenced by the enclosed artifact. This protocol forms the basis of the [|HTTP Artifact Binding].

SAML 2.0 bindings

The bindings supported by SAML 2.0 are outlined in the Bindings specification :

SAML SOAP Binding
Reverse SOAP Binding
[|HTTP Redirect Binding]
[|HTTP POST Binding]
HTTP Artifact Binding
SAML URI Binding

For Web Browser SSO, the HTTP Redirect Binding and the HTTP POST Binding are commonly used. For example, the service provider may use HTTP Redirect to send a request while the identity provider uses HTTP POST to transmit the response. This example illustrates that an entity's choice of binding is independent of its partner's choice of binding.

HTTP Redirect Binding

SAML protocol messages can be carried directly in the URL query string of an HTTP GET request. Since the length of URLs is limited in practice, the HTTP Redirect binding is suitable for short messages, such as the message. Longer messages are usually transmitted via other bindings such as the HTTP POST Binding.
SAML requests or responses transmitted via HTTP Redirect have a SAMLRequest or SAMLResponse query string parameter, respectively. Before it's sent, the message is deflated, base64-encoded, and URL-encoded, in that order. Upon receipt, the process is reversed to recover the original message.
For example, encoding the message above yields:
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=fZFfa8IwFMXfBb9DyXvaJtZ1BqsURRC2
Mabbw95ivc5Am3TJrXPffmmLY3%2FA15Pzuyf33On8XJXBCaxTRmeEhTEJQBdmr%2FRbRp63K3pL5rPhYOpkVdY
ib%2FCon%2BC9AYfDQRB4WDvRvWWksVoY6ZQTWlbgBBZik9%2FfCR7GorYGTWFK8pu6DknnwKL%2FWEetlxmR8s
BHbHJDWZqOKGdsRJM0kfQAjCUJ43KX8s78ctnIz%2Blp5xpYa4dSo1fjOKGM03i8jSeCMzGevHa2%2FBK5MNo1F
dgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1CWJgqanfl0%2Bin8xutxYOvZL18NK
UqPlvZR5el%2BVhYkAgZQdsA6fWVsZXE63W2itrTQ2cVaKV2CjSSqL1v9P%2FAXv4C
The above message may be signed for additional security. In practice, all the data contained in a , such as Issuer which contains the SP ID, and NameIDPolicy, has been agreed between IdP and SP beforehand. In that case signing the request is not a security constraint. When the contains information not known by the IdP beforehand, such as Assertion Consumer Service URL, signing the request is recommended for security purposes.

HTTP POST Binding

In the following example, both the service provider and the identity provider use an HTTP POST binding. Initially, the service provider responds to a request from the user agent with a document containing an XHTML form:

The value of the SAMLRequest parameter is the base64-encoding of a element, which is transmitted to the identity provider via the browser. The SSO service at the identity provider validates the request and responds with a document containing another XHTML form:

The value of the SAMLResponse parameter is the base64 encoding of a element, which likewise is transmitted to the service provider via the browser.
To automate the submission of the form, the following line of JavaScript may appear anywhere on the XHTML page:

window.onload = function

This assumes, of course, that the first form element in the page contains the above SAMLResponse containing form element.

HTTP Artifact Binding

The HTTP Artifact Binding uses the Artifact Resolution Protocol and the SAML SOAP Binding to resolve a SAML message by reference. Consider the following specific example. Suppose a service provider wants to send a message to an identity provider. Initially, the service provider transmits an artifact to the identity provider via an HTTP redirect:
https://idp.example.org/SAML2/SSO/Artifact?SAMLart=artifact
Next the identity provider sends a request directly to the service provider via a back channel. Finally, the service provider returns a element containing the referenced message:

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="_d84a49e5958803dedcff4c984c2b0d95"
InResponseTo="_cce4ee769ed970b501d680f697989d14"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z">

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...

Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_306f8ec5b618f361c70b6ffb1480eade"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z"
Destination="https://idp.example.org/SAML2/SSO/Artifact"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
AssertionConsumerServiceURL="https://sp.example.com/SAML2/SSO/Artifact">
https://sp.example.com/SAML2
AllowCreate="false"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>

Of course the flow can go in the other direction as well, that is, the identity provider may issue an artifact, and in fact this is more common. See, for example, the "double artifact" profile example later in this topic.

Artifact format

In general, a SAML 2.0 artifact is defined as follows :
SAML_artifact := B64
TypeCode := Byte1Byte2
EndpointIndex := Byte1Byte2
Thus a SAML 2.0 artifact consists of three components: a two-byte TypeCode, a two-byte EndpointIndex, and an arbitrary sequence of bytes called the RemainingArtifact. These three pieces of information are concatenated and base64-encoded to yield the complete artifact.
The TypeCode uniquely identifies the artifact format. SAML 2.0 predefines just one such artifact, of type 0x0004. The EndpointIndex is a reference to a particular artifact resolution endpoint managed by the artifact issuer. The RemainingArtifact, which is determined by the type definition, is the "meat" of the artifact.
The format of a type 0x0004 artifact is further defined as follows:
TypeCode := 0x0004
RemainingArtifact := SourceId MessageHandle
SourceId := 20-byte_sequence
MessageHandle := 20-byte_sequence
Thus a type 0x0004 artifact is of size 44 bytes. The SourceId is an arbitrary sequence of bytes, although in practice, the SourceId is the SHA-1 hash of the issuer's entityID. The MessageHandle is a random sequence of bytes that references a SAML message that the artifact issuer is willing to produce on-demand.
For example, consider this hex-encoded type 0x0004 artifact:
00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f
If you look closely, you can see the TypeCode and the EndpointIndex at the front of the artifact. The next 20 bytes are the SHA-1 hash of the issuer's entityID followed by 20 random bytes. The base64-encoding of these 44 bytes is what you see in the [|ArtifactResolveRequest] example above.

SAML 2.0 profiles

In SAML 2.0, as in SAML 1.1, the primary use case is still Web Browser SSO, but the scope of SAML 2.0 is broader than previous versions of SAML, as suggested in the following exhaustive list of profiles:

SSO Profiles
* [|Web browser SSO profile]
* Enhanced Client or Proxy Profile
* [|Identity Provider Discovery Profile]
* Single Logout Profile
* Name Identifier Management Profile
Artifact Resolution Profile
[|Assertion Query/Request Profile]
Name Identifier Mapping Profile
SAML Attribute Profiles
* Basic Attribute Profile
* X.500/LDAP Attribute Profile
* UUID Attribute Profile
* DCE PAC Attribute Profile
* XACML Attribute Profile

Although the number of supported profiles is quite large, the Profiles specification is simplified since the binding aspects of each profile have been factored out into a separate Bindings specification.

Web browser SSO profile

SAML 2.0 specifies a Web Browser SSO Profile involving an identity provider, a service provider, and a principal wielding an HTTP user agent. The service provider has four bindings from which to choose while the identity provider has three, which leads to twelve possible deployment scenarios. We outline three of those deployment scenarios below.

SP redirect request; IdP POST response

This is one of the most common scenarios. The service provider sends a SAML Request to the IdP SSO Service using the HTTP-Redirect Binding. The identity provider returns the SAML Response to the SP Assertion Consumer Service using the HTTP-POST Binding.
The message flow begins with a request for a secured resource at the service provider.
1. Request the target resource at the SP
The principal requests a target resource at the service provider:
https://sp.example.com/myresource
The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2-7.
The service provider may use any kind of mechanism to discover the identity provider that will be used, e.g., ask the user, use a preconfigured IdP, etc.
2. Redirect to IdP SSO Service
The service provider generates an appropriate SAMLRequest, then redirects the browser to the IdP SSO Service using a standard HTTP 302 redirect.

302 Redirect
Location: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

The RelayState token is an opaque reference to state information maintained at the service provider. The value of the SAMLRequest parameter is a deflated, base64-encoded and URL-encoded value of an element:

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z"
AssertionConsumerServiceIndex="0">
https://sp.example.com/SAML2
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>

The SAMLRequest may be signed using the SP signing key. Typically, however, this is not necessary.
3. Request the SSO Service at the IdP
The user agent issues a GET request to the SSO service at the identity provider:

GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token HTTP/1.1
Host: idp.example.org

where the values of the SAMLRequest and RelayState parameters are the same as those provided in the redirect. The SSO Service at the identity provider processes the element and performs a security check. If the user does not have a valid security context, the identity provider identifies the user with any mechanism.
4. Respond with an XHTML form
The SSO Service validates the request and responds with a document containing an XHTML form:

The value of the RelayState parameter has been preserved from step 3. The value of the SAMLResponse parameter is the base64 encoding of the following element:

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_2"
InResponseTo="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z"
Destination="https://sp.example.com/SAML2/SSO/POST">
https://idp.example.org/SAML2

Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_3"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
https://idp.example.org/SAML2

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...

Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
3f7b3dcf-1674-4ecd-92c8-1544f346baf8

Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
InResponseTo="identifier_1"
Recipient="https://sp.example.com/SAML2/SSO/POST"
NotOnOrAfter="2004-12-05T09:27:05Z"/>

NotBefore="2004-12-05T09:17:05Z"
NotOnOrAfter="2004-12-05T09:27:05Z">

https://sp.example.com/SAML2

AuthnInstant="2004-12-05T09:22:00Z"
SessionIndex="identifier_3">

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

5. Request the Assertion Consumer Service at the SP
The user agent issues a POST request to the Assertion Consumer Service at the service provider:

POST /SAML2/SSO/POST HTTP/1.1
Host: sp.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
SAMLResponse=response&RelayState=token

where the values of the SAMLResponse and RelayState parameters are taken from the XHTML form at step 4.
6. Redirect to the target resource
The assertion consumer service processes the response, creates a security context at the service provider and redirects the user agent to the target resource.
7. Request the target resource at the SP again
The user agent requests the target resource at the service provider :
https://sp.example.com/myresource
8. Respond with requested resource
Since a security context exists, the service provider returns the resource to the user agent.

SP POST Request; IdP POST Response

This is a relatively simple deployment of the SAML 2.0 Web Browser SSO Profile where both the service provider and the identity provider use the HTTP POST binding.
The message flow begins with a request for a secured resource at the SP.
1. Request the target resource at the SP
The principal requests a target resource at the service provider:
https://sp.example.com/myresource
The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2-7.
2. Respond with an XHTML form
The service provider responds with a document containing an XHTML form:

The RelayState token is an opaque reference to state information maintained at the service provider. The value of the SAMLRequest parameter is the base64 encoding of the following element:

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z"
AssertionConsumerServiceIndex="0">
https://sp.example.com/SAML2
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>

Before the element is inserted into the XHTML form, it is first base64-encoded.
3. Request the SSO Service at the IdP
The user agent issues a POST request to the SSO service at the identity provider:

POST /SAML2/SSO/POST HTTP/1.1
Host: idp.example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
SAMLRequest=request&RelayState=token

where the values of the SAMLRequest and RelayState parameters are taken from the XHTML form at step 2. The SSO service processes the element and performs a security check. If the user does not have a valid security context, the identity provider identifies the user.
4. Respond with an XHTML form
The SSO service validates the request and responds with a document containing an XHTML form:

The value of the RelayState parameter has been preserved from step 3. The value of the SAMLResponse parameter is the base64 encoding of the following element:

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_2"
InResponseTo="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z"
Destination="https://sp.example.com/SAML2/SSO/POST">
https://idp.example.org/SAML2

Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_3"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
https://idp.example.org/SAML2

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...

Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
3f7b3dcf-1674-4ecd-92c8-1544f346baf8

Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
InResponseTo="identifier_1"
Recipient="https://sp.example.com/SAML2/SSO/POST"
NotOnOrAfter="2004-12-05T09:27:05Z"/>

NotBefore="2004-12-05T09:17:05Z"
NotOnOrAfter="2004-12-05T09:27:05Z">

https://sp.example.com/SAML2

AuthnInstant="2004-12-05T09:22:00Z"
SessionIndex="identifier_3">

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

5. Request the Assertion Consumer Service at the SP
The user agent issues a POST request to the assertion consumer service at the service provider:

POST /SAML2/SSO/POST HTTP/1.1
Host: sp.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
SAMLResponse=response&RelayState=token

where the values of the SAMLResponse and RelayState parameters are taken from the XHTML form at step 4.
6. Redirect to the target resource
The assertion consumer service processes the response, creates a security context at the service provider and redirects the user agent to the target resource.
7. Request the target resource at the SP again
The user agent requests the target resource at the service provider :
https://sp.example.com/myresource
8. Respond with requested resource
Since a security context exists, the service provider returns the resource to the user agent.

SP redirect artifact; IdP redirect artifact

This is a complex deployment of the SAML 2.0 Web Browser SSO Profile where both the service provider and the identity provider use the HTTP Artifact binding. Both artifacts are delivered to their respective endpoints via HTTP GET.
The message flow begins with a request for a secured resource at the SP:
1. Request the target resource at the SP
The principal requests a target resource at the service provider:
https://sp.example.com/myresource
The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2-11.
2. Redirect to the Single Sign-on Service at the IdP
The service provider redirects the user agent to the single sign-on service at the identity provider. A RelayState parameter and a SAMLart parameter are appended to the redirect URL.
3. Request the SSO Service at the IdP
The user agent requests the SSO service at the identity provider:
https://idp.example.org/SAML2/SSO/Artifact?SAMLart=artifact_1&RelayState=token
where token is an opaque reference to state information maintained at the service provider and artifact_1 is a SAML artifact, both issued at step 2.
4. Request the Artifact Resolution Service at the SP
The SSO service dereferences the artifact by sending a element bound to a SAML SOAP message to the artifact resolution service at the service provider:

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:21:58Z"
Destination="https://sp.example.com/SAML2/ArtifactResolution">
https://idp.example.org/SAML2

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...
artifact_1

where the value of the element is the SAML artifact transmitted at step 3.
5. Respond with a SAML AuthnRequest
The artifact resolution service at the service provider returns a element bound to a SAML SOAP message to the SSO service at the identity provider:

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="identifier_2"
InResponseTo="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z">

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...

Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_3"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z"
Destination="https://idp.example.org/SAML2/SSO/Artifact"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
AssertionConsumerServiceURL="https://sp.example.com/SAML2/SSO/Artifact">
https://sp.example.com/SAML2
AllowCreate="false"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>

The SSO service processes the element and performs a security check. If the user does not have a valid security context, the identity provider identifies the user.
6. Redirect to the Assertion Consumer Service
The SSO service at the identity provider redirects the user agent to the assertion consumer service at the service provider. The previous RelayState parameter and a new SAMLart parameter are appended to the redirect URL.
7. Request the Assertion Consumer Service at the SP
The user agent requests the assertion consumer service at the service provider:
https://sp.example.com/SAML2/SSO/Artifact?SAMLart=artifact_2&RelayState=token
where token is the token value from step 3 and artifact_2 is the SAML artifact issued at step 6.
8. Request the Artifact Resolution Service at the IdP
The assertion consumer service dereferences the artifact by sending a element bound to a SAML SOAP message to the artifact resolution service at the identity provider:

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_4"
Version="2.0"
IssueInstant="2004-12-05T09:22:04Z"
Destination="https://idp.example.org/SAML2/ArtifactResolution">
https://sp.example.com/SAML2

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...
artifact_2

where the value of the element is the SAML artifact transmitted at step 7.
9. Respond with a SAML Assertion
The artifact resolution service at the identity provider returns a element bound to a SAML SOAP message to the assertion consumer service at the service provider:

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="identifier_5"
InResponseTo="identifier_4"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...

Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_6"
InResponseTo="identifier_3"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z"
Destination="https://sp.example.com/SAML2/SSO/Artifact">
https://idp.example.org/SAML2
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...

Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_7"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
https://idp.example.org/SAML2

Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
[email protected]

Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
InResponseTo="identifier_3"
Recipient="https://sp.example.com/SAML2/SSO/Artifact"
NotOnOrAfter="2004-12-05T09:27:05Z"/>

NotBefore="2004-12-05T09:17:05Z"
NotOnOrAfter="2004-12-05T09:27:05Z">

https://sp.example.com/SAML2

AuthnInstant="2004-12-05T09:22:00Z"
SessionIndex="identifier_7">

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

10. Redirect to the target resource
The assertion consumer service processes the response, creates a security context at the service provider and redirects the user agent to the target resource.
11. Request the target resource at the SP again
The user agent requests the target resource at the service provider :
https://sp.example.com/myresource
12. Respond with the requested resource
Since a security context exists, the service provider returns the resource to the user agent.

Identity provider discovery profile

The SAML 2.0 Identity Provider Discovery Profile introduces the following concepts:

Common Domain
Common Domain Cookie
Common Domain Cookie Writing Service
Common Domain Cookie Reading Service

As a hypothetical example of a Common Domain, let's suppose Example UK and Example Deutschland belong to the virtual organization Example Global Alliance. In this example, the domain example.com is the common domain. Both Example UK and Example Deutschland have a presence in this domain.
The Common Domain Cookie is a secure browser cookie scoped to the common domain. For each browser user, this cookie stores a history list of recently visited IdPs. The name and value of the cookie are specified in the IdP Discovery Profile.
After a successful act of authentication, the IdP requests the Common Domain Cookie Writing Service. This service appends the IdP's unique identifier to the common domain cookie. The SP, when it receives an unauthenticated request for a protected resource, requests the Common Domain Cookie Reading Service to discover the browser user's most recently used IdP.

Assertion query/request profile

The Assertion Query/Request Profile is a general profile that accommodates numerous types of so-called queries using the following SAML 2.0 elements:

the element, which is used to request an assertion given its unique identifier
the element, which is an abstract extension point that allows new subject-based SAML queries to be defined
the element, which is used to request existing authentication assertions about a given subject from an Authentication Authority
the element, which is used to request attributes about a given subject from an Attribute Authority
the element, which is used to request an authorization decision from a trusted third party

The SAML SOAP binding is often used in conjunction with queries.

SAML attribute query

The Attribute Query is perhaps the most important type of SAML query. Often a requester, acting on behalf of the principal, queries an identity provider for attributes. Below we give an example of a query issued by a principal directly:

xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="aaf23196-1773-2113-474a-fe114412ab72"
Version="2.0"
IssueInstant="2006-07-17T20:31:40Z">
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
[email protected],OU=User,O=NCSA-TEST,C=US

Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
[email protected],OU=User,O=NCSA-TEST,C=US

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:2.5.4.42"
FriendlyName="givenName">

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.26"
FriendlyName="mail">

Note that the Issuer is the Subject in this case. This is sometimes called an attribute self-query. An identity provider might return the following assertion, wrapped in a element :

xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
ID="_33776a319493ad607b7ab3e689482e45"
Version="2.0"
IssueInstant="2006-07-17T20:31:41Z">
https://idp.example.org/SAML2
...

Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
[email protected],OU=User,O=NCSA-TEST,C=US

Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">

MIICiDCCAXACCQDE+9eiWrm62jANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJV
UzESMBAGA1UEChMJTkNTQS1URVNUMQ0wCwYDVQQLEwRVc2VyMRMwEQYDVQQDEwpT
UC1TZXJ2aWNlMB4XDTA2MDcxNzIwMjE0MVoXDTA2MDcxODIwMjE0MVowSzELMAkG
A1UEBhMCVVMxEjAQBgNVBAoTCU5DU0EtVEVTVDENMAsGA1UECxMEVXNlcjEZMBcG
A1UEAwwQdHJzY2F2b0B1aXVjLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv9QMe4lRl3XbWPcflbCjGK9gty6zBJmp+tsaJINM0VaBaZ3t+tSXknelYife
nCc2O3yaX76aq53QMXy+5wKQYe8Rzdw28Nv3a73wfjXJXoUhGkvERcscs9EfIWcC
g2bHOg8uSh+Fbv3lHih4lBJ5MCS2buJfsR7dlr/xsadU2RcCAwEAATANBgkqhkiG
9w0BAQQFAAOCAQEAdyIcMTob7TVkelfJ7+I1j0LO24UlKvbLzd2OPvcFTCv6fVHx
Ejk0QxaZXJhreZ6+rIdiMXrEzlRdJEsNMxtDW8++sVp6avoB5EX1y3ez+CEAIL4g
cjvKZUR4dMryWshWIBHKFFul+r7urUgvWI12KbMeE9KP+kiiiiTskLcKgFzngw1J
selmHhTcTCrcDocn5yO2+d3dog52vSOtVFDBsBuvDixO2hv679JR6Hlqjtk4GExp
E9iVI0wdPE038uQIJJTXlhsMMLvUGVh/c0ReJBn92Vj4dI/yy6PtY/8ncYLYNkjg
oVN0J/ymOktn9lTlFyTiuY4OuJsZRO1+zWLy9g

NotBefore="2006-07-17T20:31:41Z"
NotOnOrAfter="2006-07-18T20:21:41Z">

AuthnInstant="2006-07-17T20:31:41Z">

urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient

xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
x500:Encoding="LDAP"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:2.5.4.42"
FriendlyName="givenName">
xsi:type="xs:string">Tom

xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
x500:Encoding="LDAP"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.26"
FriendlyName="mail">
xsi:type="xs:string">[email protected]

In contrast to the [|BearerAssertion] shown earlier, this assertion has a longer lifetime corresponding to the lifetime of the X.509 certificate that the principal used to authenticate to the identity provider. Moreover, since the assertion is signed, the user can push this assertion to a relying party, and as long as the user can prove possession of the corresponding private key, the relying party can be assured that the assertion is authentic.

SAML 2.0 metadata

Quite literally, metadata is what makes SAML work. Some important uses of metadata include:

A service provider prepares to transmit a element to an identity provider via the browser. How does the service provider know the identity provider is authentic and not some evil identity provider trying to phish the user's password? The service provider consults its list of trusted identity providers in metadata before issuing an authentication request.
In the previous scenario, how does the service provider know where to send the user with the authentication request? The service provider looks up a pre-arranged endpoint location of the trusted identity provider in metadata.
An identity provider receives a element from a service provider via the browser. How does the identity provider know the service provider is authentic and not some evil service provider trying to harvest personally identifiable information regarding the user? The identity provider consults its list of trusted service providers in metadata before issuing an authentication response.
In the previous scenario, how does the identity provider encrypt the SAML assertion so that the trusted service provider can decrypt the assertion. The identity provider uses the service provider's encryption certificate in metadata to encrypt the assertion.
Continuing with the previous scenario, how does the identity provider know where to send the user with the authentication response? The identity provider looks up a pre-arranged endpoint location of the trusted service provider in metadata.
How does the service provider know that the authentication response came from a trusted identity provider? The service provider verifies the signature on the assertion using the public key of the identity provider from metadata.
How does the service provider know where to resolve an artifact received from a trusted identity provider? The service provider looks up the pre-arranged endpoint location of the identity provider's artifact resolution service from metadata.

Metadata ensures a secure transaction between an identity provider and a service provider. Before metadata, trust information was encoded into the implementation in a proprietary manner. Now the sharing of trust information is facilitated by standard metadata. SAML 2.0 provides a well-defined, interoperable metadata format that entities can leverage to bootstrap the trust process.

Identity Provider Metadata

An identity provider publishes data about itself in an element:

xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

Some Non-profit Organization of New York
Some Non-profit Organization
https://www.example.org/

SAML Technical Support
mailto:[email protected]

Note the following details about this entity descriptor:

The entityID attribute is the unique identifier of the entity.
The validUntil attribute gives the expiration date of the metadata.
The element contains a digital signature that ensures the authenticity and integrity of the metadata.
The organization identified in the element is "responsible for the entity" described by the entity descriptor.
The contact information in the element identifies a technical contact responsible for the entity. Multiple contacts and contact types are possible. See section 2.3.2.2 of SAMLMeta.

By definition, an identity provider manages an SSO service that supports the SAML Web Browser SSO profile specified in SAMLProf. See, for example, the identity provider described in the element shown in the next section.

SSO service metadata

The SSO service at the identity provider is described in an element:

protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

...

Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://idp.example.org/SAML2/ArtifactResolution"/>
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://idp.example.org/SAML2/SSO/Redirect"/>
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://idp.example.org/SAML2/SSO/POST"/>
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://idp.example.org/SAML2/Artifact"/>
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
FriendlyName="eduPersonAffiliation">
member
student
faculty
employee
staff

The previous metadata element describes the SSO service at the identity provider. Note the following details about this element:

The identity provider software is configured with a private SAML signing key and/or a private back-channel TLS key. The corresponding public key is included in the element in IdP metadata. The key material has been omitted from the key descriptor for brevity.
The Binding attribute of the element indicates that the SAML SOAP binding should be used for artifact resolution.
The Location attribute of the element is used in step 8 of the "double artifact" profile.
The value of the index attribute of the element is used as the EndpointIndex in the construction of a SAML type 0x0004 artifact.
The elements indicate what SAML name identifier formats the SSO service supports.
The Binding attributes of the elements are standard URIs specified in the SAML 2.0 Binding specification.
The Location attribute of the element that supports the HTTP POST binding is used in step 2 of the "double POST" profile.
The Location attribute of the element that supports the HTTP Artifact binding is used in step 2 of the "double artifact" profile.
The element describes an attribute that the identity provider is willing to assert. The elements enumerate the possible values the attribute may take on.

As noted at the beginning of this section, the values of the Location attributes are used by a service provider to route SAML messages, which minimizes the possibility of a rogue identity provider orchestrating a man-in-the-middle attack.

Service provider metadata

Like the identity provider, a service provider publishes data about itself in an element:

xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

Some Commercial Vendor of California
Some Commercial Vendor
https://www.example.com/

SAML Technical Support
mailto:[email protected]

Note the following details about this entity descriptor:

The entityID attribute is the unique identifier of the entity.
The validUntil attribute gives the expiration date of the metadata.
The element contains a digital signature that ensures the authenticity and integrity of the metadata.
The organization identified in the element is "responsible for the entity" described by the entity descriptor.
The contact information in the element identifies a technical contact responsible for the entity. Multiple contacts and contact types are possible. See section 2.3.2.2 of SAMLMeta.

By definition, a service provider manages an assertion consumer service that supports the SAML Web Browser SSO profile specified in SAMLProf. See, for example, the service provider described in the element shown in the next section.

Assertion consumer service metadata

The assertion consumer service is contained in an element:

protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

...

...

Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://sp.example.com/SAML2/ArtifactResolution"/>
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://sp.example.com/SAML2/SSO/POST"/>
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://sp.example.com/SAML2/Artifact"/>

Service Provider Portal
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
FriendlyName="eduPersonAffiliation">

Note the following details about the metadata element:

The service provider software is configured with a private SAML signing key and/or a private back-channel TLS key. The corresponding public key is included in the element in SP metadata. The key material has been omitted from the key descriptor for brevity.
Likewise the service provider software is configured with a private SAML decryption key. A public SAML encryption key is included in the element in SP metadata. The key material has been omitted from the key descriptor for brevity.
The index attribute of an element is used as the value of the AssertionConsumerServiceIndex attribute in a element.
The Binding attributes of the elements are standard URIs specified in the SAML 2.0 Binding specification.
The Location attribute of the element that supports the HTTP POST binding is used in step 4 of the "double POST" profile.
The Location attribute of the element that supports the HTTP Artifact binding is used in step 6 of the "double artifact" profile.
The element is used by the identity provider to formulate an element that is pushed to the service provider in conjunction with Web Browser SSO.
The index attribute of the element is used as the value of the AttributeConsumingServiceIndex attribute in a element.

As noted at the beginning of this section, the values of the Location attributes are used by an identity provider to route SAML messages, which minimizes the possibility of a rogue service provider orchestrating a man-in-the-middle attack.

Metadata aggregates

In the previous examples, each element is shown to be digitally signed. In practice, however, multiple elements are grouped together under an element with a single digital signature over the entire aggregate:

xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

...

...

Note the following details about the above element:

The digital signature covers the entire aggregate.
The validUntil XML attribute has been elevated to the parent element, implying that the expiration date applies to each child element.
The XML namespace declarations have been elevated to the parent element to avoid redundant namespace declarations.

Typically metadata aggregates are published by trusted third parties called federations who vouch for the integrity of all the metadata in the aggregate. Note that metadata aggregates can be very large, composed of hundreds or even thousands of entities per aggregate.

Popular movies

The Hunger Games (film) - 2012 American dystopian action thriller science fiction-adventure film directed by Gary Ross and based on Suzanne Collins’s 2008 novel of the same name. It is the first insta...
untitled Captain Marvel sequel - part of Marvel Cinematic Universe....
Killers of the Flower Moon (film project) - Killers of the Flower Moon - film project in United States of America. It was presented as drama, detective fiction, thriller. The film project starred Leonardo Dicaprio, Robert De Niro. Director of...
Five Nights at Freddy's (film) - Five Nights at Freddy's - film published in 2017 in United States of America. Scenarist of the film - Scott Cawthon....

Popular books

Book of Revelation - The Book of Revelation is the final book of the New Testament, and consequently is also the final book of the Christian Bible. Its title is derived from the first word of the Koine Greek text: apok...
Book of Genesis - account of the creation of the world, the early history of humanity, Israel's ancestors and the origins...
Gospel of Matthew - The Gospel According to Matthew is the first book of the New Testament and one of the three synoptic gospels. It tells how Israel's Messiah, rejected and executed in Israel, pronounces judgement on ...
Michelin Guide - Michelin Guides are a series of guide books published by the French tyre company Michelin for more than a century. The term normally refers to the annually published Michelin Red Guide , the oldest...
Psalms - The Book of Psalms , commonly referred to simply as Psalms , the Psalter or "the Psalms", is the first book of the Ketuvim , the third section of the Hebrew Bible, and thus a book of th...
Ecclesiastes - Ecclesiastes is one of 24 books of the Tanakh , where it is classified as one of the Ketuvim . Originally written c. 450–200 BCE, it is also among the canonical Wisdom literature of the Old Tes...
The 48 Laws of Power - non-fiction book by American author Robert Greene. The book...

Popular television series

The Crown (TV series) - historical drama web television series about the reign of Queen Elizabeth II, created and principally written by Peter Morgan, and produced by Left Bank Pictures and Sony Pictures Tel...
Friends - American sitcom television series, created by David Crane and Marta Kauffman, which aired on NBC from September 22, 1994, to May 6, 2004, lasting ten seasons. With an ensemble cast sta...
Young Sheldon - spin-off prequel to The Big Bang Theory and begins with the character Sheldon...
Modern Family - American television mockumentary family sitcom created by Christopher Lloyd and Steven Levitan for the American Broadcasting Company. It ran for eleven seasons, from September 23...
Loki (TV series) - upcoming American web television miniseries created for Disney+ by Michael Waldron, based on the Marvel Comics character of the same name. It is set in the Marvel Cinematic Universe, shar...
Game of Thrones - American fantasy drama television series created by David Benioff and D. B. Weiss for HBO. It...
Shameless (American TV series) - American comedy-drama television series developed by John Wells which debuted on Showtime on January 9, 2011. It...