You do not have permission to edit this page, for the following reasons:
This IP address has been blocked from editing Wikipedia.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

The IP address or range 3.86.0.0/16 has been blocked (disabled) by ‪ST47‬ for the following reason(s):

The IP address that you are currently using has been blocked because it is believed to be a web host provider. To prevent abuse, web hosts may be blocked from editing Wikipedia.
You will not be able to edit Wikipedia using a web host provider because it hides your IP address, much like a proxy or VPN.
We recommend that you attempt to use another connection to edit. For example, if you use a proxy or VPN to connect to the internet, turn it off when editing Wikipedia. If you edit using a mobile connection, try using a Wi-Fi connection, and vice versa. If you are using a corporate internet connection, switch to a different Wi-Fi network. If you have a Wikipedia account, please log in.
If you do not have any other way to edit Wikipedia, you will need to request an IP block exemption.

How to appeal if you are confident that your connection does not use a web host's IP address:
If you are confident that you are not using a web host, you may appeal this block by adding the following text on your talk page: ((unblock|reason=Caught by a web host block but this host or IP is not a web host. My IP address is _______. Place any further information here. ~~~~)). You must fill in the blank with your IP address for this block to be investigated. Your IP address can be determined here. Alternatively, if you wish to keep your IP address private you can use the unblock ticket request system. There are several reasons you might be editing using the IP address of a web host (such as if you are using VPN software or a business network); please use this method of appeal only if you think your IP address is in fact not a web host.

Administrators: The IP block exemption user right should only be applied to allow users to edit using web host in exceptional circumstances, and they should usually be directed to the functionaries team via email. If you intend to give the IPBE user right, a CheckUser needs to take a look at the account. This can be requested most easily at SPI Quick Checkuser Requests. Unblocking an IP or IP range with this template is highly discouraged without at least contacting the blocking administrator.

This block will expire on 01:01, 24 April 2026.

Even when blocked, you will usually still be able to edit your user talk page, as well as email administrators and other editors.

For information on how to proceed, please read the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful.

