SAML 2.0
Encyclopedia
Security Assertion Markup Language 2.0 (SAML 2.0) is a version of the SAML
OASIS
standard for exchanging authentication
and authorization
data between security domains. SAML 2.0 is an XML
-based protocol that uses security tokens
containing assertions to pass information about a principal (usually an end user) between an identity provider and a web service
. SAML 2.0 enables web-based authentication and authorization scenarios including single sign-on
(SSO).
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 SAMLConform, SAMLCore, SAMLBind, and SAMLProf.
Some 30 individuals from more than two dozen companies and organizations were involved with the creation of SAML 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 2.0 specification. Thus SAML 2.0 represents the convergence of SAML 1.1
, Liberty ID-FF 1.2, and Shibboleth 1.3.
https://idp.example.org/SAML2 ) to a service provider (https://sp.example.com/SAML2 ). The assertion includes both a
Note that the
In words, the assertion encodes the following information:
The authentication statement, in particular, asserts the following:
Likewise the attribute statement asserts that
The most important of these protocols—the Authentication Request Protocol—is discussed in detail below.
Web Browser SSO Profiles are IdP-initiated, that is, an unsolicited
When a principal (or an entity acting on the principal's behalf) wishes to obtain assertions containing authentication statements, a
<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">
https://sp.example.com/SAML2
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>
The abovehttps://sp.example.com/SAML2 ) 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).
Suppose, for example, that an identity provider sends the following
<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"
Destination="https://sp.example.com/SAML2/ArtifactResolution ">
https://idp.example.org/SAML2
xmlns:ds="http://www.w3.org/2000/09/xmldsig# ">...
<samlp:Artifact>AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8=</samlp:Artifact>
</samlp:ArtifactResolve>
In response, the service provider returns the SAML element referenced by the enclosed artifact. This protocol forms the basis of the HTTP Artifact Binding.
For Web Browser SSO, the HTTP POST Binding is commonly used. Either the service provider or the identity provider (or both) use HTTP POST to transmit a protocol message. An entity's choice of binding is independent of its partner's choice of binding. For example, the service provider may use HTTP POST while the identity provider uses HTTP Artifact.
SAML requests or responses transmitted via HTTP Redirect have a
For example, encoding the
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 (formatted for readability) may be signed for additional security. In practice the
The value of the
The value of the
To automate the submission of the form, the following line of JavaScript may appear anywhere on the XHTML page:
window.onload = function { document.forms[0].submit; }
This assumes, of course, that the first form element in the page contains the above SAMLResponse containing
https://idp.example.org/SAML2/SSO/Artifact ?SAMLart=artifact
Next the identity provider sends a
<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">
xmlns:ds="http://www.w3.org/2000/09/xmldsig# ">...
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
<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 ">
https://sp.example.com/SAML2
AllowCreate="false"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
</samlp:AuthnRequest>
</samlp:ArtifactResponse>
Of course the flow can go in the other direction as well, that is, the identity provider may issue an artifact. See, for example, the "double artifact" profile example later in this topic.
SAML_artifact := B64 (TypeCode EndpointIndex RemainingArtifact)
TypeCode := Byte1Byte2
EndpointIndex := Byte1Byte2
Thus a SAML 2.0 artifact consists of three components: a two-byte
The
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 (unencoded). The
For example, consider this hex-encoded type 0x0004 artifact:
00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f
If you look closely, you can see thehttps://idp.example.org/SAML2 ) followed by 20 random bytes. The base64-encoding of these 44 bytes is what you see in the #ArtifactResolveRequest example above.
Although the number of supported profiles is quite large, the Profiles specification (#SAMLProf) is simplified since the binding aspects of each profile have been factored out into a separate Bindings specification (#SAMLBind).
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:
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
<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">
https://sp.example.com/SAML2
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>
Before the
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
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
<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 ">
https://idp.example.org/SAML2
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
<saml:Assertion
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
</saml:Assertion>
</samlp:Response>
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
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):
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.
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:
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 (SSO) Service at the IdP
The service provider redirects the user agent to the single sign-on (SSO) service at the identity provider. A
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
4. Request the Artifact Resolution Service at the SP
The SSO service dereferences the artifact by sending a
<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 ">
https://idp.example.org/SAML2
xmlns:ds="http://www.w3.org/2000/09/xmldsig# ">...
<samlp:Artifact>artifact_1</samlp:Artifact>
</samlp:ArtifactResolve>
where the value of the
5. Respond with a SAML AuthnRequest
The artifact resolution service at the service provider returns a
<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">
xmlns:ds="http://www.w3.org/2000/09/xmldsig# ">...
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
<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 ">
https://sp.example.com/SAML2
AllowCreate="false"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
</samlp:AuthnRequest>
</samlp:ArtifactResponse>
The SSO service processes the
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
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
8. Request the Artifact Resolution Service at the IdP
The assertion consumer service dereferences the artifact by sending a
<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 ">
https://sp.example.com/SAML2
xmlns:ds="http://www.w3.org/2000/09/xmldsig# ">...
<samlp:Artifact>artifact_2</samlp:Artifact>
</samlp:ArtifactResolve>
where the value of the
9. Respond with a SAML Assertion
The artifact resolution service at the identity provider returns a
<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">
xmlns:ds="http://www.w3.org/2000/09/xmldsig# ">...
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
<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 ">
https://idp.example.org/SAML2
xmlns:ds="http://www.w3.org/2000/09/xmldsig# ">...
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
<saml:Assertion
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">
user@mail.example.org
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
</saml:Assertion>
</samlp:Response>
</samlp:ArtifactResponse>
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):
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.
As a hypothetical example of a Common Domain, let's suppose NWA (nwa.com) and KLM (klm.com) belong to the virtual organization SkyTeam Global Alliance (skyteam.com). In this example, the domain skyteam.com is the common domain. Both NWA and KLM have a presence in this domain (nwa.skyteam.com and klm.skyteam.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).
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. An 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.
The SAML SOAP binding is often used in conjunction with queries.
<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>
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
CN=trscavo@uiuc.edu,OU=User,O=NCSA-TEST,C=US
</saml:Subject>
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">
</samlp:AttributeQuery>
Note that the
<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>
...
<saml:Subject>
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
CN=trscavo@uiuc.edu,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
</saml:Subject>
<saml:Conditions
NotBefore="2006-07-17T20:31:41Z"
NotOnOrAfter="2006-07-18T20:21:41Z">
</saml:Conditions>
<saml:AuthnStatement
AuthnInstant="2006-07-17T20:31:41Z">
urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
</saml:AuthnStatement>
<saml:AttributeStatement>
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">trscavo@gmail.com
</saml:AttributeStatement>
</saml:Assertion>
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 (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). Let's look at some examples of metadata at work:
The list goes on and on. Metadata bootstraps 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.
<md:EntityDescriptor
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# "
entityID="https://idp.example.org/SAML2 ">
<!-- insert ds:Signature element -->
<!-- insert md:IDPSSODescriptor element (below) -->
<!-- insert md:AttributeAuthorityDescriptor element (not shown) -->
SAML Identity Provider
SAML Identity Provider @ Some Location
http://www.idp.example.org/
SAML IdP Support
mailto:saml-support@idp.example.org
</md:EntityDescriptor>
The
The identity provider manages an SSO service and an attribute authority, each having its own descriptor. We describe SSO service metadata below while the
<md:IDPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
IdP SSO Key
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-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
</md:IDPSSODescriptor>
The previous metadata element describes the SSO service at the identity provider. Note the following details about this element:
<md:EntityDescriptor
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# "
entityID="https://sp.example.com/SAML2 ">
<!-- insert ds:Signature element -->
<!-- insert md:SPSSODescriptor element (see below) -->
SAML Service Provider
SAML Service Provider @ Some Location
http://www.sp.example.com/
SAML SP Support
mailto:saml-support@sp.example.com
</md:EntityDescriptor>
The primary component managed by the service provider is the assertion consumer service, which is discussed below.
<md:SPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
SP SSO Key
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">
</md:SPSSODescriptor>
Note the following details about the
As noted earlier, the values of the
.
SAML
Security Assertion Markup Language is an XML-based open standard for exchanging authentication and authorization data between security domains, that is, between an identity provider and a service provider...
OASIS
OASIS (organization)
The Organization for the Advancement of Structured Information Standards is a global consortium that drives the development, convergence and adoption of e-business and web service standards...
standard for exchanging authentication
Authentication
Authentication is the act of confirming the truth of an attribute of a datum or entity...
and authorization
Authorization
Authorization is the function of specifying access rights to resources, which is related to information security and computer security in general and to access control in particular. More formally, "to authorize" is to define access policy...
data between security domains. SAML 2.0 is an XML
XML
Extensible Markup Language is a set of rules for encoding documents in machine-readable form. It is defined in the XML 1.0 Specification produced by the W3C, and several other related specifications, all gratis open standards....
-based protocol that uses security tokens
Software token
A software token is a type of two-factor authentication security device that may be used to authorize the use of computer services. Software tokens are stored on a general-purpose electronic device such as a desktop computer, laptop, PDA, or mobile phone...
containing assertions to pass information about a principal (usually an end user) between an identity provider and a web service
Web service
A Web service is a method of communication between two electronic devices over the web.The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network". It has an interface described in a machine-processable format...
. SAML 2.0 enables web-based authentication and authorization scenarios including single sign-on
Single sign-on
Single sign-on is a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them...
(SSO).
SAML 2.0 was ratified as an OASIS Standard in March 2005, replacing SAML 1.1
SAML 1.1
Security Assertion Markup Language is an XML standard for exchanging authentication and authorization data between security domains. SAML is a product of the...
. The critical aspects of SAML 2.0 are covered in detail in the official documents SAMLConform, SAMLCore, SAMLBind, and SAMLProf.
Some 30 individuals from more than two dozen companies and organizations were involved with the creation of SAML 2.0. In particular, and of special note, Liberty Alliance
Liberty Alliance
The Liberty Alliance was formed in September 2001 by approximately 30 organizations to establish open standards, guidelines and best practices for identity management...
donated its Identity Federation Framework (ID-FF) specification to OASIS, which became the basis of the SAML 2.0 specification. Thus SAML 2.0 represents the convergence of SAML 1.1
SAML 1.1
Security Assertion Markup Language is an XML standard for exchanging authentication and authorization data between security domains. SAML is a product of the...
, Liberty ID-FF 1.2, and Shibboleth 1.3.
SAML 2.0 Assertions
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 (
and a
, which presumably the service provider uses to make an access control decision.Note that the
element contains the following subelements:- a
element, which contains the unique identifier of the identity provider - a
element, which contains an integrity-preserving digital signature (not shown) over the
element - a
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
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 ("b07b804c-7c29-ea16-7300-4f3d6f7928ac") was issued at time "2004-12-05T09:22:05Z" by identity provider (https://idp.example.org/SAML2 ) regarding subject (3f7b3dcf-1674-4ecd-92c8-1544f346baf8) exclusively for service provider (https://sp.example.com/SAML2 ).
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.1SAML 1.1
Security Assertion Markup Language is an XML standard for exchanging authentication and authorization data between security domains. SAML is a product of the...
Web Browser SSO Profiles are IdP-initiated, that is, an unsolicited
element is transmitted from the identity provider to the service provider (via the browser). 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 (or an entity acting on the principal's behalf) wishes to obtain assertions containing authentication statements, a
element is transmitted to the identity provider:<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">
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>
The above
element, which implicitly requests an assertion containing an authentication statement, was evidently issued by a 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 (via a back channel):<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"
Destination="
<samlp:Artifact>AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8=</samlp:Artifact>
</samlp:ArtifactResolve>
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 (SAMLBind):- SAML SOAP Binding (based on SOAP 1.1)
- Reverse SOAP (PAOS) Binding
- HTTP Redirect Binding
- HTTP POST Binding
- HTTP Artifact Binding
- SAML URI Binding
For Web Browser SSO, the HTTP POST Binding is commonly used. Either the service provider or the identity provider (or both) use HTTP POST to transmit a protocol message. An entity's choice of binding is independent of its partner's choice of binding. For example, the service provider may use HTTP POST while the identity provider uses HTTP Artifact.
HTTP Redirect Binding
SAML protocol messages are often 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 (e.g., those containing signed SAML assertions) should be 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:Mabbw95ivc5Am3TJrXPffmmLY3%2FA15Pzuyf33On8XJXBCaxTRmeEhTEJQBdmr%2FRbRp63K3pL5rPhYOpkVdY
ib%2FCon%2BC9AYfDQRB4WDvRvWWksVoY6ZQTWlbgBBZik9%2FfCR7GorYGTWFK8pu6DknnwKL%2FWEetlxmR8s
BHbHJDWZqOKGdsRJM0kfQAjCUJ43KX8s78ctnIz%2Blp5xpYa4dSo1fjOKGM03i8jSeCMzGevHa2%2FBK5MNo1F
dgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1CWJgqanfl0%2Bin8xutxYOvZL18NK
UqPlvZR5el%2BVhYkAgZQdsA6fWVsZXE63W2itrTQ2cVaKV2CjSSqL1v9P%2FAXv4C
The above message (formatted for readability) may be signed for additional security. In practice the
message is unsigned, leaving the identity provider to identify the sender via SAML metadata.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 { document.forms[0].submit; }
This assumes, of course, that the first form element in the page contains the above SAMLResponse containing
form
element (forms[0]
).HTTP Artifact Binding
The HTTP Artifact Binding uses the 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
message to an identity provider. Initially, the service provider transmits an artifact to the identity provider via an HTTP redirect:Next the identity provider sends a
request (such as the ArtifactResolveRequest shown earlier) directly to the service provider via a back channel. Finally, the service provider returns a
element containing the referenced
message:<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">
<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="
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
AssertionConsumerServiceURL="
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
</samlp:AuthnRequest>
</samlp:ArtifactResponse>
Of course the flow can go in the other direction as well, that is, the identity provider may issue an artifact. 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 (#SAMLBind):SAML_artifact := B64 (TypeCode EndpointIndex RemainingArtifact)
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 (which may be either the IdP or the SP, as mentioned earlier). 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 (unencoded). 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
(0x0004) and the EndpointIndex
(0x0000) at the front of the artifact. The next 20 bytes are the SHA-1 hash of the issuer's entityID (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 (ECP) 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 (#SAMLProf) is simplified since the binding aspects of each profile have been factored out into a separate Bindings specification (#SAMLBind).
Web Browser SSO Profile
SAML 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 SP has four bindings from which to choose while the IdP has three, which leads to twelve (12) possible deployment scenarios. We outline two such deployment scenarios below.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 (SP) and the identity provider (IdP) 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 (via an HTTP user agent) requests a target resource at the service provider:
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:<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">
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>
Before the
element is URL-encoded and inserted into the XHTML form, it is first deflated and base64-encoded (in that order).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 (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:
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:<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="
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_3"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
3f7b3dcf-1674-4ecd-92c8-1544f346baf8
Recipient="
NotOnOrAfter="2004-12-05T09:27:05Z"/>
NotOnOrAfter="2004-12-05T09:27:05Z">
SessionIndex="identifier_3">
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:Assertion>
</samlp:Response>
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 (again):
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 (SP) and the identity provider (IdP) 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 (via an HTTP user agent) requests a target resource at the service provider:
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 (SSO) Service at the IdP
The service provider redirects the user agent to the single sign-on (SSO) 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:
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:<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="
<samlp:Artifact>artifact_1</samlp:Artifact>
</samlp:ArtifactResolve>
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 (containing an
element) bound to a SAML SOAP message to the SSO service at the identity provider:<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">
<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="
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
AssertionConsumerServiceURL="
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
</samlp:AuthnRequest>
</samlp:ArtifactResponse>
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 (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
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:
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:<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="
<samlp:Artifact>artifact_2</samlp:Artifact>
</samlp:ArtifactResolve>
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 (containing an
element) bound to a SAML SOAP message to the assertion consumer service at the service provider:<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">
<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="
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_7"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
user@mail.example.org
Recipient="
NotOnOrAfter="2004-12-05T09:27:05Z"/>
NotOnOrAfter="2004-12-05T09:27:05Z">
SessionIndex="identifier_7">
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:Assertion>
</samlp:Response>
</samlp:ArtifactResponse>
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):
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 NWA (nwa.com) and KLM (klm.com) belong to the virtual organization SkyTeam Global Alliance (skyteam.com). In this example, the domain skyteam.com is the common domain. Both NWA and KLM have a presence in this domain (nwa.skyteam.com and klm.skyteam.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).
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. An 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 (ID
) - 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:<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>
CN=trscavo@uiuc.edu,OU=User,O=NCSA-TEST,C=US
</saml:Subject>
Name="urn:oid:2.5.4.42"
FriendlyName="givenName">
Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.26"
FriendlyName="mail">
</samlp:AttributeQuery>
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 (not shown):<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xs="
xmlns:xsi="
xmlns:ds="
ID="_33776a319493ad607b7ab3e689482e45"
Version="2.0"
IssueInstant="2006-07-17T20:31:41Z">
<saml:Issuer>
<saml:Subject>
CN=trscavo@uiuc.edu,OU=User,O=NCSA-TEST,C=US
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
</saml:Subject>
<saml:Conditions
NotBefore="2006-07-17T20:31:41Z"
NotOnOrAfter="2006-07-18T20:21:41Z">
</saml:Conditions>
<saml:AuthnStatement
AuthnInstant="2006-07-17T20:31:41Z">
urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
</saml:AuthnStatement>
<saml:AttributeStatement>
x500:Encoding="LDAP"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:2.5.4.42"
FriendlyName="givenName">
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:AttributeStatement>
</saml:Assertion>
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 (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). Let's look at some examples of metadata at work:
- An identity provider receives an
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 pharm private information regarding the user? Answer: Metadata! 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 know where to redirect the user with the authentication response? Answer: Metadata! The identity provider looks up a pre-arranged endpoint location of the service provider (in metadata).
- How does the service provider know that the authentication response came from a trusted identity provider? Answer: Metadata! The service provider validates 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 from a trusted identity provider? Answer: Metadata! The service provider looks up the pre-arranged endpoint location of the identity provider's artifact resolution service from metadata.
The list goes on and on. Metadata bootstraps 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:<md:EntityDescriptor
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:ds="
entityID="
<!-- insert ds:Signature element -->
<!-- insert md:IDPSSODescriptor element (below) -->
<!-- insert md:AttributeAuthorityDescriptor element (not shown) -->
SAML Identity Provider
SAML Identity Provider @ Some Location
</md:EntityDescriptor>
The
entityID
attribute is the unique identifier of the identity provider. Note that the details of the digital signature (in the
element) have been omitted from this example.The identity provider manages an SSO service and an attribute authority, each having its own descriptor. We describe SSO service metadata below while the
element is not shown.SSO Service Metadata
The SSO service at the identity provider is described in an
element:<md:IDPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
Location="
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
Location="
Location="
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
FriendlyName="eduPersonAffiliation">
</md:IDPSSODescriptor>
The previous metadata element describes the SSO service at the identity provider. Note the following details about this element:
- Key information has been omitted for brevity.
- The
Binding
attribute of the
element indicates that the SAML SOAP binding (#SAMLBind) 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 theEndpointIndex
in the construction of a SAML type 0x0004 artifact. - The
elements indicate what SAML name identifier formats (#SAMLCore) the SSO service supports. - The
Binding
attributes of the
elements are standard URIs specified in the SAML 2.0 Binding specification (#SAMLBind). - 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 (subject to policy). The
elements enumerate the possible values the attribute may take on.
Service Provider Metadata
A service provider also publishes data about itself in an
element:<md:EntityDescriptor
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:ds="
entityID="
<!-- insert ds:Signature element -->
<!-- insert md:SPSSODescriptor element (see below) -->
SAML Service Provider
SAML Service Provider @ Some Location
</md:EntityDescriptor>
The primary component managed by the service provider is the assertion consumer service, which is discussed below.
Assertion Consumer Service Metadata
The assertion consumer service is represented by an
element:<md:SPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
Location="
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
Location="
Location="
Service Provider Portal
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
FriendlyName="eduPersonAffiliation">
</md:SPSSODescriptor>
Note the following details about the
metadata element:- The
index
attribute of an
element is used as the value of theAssertionConsumerServiceIndex
attribute in a
element. - The
Binding
attributes of the
elements are standard URIs specified in the SAML 2.0 Binding specification (#SAMLBind). - The
Location
attribute of the
element that supports the HTTP POST binding (index="0"
) is used in step 4 of the "double POST" profile. - The
Location
attribute of the
element that supports the HTTP Artifact binding (index="1"
) 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 theAssertionConsumingServiceIndex
attribute in a
element.
As noted earlier, 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 attackMan-in-the-middle attack
In cryptography, the man-in-the-middle attack , bucket-brigade attack, or sometimes Janus attack, is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other...
.