Other useful links: Blocking policy · Help:I have been blocked
Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis. The block was made by ‪Jon Kolbert‬. The reason given is Open proxy/Webhost: See the help page if you are affected .
- Start of block: 05:35, 21 February 2024
- Expiry of block: 05:35, 21 February 2029
Your current IP address is 3.86.82.155. The blocked range is 3.86.0.0/16. Please include all above details in any queries you make. If you believe you were blocked by mistake, you can find additional information and instructions in the No open proxies global policy. Otherwise, to discuss the block please post a request for review on Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.
You can view and copy the source of this page:
((Short description|Computer markup language))
((multipleissues|((Technical|date=December 2019))
((manual|date=February 2020))))
((Infobox technology standard
| title             = Security Assertion Markup Language
| status            = Published
| year_started      = November 2003
| version           = V2.0
| version_date      = March 2005
| preview           = V2.0 with Errata
| preview_date      = May 2019
| organization      = [[OASIS (organization)|Organization for the Advancement of Structured Information Standards (OASIS)]]
| committee         = OASIS Security Services (SAML) Technical Committee
| abbreviation      = SAML
| website           = [https://wiki.oasis-open.org/security/FrontPage OASIS SAML Wiki]
))
'''Security Assertion Markup Language 2.0''' ('''SAML&nbsp;2.0''') is a version of the [[Security Assertion Markup Language|SAML]] standard for exchanging [[authentication]] and [[authorization]] identities between [[security domain]]s.  SAML&nbsp;2.0 is an [[XML]]-based [[communications protocol|protocol]] that uses [[software token|security tokens]] containing [[Security Assertion Markup Language|assertions]] to pass information about a principal (usually an end user) between a SAML authority, named an [[Identity Provider]], and a SAML consumer, named a [[Service Provider]].  SAML&nbsp;2.0 enables web-based, cross-domain [[single sign-on]] (SSO), which helps reduce the administrative overhead of distributing multiple authentication tokens to the user.
SAML&nbsp;2.0 was ratified as an [[OASIS (organization)|OASIS]] Standard in March 2005, replacing [[SAML 1.1]].  The critical aspects of SAML&nbsp;2.0 are covered in detail in the official documents SAMLCore,<ref name="SAMLCore"/> SAMLBind,<ref name="SAMLBind"/> SAMLProf,<ref name="SAMLProf"/> and SAMLMeta.<ref name="SAMLMeta"/>

Some 30 individuals from more than 24 companies and organizations were involved in the creation of SAML&nbsp;2.0.  In particular, and of special note, [[Liberty Alliance]] donated its Identity Federation Framework (ID-FF) specification to OASIS, which became the basis of the SAML&nbsp;2.0 specification.  Thus SAML&nbsp;2.0 represents the convergence of [[SAML 1.1]], [http://www.projectliberty.org/resource_center/specifications/liberty_alliance_id_ff_1_2_specifications Liberty ID-FF&nbsp;1.2], and [http://shibboleth.internet2.edu/docs/internet2-mace-shibboleth-arch-protocols-200509.pdf Shibboleth&nbsp;1.3].
==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 <code><Subject></code> 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 assertion statements defined are as follows:
* Authentication Statement: The assertion subject was authenticated by a particular means at a particular time.
* Attribute Statement: The assertion subject is associated with the supplied attributes.
* Authorization Decision Statement: A request to allow the assertion subject to access the specified resource has been granted or denied.((cn|date=September 2023))

An important type of SAML assertion is the so-called <span id="BearerAssertion">"bearer" assertion</span> used to facilitate Web Browser SSO.  Here is an example of a short-lived bearer assertion issued by an identity provider (<nowiki>https://idp.example.org/SAML2</nowiki>) to a service provider (<nowiki>https://sp.example.com/SAML2</nowiki>).  The assertion includes both an Authentication Assertion <code><saml:AuthnStatement></code> and an Attribute Assertion <code><saml:AttributeStatement></code>, which presumably the service provider uses to make an access control decision. The prefix <code>saml:</code> represents the SAML V2.0 assertion namespace.

=== Example of SAML ===
<syntaxhighlight lang="xml">
<saml:Assertion
   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">
   <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
   <ds:Signature
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
   <saml:Subject>
     <saml:NameID
       Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
       3f7b3dcf-1674-4ecd-92c8-1544f346baf8
     </saml:NameID>
     <saml:SubjectConfirmation
       Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
       <saml:SubjectConfirmationData
         InResponseTo="aaf23196-1773-2113-474a-fe114412ab72"
         Recipient="https://sp.example.com/SAML2/SSO/POST"
         NotOnOrAfter="2004-12-05T09:27:05Z"/>
     </saml:SubjectConfirmation>
   </saml:Subject>
   <saml:Conditions
     NotBefore="2004-12-05T09:17:05Z"
     NotOnOrAfter="2004-12-05T09:27:05Z">
     <saml:AudienceRestriction>
       <saml:Audience>https://sp.example.com/SAML2</saml:Audience>
     </saml:AudienceRestriction>
   </saml:Conditions>
   <saml:AuthnStatement
     AuthnInstant="2004-12-05T09:22:00Z"
     SessionIndex="b07b804c-7c29-ea16-7300-4f3d6f7928ac">
     <saml:AuthnContext>
       <saml:AuthnContextClassRef>
         urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
       </saml:AuthnContextClassRef>
     </saml:AuthnContext>
   </saml:AuthnStatement>
   <saml:AttributeStatement>
     <saml:Attribute
       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">
       <saml:AttributeValue
         xsi:type="xs:string">member</saml:AttributeValue>
       <saml:AttributeValue
         xsi:type="xs:string">staff</saml:AttributeValue>
     </saml:Attribute>
   </saml:AttributeStatement>
 </saml:Assertion>
</syntaxhighlight>

Note that in the above example the <code><saml:Assertion></code> element contains the following child elements:

* a <code><saml:Issuer></code> element, which contains the unique identifier of the identity provider
* a <code><ds:Signature></code> element, which contains an integrity-preserving digital signature (not shown) over the <code><saml:Assertion></code> element
* a <code><saml:Subject></code> element, which identifies the authenticated principal (but in this case the identity of the principal is hidden behind an opaque transient identifier, for reasons of privacy)
* a <code><saml:Conditions></code> element, which gives the conditions under which the assertion is to be considered ''valid''
* a <code><saml:AuthnStatement></code> element, which describes the act of authentication at the identity provider
* a <code><saml:AttributeStatement></code> element, which asserts a multi-valued attribute associated with the authenticated principal

In words, the assertion encodes the following information:

<blockquote>The assertion ("b07b804c-7c29-ea16-7300-4f3d6f7928ac") was issued at time "2004-12-05T09:22:05Z" by identity provider (<nowiki>https://idp.example.org/SAML2</nowiki>) regarding subject (3f7b3dcf-1674-4ecd-92c8-1544f346baf8) exclusively for service provider (<nowiki>https://sp.example.com/SAML2</nowiki>).</blockquote>

The authentication statement, in particular, asserts the following:

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

Likewise the attribute statement asserts that:

<blockquote>The principal identified in the <code><saml:Subject></code> element has the 'staff' and 'member' attributes at this institution.</blockquote>

==SAML 2.0 protocols==

The following protocols are specified in SAMLCore:<ref name="SAMLCore"/>

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

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

===Authentication Request Protocol===

In [[SAML 1.1]] Web Browser SSO Profiles are initiated by the [[Identity provider|Identity Provider (IDP)]], that is, an unsolicited <code><samlp:Response></code> element is transmitted from the identity provider to the service provider (via the browser). (The prefix <code>samlp:</code> denotes the SAML protocol namespace.) 

In SAML&nbsp;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&nbsp;2.0.

When a principal (or an entity acting on the principal's behalf) wishes to obtain an assertion containing an authentication statement, a <code><samlp:AuthnRequest></code> element is transmitted to the identity provider:
<syntaxhighlight lang="xml">
  <samlp:AuthnRequest
    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">
    <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
    <samlp:NameIDPolicy
      AllowCreate="true"
      Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
  </samlp:AuthnRequest>
</syntaxhighlight>
The above <code><samlp:AuthnRequest></code> element, which implicitly requests [[#SAML_2.0_assertions|an assertion containing an authentication statement]], was evidently issued by a service provider (<nowiki>https://sp.example.com/SAML2</nowiki>) and subsequently presented to the identity provider (via the browser).  The identity provider authenticates the principal (if necessary) and issues an authentication response, which is transmitted back to the service provider (again via the browser).

===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 <code><samlp:ArtifactResolve></code> 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 <span id="ArtifactResolveRequest"><code><samlp:ArtifactResolve></code> request</span> directly to a service provider (via a back channel):
<syntaxhighlight lang="xml">
  <samlp:ArtifactResolve
 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">
    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
    <!-- an ArtifactResolve message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Artifact>AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8=</samlp:Artifact>
  </samlp:ArtifactResolve>
</syntaxhighlight>
In response, the service provider returns the SAML element referenced by the enclosed artifact.  This protocol forms the basis of the [[#HTTP Artifact Binding|HTTP Artifact Binding]].

==SAML 2.0 bindings==

The ''bindings'' supported by SAML&nbsp;2.0 are outlined in the Bindings specification (SAMLBind<ref name="SAMLBind"/>):

* SAML SOAP Binding (based on SOAP&nbsp;1.1)
* Reverse SOAP (PAOS) Binding
* [[#HTTP Redirect Binding|HTTP Redirect Binding]]
* [[#HTTP POST Binding|HTTP POST Binding]]
* [[#HTTP Artifact 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 <code><samlp:AuthnRequest></code> message. Longer messages (e.g. those containing signed or encrypted SAML assertions, such as SAML Responses) are usually transmitted via other bindings such as the [[#HTTP POST Binding|HTTP POST Binding]].

SAML requests or responses transmitted via HTTP Redirect have a <code>SAMLRequest</code> or <code>SAMLResponse</code> query string parameter, respectively. Before it's sent, the message is [[DEFLATE|deflated]] (without header and checksum), [[base64]]-encoded, and URL-encoded, in that order. Upon receipt, the process is reversed to recover the original message.

For example, encoding the <code><samlp:AuthnRequest></code> message above yields:

  <nowiki>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</nowiki>

The above message (formatted for readability) may be signed for additional security. In practice, all the data contained in a <code><samlp:AuthnRequest></code>, such as <code>Issuer</code> which contains the SP ID, and <code>NameIDPolicy</code>, has been agreed between IdP and SP beforehand (via manual information exchange or via [[#SAML 2.0 metadata|SAML metadata]]). In that case signing the request is not a security constraint. When the <code><samlp:AuthnRequest></code> 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:
<syntaxhighlight lang="html">
  <form method="post" action="https://idp.example.org/SAML2/SSO/POST" ...>
    <input type="hidden" name="SAMLRequest" value="''request''" />
    ... other input parameter....
  </form>
</syntaxhighlight>
The value of the <code>SAMLRequest</code> parameter is the base64-encoding of a <code><samlp:AuthnRequest></code> 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:
<syntaxhighlight lang="html">
  <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
    <input type="hidden" name="SAMLResponse" value="''response''" />
    ...
  </form>
</syntaxhighlight>
The value of the <code>SAMLResponse</code> parameter is the base64 encoding of a <code><samlp:Response></code> 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:
<syntaxhighlight lang="javascript">
  window.onload = function () { document.forms[0].submit(); }
</syntaxhighlight>
This assumes, of course, that the first form element in the page contains the above SAMLResponse containing <code>form</code> element (<code>forms[0]</code>).

===HTTP Artifact Binding===

The HTTP Artifact Binding uses the [[#Artifact Resolution Protocol|Artifact Resolution Protocol]] and the SAML SOAP Binding (over HTTP) to resolve a SAML message by reference.  Consider the following specific example.  Suppose a service provider wants to send a <code><samlp:AuthnRequest></code> message to an identity provider.  Initially, the service provider transmits an artifact to the identity provider via an HTTP redirect:

  <nowiki>https://idp.example.org/SAML2/SSO/Artifact</nowiki>?SAMLart=''artifact''

Next the identity provider sends a <code><samlp:ArtifactResolve></code> request (such as the [[#ArtifactResolveRequest|ArtifactResolveRequest]] shown earlier) directly to the service provider via a back channel.  Finally, the service provider returns a <code><samlp:ArtifactResponse></code> element containing the referenced <code><samlp:AuthnRequest></code> message:
<syntaxhighlight lang="xml">
  <samlp:ArtifactResponse
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="_d84a49e5958803dedcff4c984c2b0d95"
    InResponseTo="_cce4ee769ed970b501d680f697989d14"
    Version="2.0"
    IssueInstant="2004-12-05T09:21:59Z">
    <!-- an ArtifactResponse message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <samlp:AuthnRequest
      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">
      <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
      <samlp:NameIDPolicy
        AllowCreate="false"
        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
    </samlp:AuthnRequest>
  </samlp:ArtifactResponse>
</syntaxhighlight>

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 "[[#SP redirect artifact; IdP redirect artifact|double artifact]]" profile example later in this topic.

====Artifact format====

In general, a SAML&nbsp;2.0 ''artifact'' is defined as follows (SAMLBind<ref name="SAMLBind"/>):

  SAML_artifact := B64 (TypeCode EndpointIndex RemainingArtifact)
  TypeCode      := Byte1Byte2
  EndpointIndex := Byte1Byte2

Thus a SAML&nbsp;2.0 artifact consists of three components: a two-byte <code>TypeCode</code>, a two-byte <code>EndpointIndex</code>, and an arbitrary sequence of bytes called the <code>RemainingArtifact</code>.  These three pieces of information are concatenated and base64-encoded to yield the complete artifact.

The <code>TypeCode</code> uniquely identifies the artifact format.  SAML&nbsp;2.0 predefines just one such artifact, of type&nbsp;0x0004.  The <code>EndpointIndex</code> is a reference to a particular artifact resolution endpoint managed by the artifact issuer (which may be either the IdP or the SP, as mentioned earlier).  The <code>RemainingArtifact</code>, which is determined by the type definition, is the "meat" of the artifact.

The format of a ''type&nbsp;0x0004 artifact'' is further defined as follows:

  TypeCode            := 0x0004
  RemainingArtifact   := SourceId MessageHandle
  SourceId            := 20-byte_sequence
  MessageHandle       := 20-byte_sequence

Thus a type&nbsp;0x0004 artifact is of size 44&nbsp;bytes (unencoded).  The <code>SourceId</code> is an arbitrary sequence of bytes, although in practice, the <code>SourceId</code> is the SHA-1 hash of the issuer's entityID.  The <code>MessageHandle</code> 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&nbsp;0x0004 artifact:

  00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f

If you look closely, you can see the <code>TypeCode</code> (0x0004) and the <code>EndpointIndex</code> (0x0000) at the front of the artifact.  The next 20&nbsp;bytes are the SHA-1 hash of the issuer's entityID (<nowiki>https://idp.example.org/SAML2</nowiki>) followed by 20 random bytes.  The base64-encoding of these 44&nbsp;bytes is what you see in the [[#ArtifactResolveRequest|ArtifactResolveRequest]] example above.

==SAML 2.0 profiles==

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

* SSO Profiles
** [[#Web_browser_SSO_profile|Web browser SSO profile]]
** Enhanced Client or Proxy (ECP) Profile
** [[#Identity provider discovery profile|Identity Provider Discovery Profile]]
** Single Logout Profile
** Name Identifier Management Profile
* Artifact Resolution Profile
* [[#Assertion query/request 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 (SAMLProf<ref name="SAMLProf"/>) is simplified since the binding aspects of each profile have been factored out into a separate Bindings specification (SAMLBind<ref name="SAMLBind"/>).

===Web browser SSO profile===

SAML&nbsp;2.0 specifies a ''Web Browser SSO Profile'' involving an identity provider (IdP), a service provider (SP), 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.

[[File:Saml2-browser-sso-redirect-post.png|thumb|none|700px|SAML 2.0 Web Browser SSO (SP Redirect Bind/ IdP POST Response)]]

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 (via an HTTP user agent) requests a target resource at the service provider:

  <nowiki>https://sp.example.com/myresource</nowiki>

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&ndash;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 (and RelayState, if any), then redirects the browser to the IdP SSO Service using a standard [[HTTP 302]] redirect.

<syntaxhighlight lang="http">
302 Redirect
Location: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token
</syntaxhighlight>

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

<syntaxhighlight lang="xml">
  <samlp:AuthnRequest
    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">
    <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
    <samlp:NameIDPolicy
      AllowCreate="true"
      Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
  </samlp:AuthnRequest>
</syntaxhighlight>

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:

<syntaxhighlight lang="http" highlight="6">
GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token HTTP/1.1
Host: idp.example.org
</syntaxhighlight>

where the values of the <code>SAMLRequest</code> and <code>RelayState</code> parameters are the same as those provided in the redirect.  The SSO Service at the identity provider processes the <code><samlp:AuthnRequest></code> element (by URL-decoding, base64-decoding and inflating the request, in that order) and performs a security check.  If the user does not have a valid security context, the identity provider identifies the user with any mechanism (details omitted).

'''4. Respond with an XHTML form'''

The SSO Service validates the request and responds with a document containing an XHTML form:

<syntaxhighlight lang="html" highlight="2-3">
  <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
    <input type="hidden" name="SAMLResponse" value="response" />
    <input type="hidden" name="RelayState" value="token" />
    ...
    <input type="submit" value="Submit" />
  </form>
</syntaxhighlight>

The value of the <code>RelayState</code> parameter has been preserved from step&nbsp;3.  The value of the <code>SAMLResponse</code> parameter is the base64 encoding of the following <code><samlp:Response></code> element:

<syntaxhighlight lang="xml">
  <samlp:Response
    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">
    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      ID="identifier_3"
      Version="2.0"
      IssueInstant="2004-12-05T09:22:05Z">
      <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
      <!-- a POSTed assertion MUST be signed -->
      <ds:Signature
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
      <saml:Subject>
        <saml:NameID
          Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
          3f7b3dcf-1674-4ecd-92c8-1544f346baf8
        </saml:NameID>
        <saml:SubjectConfirmation
          Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
          <saml:SubjectConfirmationData
            InResponseTo="identifier_1"
            Recipient="https://sp.example.com/SAML2/SSO/POST"
            NotOnOrAfter="2004-12-05T09:27:05Z"/>
        </saml:SubjectConfirmation>
      </saml:Subject>
      <saml:Conditions
        NotBefore="2004-12-05T09:17:05Z"
        NotOnOrAfter="2004-12-05T09:27:05Z">
        <saml:AudienceRestriction>
          <saml:Audience>https://sp.example.com/SAML2</saml:Audience>
        </saml:AudienceRestriction>
      </saml:Conditions>
      <saml:AuthnStatement
        AuthnInstant="2004-12-05T09:22:00Z"
        SessionIndex="identifier_3">
        <saml:AuthnContext>
          <saml:AuthnContextClassRef>
            urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
         </saml:AuthnContextClassRef>
        </saml:AuthnContext>
      </saml:AuthnStatement>
    </saml:Assertion>
  </samlp:Response>
</syntaxhighlight>

'''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:

<syntaxhighlight lang="http" highlight="6">
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
</syntaxhighlight>

where the values of the <code>SAMLResponse</code> and <code>RelayState</code> parameters are taken from the XHTML form at step&nbsp;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 (again):

  <nowiki>https://sp.example.com/myresource</nowiki>

'''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&nbsp;2.0 Web Browser SSO Profile (SAMLProf<ref name="SAMLProf"/>) where both the service provider (SP) and the identity provider (IdP) use the HTTP POST binding.

[[File:Saml2-browser-sso-post.gif|frame|center|SAML 2.0 Web Browser SSO (POST)]]

The message flow begins with a request for a secured resource at the SP.

'''1. Request the target resource at the SP'''

The principal (via an HTTP user agent) requests a target resource at the service provider:

  <nowiki>https://sp.example.com/myresource</nowiki>

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&ndash;7.

'''2. Respond with an XHTML form'''

The service provider responds with a document containing an XHTML form:
<syntaxhighlight lang="html" highlight="2-3">
  <form method="post" action="https://idp.example.org/SAML2/SSO/POST" ...>
    <input type="hidden" name="SAMLRequest" value="request" />
    <input type="hidden" name="RelayState" value="token" />
    ...
    <input type="submit" value="Submit" />
  </form>
</syntaxhighlight>
The <code>RelayState</code> token is an opaque reference to state information maintained at the service provider.  The value of the <code>SAMLRequest</code> parameter is the base64 encoding of the following <code><samlp:AuthnRequest></code> element:
<syntaxhighlight lang="xml">
  <samlp:AuthnRequest
    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">
    <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
    <samlp:NameIDPolicy
      AllowCreate="true"
      Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
  </samlp:AuthnRequest>
</syntaxhighlight>
Before the <code><samlp:AuthnRequest></code> 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:
<syntaxhighlight lang="http" highlight="6">
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
</syntaxhighlight>
where the values of the <code>SAMLRequest</code> and <code>RelayState</code> parameters are taken from the XHTML form at step&nbsp;2.  The SSO service processes the <code><samlp:AuthnRequest></code> element (by URL-decoding, base64-decoding and inflating the request, in that order) and performs a security check.  If the user does not have a valid security context, the identity provider identifies the user (details omitted).

'''4. Respond with an XHTML form'''

The SSO service validates the request and responds with a document containing an XHTML form:
<syntaxhighlight lang="html" highlight="2-3">
  <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
    <input type="hidden" name="SAMLResponse" value="response" />
    <input type="hidden" name="RelayState" value="token" />
    ...
    <input type="submit" value="Submit" />
  </form>
</syntaxhighlight>
The value of the <code>RelayState</code> parameter has been preserved from step&nbsp;3.  The value of the <code>SAMLResponse</code> parameter is the base64 encoding of the following <code><samlp:Response></code> element:
<syntaxhighlight lang="xml">
  <samlp:Response
    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">
    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      ID="identifier_3"
      Version="2.0"
      IssueInstant="2004-12-05T09:22:05Z">
      <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
      <!-- a POSTed assertion MUST be signed -->
      <ds:Signature
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
      <saml:Subject>
        <saml:NameID
          Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
          3f7b3dcf-1674-4ecd-92c8-1544f346baf8
        </saml:NameID>
        <saml:SubjectConfirmation
          Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
          <saml:SubjectConfirmationData
            InResponseTo="identifier_1"
            Recipient="https://sp.example.com/SAML2/SSO/POST"
            NotOnOrAfter="2004-12-05T09:27:05Z"/>
        </saml:SubjectConfirmation>
      </saml:Subject>
      <saml:Conditions
        NotBefore="2004-12-05T09:17:05Z"
        NotOnOrAfter="2004-12-05T09:27:05Z">
        <saml:AudienceRestriction>
          <saml:Audience>https://sp.example.com/SAML2</saml:Audience>
        </saml:AudienceRestriction>
      </saml:Conditions>
      <saml:AuthnStatement
        AuthnInstant="2004-12-05T09:22:00Z"
        SessionIndex="identifier_3">
        <saml:AuthnContext>
          <saml:AuthnContextClassRef>
            urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
         </saml:AuthnContextClassRef>
        </saml:AuthnContext>
      </saml:AuthnStatement>
    </saml:Assertion>
  </samlp:Response>
</syntaxhighlight>
'''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:
<syntaxhighlight lang="http" highlight="6">
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
</syntaxhighlight>
where the values of the <code>SAMLResponse</code> and <code>RelayState</code> parameters are taken from the XHTML form at step&nbsp;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 (again):

  <nowiki>https://sp.example.com/myresource</nowiki>

'''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&nbsp;2.0 Web Browser SSO Profile (SAMLProf<ref name="SAMLProf"/>) where both the service provider (SP) and the identity provider (IdP) use the HTTP Artifact binding.  Both artifacts are delivered to their respective endpoints via HTTP GET.

[[File:Saml2-browser-sso-artifact.gif|frame|center|SAML 2.0 Web Browser SSO (Artifact)]]

The message flow begins with a request for a secured resource at the SP:

'''1. Request the target resource at the SP'''

The principal (via an HTTP user agent) requests a target resource at the service provider:

  <nowiki>https://sp.example.com/myresource</nowiki>

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&ndash;11.

'''2. Redirect to the Single Sign-on (SSO) Service at the IdP'''

The service provider redirects the user agent to the single sign-on (SSO) service at the identity provider.  A <code>RelayState</code> parameter and a <code>SAMLart</code> 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:

  <nowiki>https://idp.example.org/SAML2/SSO/Artifact</nowiki>?SAMLart=''artifact_1''&RelayState=''token''

where <code>''token''</code> is an opaque reference to state information maintained at the service provider and <code>''artifact_1''</code> is a SAML artifact, both issued at step&nbsp;2.

'''4. Request the Artifact Resolution Service at the SP'''

The SSO service dereferences the artifact by sending a <code><samlp:ArtifactResolve></code> element bound to a SAML SOAP message to the artifact resolution service at the service provider:
<syntaxhighlight lang="xml">
  <samlp:ArtifactResolve
    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">
    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
    <!-- an ArtifactResolve message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Artifact>''artifact_1''</samlp:Artifact>
  </samlp:ArtifactResolve>
</syntaxhighlight>
where the value of the <code><samlp:Artifact></code> 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 <code><samlp:ArtifactResponse></code> element (containing an <code><samlp:AuthnRequest></code> element) bound to a SAML SOAP message to the SSO service at the identity provider:
<syntaxhighlight lang="xml">
  <samlp:ArtifactResponse
    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">
    <!-- an ArtifactResponse message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <samlp:AuthnRequest
      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">
      <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
      <samlp:NameIDPolicy
        AllowCreate="false"
        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
    </samlp:AuthnRequest>
  </samlp:ArtifactResponse>
</syntaxhighlight>

The SSO service processes the <code><samlp:AuthnRequest></code> element and performs a security check.  If the user does not have a valid security context, the identity provider identifies the user (details omitted).

'''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 <code>RelayState</code> parameter and a new <code>SAMLart</code> 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:

  <nowiki>https://sp.example.com/SAML2/SSO/Artifact</nowiki>?SAMLart=''artifact_2''&RelayState=''token''

where <code>''token''</code> is the token value from step&nbsp;3 and <code>''artifact_2''</code> is the SAML artifact issued at step&nbsp;6.

'''8. Request the Artifact Resolution Service at the IdP'''

The assertion consumer service dereferences the artifact by sending a <code><samlp:ArtifactResolve></code> element bound to a SAML SOAP message to the artifact resolution service at the identity provider:
<syntaxhighlight lang="xml">
  <samlp:ArtifactResolve
    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">
    <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
    <!-- an ArtifactResolve message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Artifact>''artifact_2''</samlp:Artifact>
  </samlp:ArtifactResolve>
</syntaxhighlight>

where the value of the <code><samlp:Artifact></code> element is the SAML artifact transmitted at step&nbsp;7.

'''9. Respond with a SAML Assertion'''

The artifact resolution service at the identity provider returns a <code><samlp:ArtifactResponse></code> element (containing an <code><samlp:Response></code> element) bound to a SAML SOAP message to the assertion consumer service at the service provider:
<syntaxhighlight lang="xml">
  <samlp:ArtifactResponse
    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">
    <!-- an ArtifactResponse message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <samlp:Response
      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">
      <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
      <ds:Signature
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
      <samlp:Status>
        <samlp:StatusCode
          Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
      </samlp:Status>
      <saml:Assertion
        xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
        ID="identifier_7"
        Version="2.0"
        IssueInstant="2004-12-05T09:22:05Z">
        <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
        <!-- a Subject element is required -->
        <saml:Subject>
          <saml:NameID
            Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
            user@mail.example.org
          </saml:NameID>
          <saml:SubjectConfirmation
            Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <saml:SubjectConfirmationData
              InResponseTo="identifier_3"
              Recipient="https://sp.example.com/SAML2/SSO/Artifact"
              NotOnOrAfter="2004-12-05T09:27:05Z"/>
          </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions
          NotBefore="2004-12-05T09:17:05Z"
          NotOnOrAfter="2004-12-05T09:27:05Z">
          <saml:AudienceRestriction>
            <saml:Audience>https://sp.example.com/SAML2</saml:Audience>
          </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement
          AuthnInstant="2004-12-05T09:22:00Z"
          SessionIndex="identifier_7">
          <saml:AuthnContext>
            <saml:AuthnContextClassRef>
              urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
           </saml:AuthnContextClassRef>
          </saml:AuthnContext>
        </saml:AuthnStatement>
      </saml:Assertion>
    </samlp:Response>
  </samlp:ArtifactResponse>
</syntaxhighlight>

'''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 (again):

  <nowiki>https://sp.example.com/myresource</nowiki>

'''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&nbsp;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 (example.co.uk) and Example Deutschland (example.de) belong to the virtual organization Example Global Alliance (example.com).  In this example, the domain '''example.com''' is the common domain.  Both Example UK and Example Deutschland have a presence in this domain (uk.example.com and de.example.com, resp.).

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 (SAMLProf<ref name="SAMLProf"/>).

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&nbsp;2.0 elements:

* the <code><samlp:AssertionIDRequest></code> element, which is used to request an assertion given its unique identifier (<code>ID</code>)
* the <code><samlp:SubjectQuery></code> element, which is an abstract extension point that allows new subject-based SAML queries to be defined
* the <code><samlp:AuthnQuery></code> element, which is used to request '''existing''' authentication assertions about a given subject from an Authentication Authority
* the <code><samlp:AttributeQuery></code> element, which is used to request attributes about a given subject from an Attribute Authority
* the <code><samlp:AuthzDecisionQuery></code> 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:
<syntaxhighlight lang="xml">
  <samlp:AttributeQuery
    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">
    <saml:Issuer
      Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
      CN=trscavo@uiuc.edu,OU=User,O=NCSA-TEST,C=US
    </saml:Issuer>
    <saml:Subject>
      <saml:NameID
        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
        CN=trscavo@uiuc.edu,OU=User,O=NCSA-TEST,C=US
      </saml:NameID>
    </saml:Subject>
    <saml:Attribute
      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
      Name="urn:oid:2.5.4.42"
      FriendlyName="givenName">
    </saml:Attribute>
    <saml:Attribute
      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">
    </saml:Attribute>
  </samlp:AttributeQuery>
</syntaxhighlight>

Note that the <code>Issuer</code> is the <code>Subject</code> in this case.  This is sometimes called an ''attribute self-query''.  An identity provider might return the following assertion, wrapped in a <code><samlp:Response></code> element (not shown):
<syntaxhighlight lang="xml">
  <saml:Assertion
    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">
    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
    <ds:Signature>...</ds:Signature>
    <saml:Subject>
      <saml:NameID
        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
        CN=trscavo@uiuc.edu,OU=User,O=NCSA-TEST,C=US
      </saml:NameID>
      <saml:SubjectConfirmation
        Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
        <saml:SubjectConfirmationData>
          <ds:KeyInfo>
            <ds:X509Data>
              <!-- principal's X.509 cert -->
              <ds:X509Certificate>
  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==
              </ds:X509Certificate>
            </ds:X509Data>
          </ds:KeyInfo>
        </saml:SubjectConfirmationData>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <!-- assertion lifetime constrained by principal's X.509 cert -->
    <saml:Conditions
      NotBefore="2006-07-17T20:31:41Z"
      NotOnOrAfter="2006-07-18T20:21:41Z">
    </saml:Conditions>
    <saml:AuthnStatement
      AuthnInstant="2006-07-17T20:31:41Z">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>
            urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
        </saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute
        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">
        <saml:AttributeValue
          xsi:type="xs:string">Tom</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute
        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">
        <saml:AttributeValue
          xsi:type="xs:string">trscavo@gmail.com</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</syntaxhighlight>

In contrast to the [[#BearerAssertion|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 (hence the name "holder-of-key"), the relying party can be assured that the assertion is authentic.

==SAML 2.0 metadata==

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

* A service provider prepares to transmit a <code><samlp:AuthnRequest></code> 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 [[phishing|phish]] the user's password?  The service provider consults its list of trusted identity providers <strong>in metadata</strong> 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 <strong>in metadata</strong>.
* An identity provider receives a <code><samlp:AuthnRequest></code> 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 <strong>in metadata</strong> before issuing an authentication response.
* In the previous scenario, how does the identity provider encrypt the SAML assertion so that the trusted service provider (and only the trusted service provider) can decrypt the assertion. The identity provider uses the service provider's encryption certificate <strong>in metadata</strong> 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 <strong>in metadata</strong>.
* 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 <strong>from metadata</strong>.
* 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 <strong>from metadata</strong>.

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&nbsp;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 <code><md:EntityDescriptor></code> element:

<syntaxhighlight lang="xml">
  <md:EntityDescriptor entityID="https://idp.example.org/SAML2" validUntil="2013-03-22T23:00:00Z"
    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#">
    <!-- insert ds:Signature element (omitted) -->
    <!-- insert md:IDPSSODescriptor element (below) -->
    <md:Organization>
      <md:OrganizationName xml:lang="en">Some Non-profit Organization of New York</md:OrganizationName>
      <md:OrganizationDisplayName xml:lang="en">Some Non-profit Organization</md:OrganizationDisplayName>
      <md:OrganizationURL xml:lang="en">https://www.example.org/</md:OrganizationURL>
    </md:Organization>
    <md:ContactPerson contactType="technical">
      <md:SurName>SAML Technical Support</md:SurName>
      <md:EmailAddress>mailto:saml-support@example.org</md:EmailAddress>
    </md:ContactPerson>
  </md:EntityDescriptor>
</syntaxhighlight>

Note the following details about this entity descriptor:

* The <code>entityID</code> attribute is the unique identifier of the entity.
* The <code>validUntil</code> attribute gives the expiration date of the metadata.
* The <code><ds:Signature></code> element (which has been omitted for simplicity) contains a digital signature that ensures the authenticity and integrity of the metadata.
* The organization identified in the <code><md:Organization></code> element is "responsible for the entity" described by the entity descriptor (section&nbsp;2.3.2 of SAMLMeta<ref name="SAMLMeta"/>).
* The contact information in the <code><md:ContactPerson></code> element identifies a technical contact responsible for the entity. Multiple contacts and contact types are possible. See section&nbsp;2.3.2.2 of SAMLMeta.<ref name="SAMLMeta"/>

By definition, an identity provider manages an SSO service that supports the SAML Web Browser SSO profile specified in SAMLProf.<ref name="SAMLProf"/> See, for example, the identity provider described in the <code><md:IDPSSODescriptor></code> element shown in the next section.

====SSO service metadata====

The SSO service at the identity provider is described in an <code><md:IDPSSODescriptor></code> element:
<syntaxhighlight lang="xml">
  <md:IDPSSODescriptor
    protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo>...</ds:KeyInfo>
    </md:KeyDescriptor>
    <md:ArtifactResolutionService isDefault="true" index="0"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
      Location="https://idp.example.org/SAML2/ArtifactResolution"/>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
    <md:SingleSignOnService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
      Location="https://idp.example.org/SAML2/SSO/Redirect"/>
    <md:SingleSignOnService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://idp.example.org/SAML2/SSO/POST"/>
    <md:SingleSignOnService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
      Location="https://idp.example.org/SAML2/Artifact"/>
    <saml:Attribute
      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">
      <saml:AttributeValue>member</saml:AttributeValue>
      <saml:AttributeValue>student</saml:AttributeValue>
      <saml:AttributeValue>faculty</saml:AttributeValue>
      <saml:AttributeValue>employee</saml:AttributeValue>
      <saml:AttributeValue>staff</saml:AttributeValue>
    </saml:Attribute>
  </md:IDPSSODescriptor>
</syntaxhighlight>
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 <code><md:KeyDescriptor use="signing"></code> element in IdP metadata. The key material has been omitted from the key descriptor for brevity.
* The <code>Binding</code> attribute of the <code><md:ArtifactResolutionService></code> element indicates that the SAML SOAP binding (SAMLBind<ref name="SAMLBind"/>) should be used for artifact resolution.
* The <code>Location</code> attribute of the <code><md:ArtifactResolutionService></code> element is used in step&nbsp;8 of the "[[#SP redirect artifact; IdP redirect artifact|double artifact]]" profile.
* The value of the <code>index</code> attribute of the <code><md:ArtifactResolutionService></code> element is used as the <code>EndpointIndex</code> in the construction of a SAML type&nbsp;0x0004 artifact.
* The <code><md:NameIDFormat></code> elements indicate what SAML name identifier formats (SAMLCore<ref name="SAMLCore"/>) the SSO service supports.
* The <code>Binding</code> attributes of the <code><md:SingleSignOnService></code> elements are standard URIs specified in the SAML&nbsp;2.0 Binding specification (SAMLBind<ref name="SAMLBind"/>).
* The <code>Location</code> attribute of the <code><md:SingleSignOnService></code> element that supports the HTTP POST binding is used in step&nbsp;2 of the "[[#SP POST Request; IdP POST Response|double POST]]" profile.
* The <code>Location</code> attribute of the <code><md:SingleSignOnService></code> element that supports the HTTP Artifact binding is used in step&nbsp;2 of the "[[#SP redirect artifact; IdP redirect artifact|double artifact]]" profile.
* The <code><saml:Attribute></code> element describes an attribute that the identity provider is willing to assert (subject to policy).  The <code><saml:AttributeValue></code> elements enumerate the possible values the attribute may take on.

As noted at the beginning of this section, the values of the <code>Location</code> 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 <code><md:EntityDescriptor></code> element:

<syntaxhighlight lang="xml">
  <md:EntityDescriptor entityID="https://sp.example.com/SAML2" validUntil="2013-03-22T23:00:00Z"
    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#">
    <!-- insert ds:Signature element (omitted) -->
    <!-- insert md:SPSSODescriptor element (see below) -->
    <md:Organization>
      <md:OrganizationName xml:lang="en">Some Commercial Vendor of California</md:OrganizationName>
      <md:OrganizationDisplayName xml:lang="en">Some Commercial Vendor</md:OrganizationDisplayName>
      <md:OrganizationURL xml:lang="en">https://www.example.com/</md:OrganizationURL>
    </md:Organization>
    <md:ContactPerson contactType="technical">
      <md:SurName>SAML Technical Support</md:SurName>
      <md:EmailAddress>mailto:saml-support@example.com</md:EmailAddress>
    </md:ContactPerson>
  </md:EntityDescriptor>
</syntaxhighlight>

Note the following details about this entity descriptor:

* The <code>entityID</code> attribute is the unique identifier of the entity.
* The <code>validUntil</code> attribute gives the expiration date of the metadata.
* The <code><ds:Signature></code> element (which has been omitted for simplicity) contains a digital signature that ensures the authenticity and integrity of the metadata.
* The organization identified in the <code><md:Organization></code> element is "responsible for the entity" described by the entity descriptor (section&nbsp;2.3.2 of SAMLMeta<ref name="SAMLMeta"/>).
* The contact information in the <code><md:ContactPerson></code> element identifies a technical contact responsible for the entity. Multiple contacts and contact types are possible. See section&nbsp;2.3.2.2 of SAMLMeta.<ref name="SAMLMeta"/>

By definition, a service provider manages an assertion consumer service that supports the SAML Web Browser SSO profile specified in SAMLProf.<ref name="SAMLProf"/> See, for example, the service provider described in the <code><md:SPSSODescriptor></code> element shown in the next section.

====Assertion consumer service metadata====

The assertion consumer service is contained in an <code><md:SPSSODescriptor></code> element:

<syntaxhighlight lang="xml">
  <md:SPSSODescriptor
    protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo>...</ds:KeyInfo>
    </md:KeyDescriptor>
    <md:KeyDescriptor use="encryption">
      <ds:KeyInfo>...</ds:KeyInfo>
    </md:KeyDescriptor>
    <md:ArtifactResolutionService isDefault="true" index="0"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
      Location="https://sp.example.com/SAML2/ArtifactResolution"/>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
    <md:AssertionConsumerService isDefault="true" index="0"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://sp.example.com/SAML2/SSO/POST"/>
    <md:AssertionConsumerService index="1"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
      Location="https://sp.example.com/SAML2/Artifact"/>
    <md:AttributeConsumingService isDefault="true" index="1">
      <md:ServiceName xml:lang="en">Service Provider Portal</md:ServiceName>
      <md:RequestedAttribute
        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">
      </md:RequestedAttribute>
    </md:AttributeConsumingService>
  </md:SPSSODescriptor>
</syntaxhighlight>

Note the following details about the <code><md:SPSSODescriptor></code> 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 <code><md:KeyDescriptor use="signing"></code> 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 <code><md:KeyDescriptor use="encryption"></code> element in SP metadata. The key material has been omitted from the key descriptor for brevity.
* The <code>index</code> attribute of an <code><md:AssertionConsumerService></code> element is used as the value of the <code>AssertionConsumerServiceIndex</code> attribute in a <code><samlp:AuthnRequest></code> element.
* The <code>Binding</code> attributes of the <code><md:AssertionConsumerService></code> elements are standard URIs specified in the SAML&nbsp;2.0 Binding specification (SAMLBind<ref name="SAMLBind"/>).
* The <code>Location</code> attribute of the <code><md:AssertionConsumerService></code> element that supports the HTTP POST binding (<code>index="0"</code>) is used in step&nbsp;4 of the "[[#SP POST Request; IdP POST Response|double POST]]" profile.
* The <code>Location</code> attribute of the <code><md:AssertionConsumerService></code> element that supports the HTTP Artifact binding (<code>index="1"</code>) is used in step&nbsp;6 of the "[[#SP redirect artifact; IdP redirect artifact|double artifact]]" profile.
* The <code><md:AttributeConsumingService></code> element is used by the identity provider to formulate an <code><saml:AttributeStatement></code> element that is pushed to the service provider in conjunction with Web Browser SSO.
* The <code>index</code> attribute of the <code><md:AttributeConsumingService></code> element is used as the value of the <code>AttributeConsumingServiceIndex</code> attribute in a <code><samlp:AuthnRequest></code> element.

As noted at the beginning of this section, the values of the <code>Location</code> 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 <code><md:EntityDescriptor></code> element is shown to be digitally signed. In practice, however, multiple <code><md:EntityDescriptor></code> elements are grouped together under an <code><md:EntitiesDescriptor></code> element with a single digital signature over the entire aggregate:

<syntaxhighlight lang="xml">
  <md:EntitiesDescriptor validUntil="2013-03-22T23:00:00Z"
    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#">
    <!-- insert ds:Signature element (omitted) -->
    <md:EntityDescriptor entityID="https://idp.example.org/SAML2">
      ...
    </md:EntityDescriptor>
    <md:EntityDescriptor entityID="https://sp.example.com/SAML2">
      ...
    </md:EntityDescriptor>
  </md:EntitiesDescriptor>
</syntaxhighlight>

Note the following details about the above <code><md:EntitiesDescriptor></code> element:

* The digital signature (which has been omitted for brevity) covers the entire aggregate.
* The <code>validUntil</code> 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.

== Related Items ==
Folio (formally known as FOLIO, from the Latin "leaf") is a cloud-enabled open source for library management, developed by the international Folio community. Folio has been developed since 2015 by software company Index Data and funded by EBSCO Information Services.  The executable software foundation has been available since September 2016, and an initial version with functional modules was released in 2018.<ref name="bit-2016-06">((Cite web |date=2016-06-28 |title=FOLIO - eine neue Kooperation zwischen Bibliotheken, Serviceanbietern und Entwicklern |url=http://www.b-i-t-online.de/neues/3737 |accessdate=2016-07-15 |work=b.i.t.online))</ref><ref name="repositories-released">((Cite web |date=2016-09-27 |title=The Repos Are Here—FOLIO Source Code Repositories Released |url=https://www.folio.org/blog/the-repos-are-here-folio-source-code-repositories-released/ |accessdate=2016-09-28 |work=folio.org |language=en))</ref><ref name="librarysystem">((Cite web |author=Nassib Nassar |date=2016-09-01 |title=FOLIO Developer |url=http://dev.folio.org/ |accessdate=2016-10-06 |work=dev.folio.org |language=en))</ref><ref name="librarysystem-github">((Cite web |author=Nassib Nassar |date=2016-09-01 |title=FOLIO Developer |url=https://github.com/folio-org/folio-org.github.io/commit/7b95147149784a420494196015f77dc2a501512c |accessdate=2016-10-06 |work=dev.folio.org |language=en))</ref>

==See also==

* [[Security Assertion Markup Language]]
* [[SAML 1.1]]
* [[SAML metadata]]
* [[SAML-based products and services]]
* [[OpenID Connect]]

==References==

'''Primary references:'''

((reflist|refs=
<ref name="SAMLCore">S.&nbsp;Cantor et al. ''Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML)&nbsp;V2.0 – Errata Composite.'' Working Draft 07, 8 September 2015. Document ID&nbsp;sstc-saml-core-errata-2.0-wd-07 http://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf</ref>

<ref name="SAMLBind">S.&nbsp;Cantor et al. ''Bindings for the OASIS Security Assertion Markup Language (SAML)&nbsp;V2.0 – Errata Composite.'' Working Draft 06, 8 September 2015. Document ID&nbsp;sstc-saml-bindings-errata-2.0-wd-06 https://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata-2.0-wd-06.pdf</ref>

<ref name="SAMLProf">J.&nbsp;Hughes et al. ''Profiles for the OASIS Security Assertion Markup Language (SAML)&nbsp;V2.0 – Errata Composite.'' Working Draft 07, 8 September 2015. Document ID&nbsp;sstc-saml-profiles-errata-2.0-wd-07 https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf</ref>

<ref name="SAMLMeta">S.&nbsp;Cantor et al. ''Metadata for the OASIS Security Assertion Markup Language (SAML)&nbsp;V2.0 – Errata Composite.'' Working Draft 05, 8 September 2015. Document ID&nbsp;sstc-saml-metadata-errata-2.0-wd-05 https://www.oasis-open.org/committees/download.php/56785/sstc-saml-metadata-errata-2.0-wd-05.pdf</ref>
))

'''Secondary references:'''

((refbegin))
* <span name="SAMLConform">P.&nbsp;Mishra et al. ''Conformance Requirements for the OASIS Security Assertion Markup Language (SAML)&nbsp;V2.0 – Errata Composite.'' Working Draft 04, 1 December 2009. Document ID&nbsp;sstc-saml-conformance-errata-2.0-wd-04 https://www.oasis-open.org/committees/download.php/35393/sstc-saml-conformance-errata-2.0-wd-04-diff.pdf</span>

* <span name="SAMLTechOverview">N.&nbsp;Ragouzis et al., ''Security Assertion Markup Language (SAML)&nbsp;V2.0 Technical Overview.'' OASIS Committee Draft, March 2008. Document ID&nbsp;sstc-saml-tech-overview-2.0-cd-02 http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf</span>

* <span name="SAMLExecOverview">P.&nbsp;Madsen et al., ''SAML&nbsp;V2.0 Executive Overview.'' OASIS Committee Draft, April 2005. Document ID&nbsp;sstc-saml-tech-overview-2.0-cd-01-2col http://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf</span>

* <span name="SAMLAuthnCtx">J.&nbsp;Kemp et al. ''Authentication Context for the OASIS Security Assertion Markup Language (SAML)&nbsp;V2.0.'' OASIS Standard, March 2005. Document ID&nbsp;saml-authn-context-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf</span>

* <span name="SAMLSecurity">F.&nbsp;Hirsch et al. ''Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML)&nbsp;V2.0.'' OASIS Standard, March 2005. Document ID&nbsp;saml-sec-consider-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf</span>

* <span name="SAMLGlossary">J.&nbsp;Hodges et al. ''Glossary for the OASIS Security Assertion Markup Language (SAML)&nbsp;V2.0.'' OASIS Standard, March 2005. Document ID&nbsp;saml-glossary-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf</span>
((refend))

'''Deprecated references:'''

((refbegin))
* <span name="SAMLConformDeprecated">P.&nbsp;Mishra et al. ''Conformance Requirements for the OASIS Security Assertion Markup Language (SAML)&nbsp;V2.0.'' OASIS Standard, March 2005. Document ID&nbsp;saml-conformance-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf</span>

* <span name="SAMLCoreDeprecated">S.&nbsp;Cantor et al. ''Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML)&nbsp;V2.0.'' OASIS Standard, March 2005. Document ID&nbsp;saml-core-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf</span>

* <span name="SAMLBindDeprecated">S.&nbsp;Cantor et al. ''Bindings for the OASIS Security Assertion Markup Language (SAML)&nbsp;V2.0.'' OASIS Standard, March 2005. Document ID&nbsp;saml-bindings-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf</span>

* <span name="SAMLProfDeprecated">S.&nbsp;Cantor et al. ''Profiles for the OASIS Security Assertion Markup Language (SAML)&nbsp;V2.0.'' OASIS Standard, March 2005. Document ID&nbsp;saml-profiles-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf</span>

* <span name="SAMLMetaDeprecated">S.&nbsp;Cantor et al. ''Metadata for the OASIS Security Assertion Markup Language (SAML)&nbsp;V2.0.'' OASIS Standard, March 2005. Document ID&nbsp;saml-metadata-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf</span>
((refend))

((OASIS Standards))

[[Category:XML-based standards]]
[[Category:Computer access control]]
[[Category:Identity management]]
[[Category:Federated identity]]
[[Category:Identity management systems]]
[[Category:Metadata standards]]
[[Category:Computer security software]]
Pages transcluded onto the current version of this page (help):
SAML 2.0 (edit)
Template:Ambox (view source) (template editor protected)
Template:Br separated entries (view source) (template editor protected)
Template:Category handler (view source) (protected)
Template:Citation needed (view source) (protected)
Template:Cite web (view source) (protected)
Template:Cn (view source) (template editor protected)
Template:DMCA (view source) (template editor protected)
Template:Dated maintenance category (view source) (template editor protected)
Template:Dated maintenance category (articles) (view source) (template editor protected)
Template:Delink (view source) (protected)
Template:FULLROOTPAGENAME (view source) (template editor protected)
Template:Fix (view source) (protected)
Template:Fix/category (view source) (protected)
Template:Hlist/styles.css (view source) (protected)
Template:Infobox (view source) (template editor protected)
Template:Infobox technology standard (view source) (semi-protected)
Template:Main other (view source) (protected)
Template:Manual (view source) (semi-protected)
Template:Multiple issues (view source) (template editor protected)
Template:Multiple issues/styles.css (view source) (template editor protected)
Template:Multipleissues (edit)
Template:Navbox (view source) (template editor protected)
Template:Ns has subpages (view source) (protected)
Template:OASIS Standards (edit)
Template:Pagetype (view source) (protected)
Template:Refbegin (view source) (template editor protected)
Template:Refbegin/styles.css (view source) (template editor protected)
Template:Refend (view source) (template editor protected)
Template:Reflist (view source) (protected)
Template:Reflist/styles.css (view source) (protected)
Template:SDcat (view source) (protected)
Template:Short description (view source) (protected)
Template:Short description/lowercasecheck (view source) (protected)
Template:Technical (view source) (template editor protected)
Template:Template other (view source) (protected)
Module:Arguments (view source) (protected)
Module:Category handler (view source) (protected)
Module:Category handler/blacklist (view source) (protected)
Module:Category handler/config (view source) (protected)
Module:Category handler/data (view source) (protected)
Module:Category handler/shared (view source) (protected)
Module:Check for unknown parameters (view source) (protected)
Module:Citation/CS1 (view source) (protected)
Module:Citation/CS1/COinS (view source) (protected)
Module:Citation/CS1/Configuration (view source) (protected)
Module:Citation/CS1/Date validation (view source) (protected)
Module:Citation/CS1/Identifiers (view source) (protected)
Module:Citation/CS1/Utilities (view source) (protected)
Module:Citation/CS1/Whitelist (view source) (protected)
Module:Citation/CS1/styles.css (view source) (protected)
Module:Delink (view source) (protected)
Module:Disambiguation/templates (view source) (protected)
Module:Infobox (view source) (template editor protected)
Module:Infobox/styles.css (view source) (template editor protected)
Module:InfoboxImage (view source) (template editor protected)
Module:Message box (view source) (protected)
Module:Message box/ambox.css (view source) (protected)
Module:Message box/configuration (view source) (protected)
Module:Namespace detect/config (view source) (protected)
Module:Namespace detect/data (view source) (protected)
Module:Navbar (view source) (protected)
Module:Navbar/configuration (view source) (protected)
Module:Navbar/styles.css (view source) (protected)
Module:Navbox (view source) (template editor protected)
Module:Navbox/configuration (view source) (template editor protected)
Module:Navbox/styles.css (view source) (template editor protected)
Module:Ns has subpages (view source) (protected)
Module:Pagetype (view source) (protected)
Module:Pagetype/config (view source) (protected)
Module:Pagetype/disambiguation (view source) (protected)
Module:Pagetype/setindex (view source) (protected)
Module:Pagetype/softredirect (view source) (protected)
Module:SDcat (view source) (protected)
Module:Separated entries (view source) (protected)
Module:String (view source) (protected)
Module:TableTools (view source) (protected)
Module:Unsubst (view source) (protected)
Module:Wikitext Parsing (view source) (protected)
Module:Yesno (view source) (protected)
Return to SAML 2.0.
Retrieved from "https://en.wikipedia.org/wiki/SAML_2.0"