SAML 1.1
Encyclopedia
Security Assertion Markup Language (SAML) is an XML
standard for exchanging authentication
and authorization
data between security domains. SAML
is a product of the ASIS (organization)] Security Services Technical Committee.
SAML 1.1 was ratified as an OASIS standard in September 2003. The critical aspects of SAML 1.1 are covered in detail in the official documents #SAMLCore and #SAMLBind. If you are new to SAML, you should probably read the introductory SAML
topic first, and then the #SAMLOverview document from OASIS.
Prior to SAML 1.1, SAML 1.0 was adopted as an OASIS standard in November 2002. SAML has undergone one minor (V1.1) and one major revision (V2.0) since V1.0, which itself is a relatively simple protocol. SAML 1.0 is of more than historical interest, however, since the US Federal E-Authentication Initiative has adopted SAML 1.0 as its core technology.
Fortunately, versions 1.0 and 1.1 of SAML are similar. See #SAMLDiff for specific differences between the two standards. This article concentrates on SAML 1.1 since it is an important standard upon which many other standards and implementations depend.
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
MajorVersion="1" MinorVersion="1"
AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa"
Issuer="https://idp.example.org/saml "
IssueInstant="2002-06-19T17:05:37.795Z">
<saml:Conditions
NotBefore="2002-06-19T17:00:37.795Z"
NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
<saml:AuthenticationStatement
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
AuthenticationInstant="2002-06-19T17:05:17.706Z">
<saml:Subject>
<saml:NameIdentifier
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
user@idp.example.org
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:bearer
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
An e-mail address (as in the above example) will suffice in a large number of situations. In some cases, however, additional information is needed before a service provider can make an access control decision. As an example, suppose that students are allowed to access scholarships data. An attribute statement can indicate whether or not the principal has an affiliation of "student", which the service provider uses to allow or deny access (resp.) to the scholarships application:
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
MajorVersion="1" MinorVersion="1"
Issuer="https://idp.example.org/saml " ...>
<saml:Conditions NotBefore="..." NotAfter="..."/>
<saml:AuthenticationStatement
AuthenticationMethod="..."
AuthenticationInstant="...">
<saml:Subject>...</saml:Subject>
</saml:AuthenticationStatement>
<saml:AttributeStatement>
<saml:Subject>...</saml:Subject>
<saml:Attribute
AttributeName="urn:mace:dir:attribute-def:eduPersonAffiliation"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<saml:AttributeValue>member</saml:AttributeValue>
<saml:AttributeValue>student</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
Attributes are often obtained from an LDAP
directory, so consistent representations of attributes across security domains is crucial.
In the above example showing how a student might obtain access to a scholarships application, the service provider is functioning as both a policy enforcement point and a policy decision point. In some situations, it may be preferable to associate the policy decision point with the identity provider. In this case, the service provider passes a URI to the identity provider who asserts an authorization decision statement that dictates whether or not the principal should be allowed access to the secured resource at the given URI.
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
MajorVersion="1" MinorVersion="1"
Issuer="https://idp.example.org/saml " ...>
<saml:Conditions .../>
<saml:AuthorizationDecisionStatement
Decision="Permit"
Resource="https://sp.example.com/confidential_report.html ">
<saml:Subject>...</saml:Subject>
<saml:Action>read</saml:Action>
</saml:AuthorizationDecisionStatement>
</saml:Assertion>
The three statement types are not mutually exclusive. For example, both authentication statements and attribute statements may be included in a single assertion (as shown above). This precludes the need to make subsequent round trips between the service provider and identity provider.
<samlp:Request
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
MajorVersion="1" MinorVersion="1"
RequestID="aaf23196-1773-2113-474a-fe114412ab72"
IssueInstant="2006-07-17T22:26:40Z">
<!-- insert other SAML elements here -->
</samlp:Request>
Similarly, a SAML responder returns a SAML
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
MajorVersion="1" MinorVersion="1"
ResponseID="b07b804c-7c29-ea16-7300-4f3d6f7928ac"
InResponseTo="aaf23196-1773-2113-474a-fe114412ab72"
IssueInstant="2006-07-17T22:26:41Z">
<!-- insert other SAML elements here, including assertions -->
</samlp:Response>
The bindings and profiles needed to affect this message exchange are detailed in the following sections.
, the SAML SOAP binding. A compatible SAML 1.1 implementation must implement SAML over SOAP over HTTP (a synchronous protocol binding). Other transport mechanisms besides HTTP are permitted, provided the protocol-independent aspects of the SAML SOAP binding are observed (see section 3.1.2 of #SAMLBind).
The SAML 1.1 SOAP binding is built on top of version 1.1 of SOAP
(the numbering is purely coincidental). A SAML requester wraps a SAML
Any SAML markup must be included in the SOAP body. SAML 1.1 does not define any SAML-specific SOAP headers. A requester is free to insert any SOAP headers it wishes (although none are required).
Recall that in SOAP 1.1, a
SOAPAction:http://www.oasis-open.org/committees/security
A SAML responder must not depend on this value, however.
A secure connection is not required for SAML requests and responses, but in those situations where message integrity and confidentiality are required, HTTP over SSL 3.0 or TLS 1.0 with a server-side certificate is required.
A SAML responder may return a "403 Forbidden" response when it refuses to respond to a SAML requester. A responder must return a "500 Internal Server Error" response in the event of a SOAP error (a SOAP fault element must be included as well). Otherwise, a "200 OK" response is returned, even in the presence of a SAML processing error. Such a response will include a SAML
The Browser/POST Profile relies on a "push" operation that passes an SSO assertion by value through the browser using HTTP POST. We say that the identity provider "pushes" the assertion to the service provider.
The Browser/Artifact Profile employs a "pull" mechanism. The profile essentially passes an SSO assertion from the identity provider to the service provider by reference (through the browser using HTTP Redirect), which is subsequently dereferenced via a back-channel exchange (i.e., the service provider "pulls" the assertion from the identity provider using SAML over SOAP over HTTP).
These profiles support cross-domain single sign-on (SSO). The specification does not define any additional profiles. In particular, SAML 1.1 does not support a profile to secure a web service message nor does it support a single logout profile.
Both SAML 1.1 profiles begin at the inter-site transfer service, which is managed by the identity provider. How the principal arrives at the transfer service in the first place is not dictated by the specification. See sections 4.1 and 4.2 of #SAMLOverview for possible scenarios. In practice, a client accessing a secured resource at a service provider will be redirected to the inter-site transfer service at the identity provider, but the precise sequence of steps needed to accomplish this is not outlined by SAML 1.1. (See section 4.3 of #SAMLOverview for some rough ideas along these lines.) This scenario is thoroughly addressed in SAML 2.0.
After visiting the inter-site transfer service, the principal is transferred to the assertion consumer service at the service provider. Exactly how the principal is transferred from the inter-site transfer service to the assertion consumer service depends on the profile used. In the case of the Browser/Artifact Profile, a redirect is used; in the case of the Browser/POST Profile, the client issues a POST request (with or without user intervention).
To expedite processing by the assertion consumer service, two separate URLs are specified:
These and other endpoint locations may be recorded in metadata files.
Note that a conforming SAML 1.1 identity provider must provide an inter-site transfer service. Similarly, a SAML 1.1 service provider must provide an assertion consumer service.
The message flow begins with a request directed at the IdP.
1. Request the Inter-site Transfer Service at the IdP
The principal (via an HTTP user agent) requests the Inter-site Transfer Service at the identity provider:
https://idp.example.org/TransferService ?TARGET=target
wherehttps://sp.example.com/home . In other words, the following GET request is issued by the user agent over SSL/TLS:
GET /TransferService?TARGET=target HTTP/1.1
Host: idp.example.org
The profile does not specify how the URL to the Transfer Service (with
2. Respond with an HTML form
The Inter-site Transfer Service returns an HTML document containing a
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: nnnn
...
...
where the
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
MajorVersion="1" MinorVersion="1"
ResponseID="_P1YaA+Q/wSM/t/8E3R8rNhcpPTM="
IssueInstant="2002-06-19T17:05:37.795Z">
xmlns:ds="http://www.w3.org/2000/09/xmldsig# ">...
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
MajorVersion="1" MinorVersion="1"
AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa"
Issuer="https://idp.example.org/saml "
IssueInstant="2002-06-19T17:05:37.795Z">
NotBefore="2002-06-19T17:00:37.795Z"
NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
AuthenticationInstant="2002-06-19T17:05:17.706Z">
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
user@idp.example.org
urn:oasis:names:tc:SAML:1.0:cm:bearer
The SAML Response must be digitally signed by the identity provider.
Important: It is assumed that the principal has already established a security context at the identity provider, otherwise the Inter-site Transfer Service would be unable to provide an authentication statement in the SAML
3. Request the Assertion Consumer Service at the SP
The user agent requests the Assertion Consumer Service at the service provider:
POST /ACS/POST HTTP/1.1
Host: sp.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: nnnn
TARGET=target&SAMLResponse=response
where the values of the
Note: To automate the submission of the form, the following line of JavaScript may appear anywhere on the page:
window.onload = function { document.forms[0].submit; }
This assumes of course that the page contains a single
4. Respond to the principal's request
The Assertion Consumer Service consumes the SAML
The message flow begins with a request directed at the IdP.
1. Request the Inter-site Transfer Service at the IdP
The principal (via an HTTP user agent) requests the Inter-site Transfer Service at the identity provider:
https://idp.example.org/TransferService ?TARGET=target
wherehttps://sp.example.com/home . In other words, the following GET request is issued by the user agent over SSL/TLS:
GET /TransferService?TARGET=target HTTP/1.1
Host: idp.example.org
The profile does not specify how the URL to the transfer service (with
2. Redirect to the Assertion Consumer Servicemm
The principal is redirected to the Assertion Consumer Service at the service provider, that is, the following response is returned to the user agent:
HTTP/1.1 302 Found
Location:https://sp.example.com/ACS/Artifact ?TARGET=target&SAMLart=artifact
where
Important: It is assumed that the principal has already established a security context at the identity provider, otherwise the Inter-site Transfer Service would be unable to provide an authentication statement.
3. Request the Assertion Consumer Service at the SP
The user agent requests the Assertion Consumer Service at the service provider:
https://sp.example.com/ACS/Artifact ?TARGET=target&SAMLart=artifact
where
GET /ACS/Artifact?TARGET=target&SAMLart=artifact HTTP/1.1
Host: sp.example.com
4. Request the Artifact Resolution Service at the IdP
The Assertion Consumer Service at the service provider begins a back-channel exchange with the Artifact Resolution Service at the identity provider. A SAML SOAP message is bound to an HTTP POST request:
POST /ArtifactResolutionService HTTP/1.1
Host: idp.example.org
Content-Type: text/xml
Content-Length: nnn
SOAPAction:http://www.oasis-open.org/committees/security
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/ ">
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
MajorVersion="1" MinorVersion="1"
RequestID="_192.168.16.51.1024506224022"
IssueInstant="2002-06-19T17:03:44.022Z">
artifact
where
5. Respond with a SAML Assertion
The identity provider completes the back-channel exchange by responding with a SAML assertion bound to a SAML SOAP message:
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: nnnn
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/ ">
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
MajorVersion="1" MinorVersion="1"
ResponseID="_P1YaA+Q/wSM/t/8E3R8rNhcpPTM="
InResponseTo="_192.168.16.51.1024506224022"
IssueInstant="2002-06-19T17:05:37.795Z">
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
MajorVersion="1" MinorVersion="1"
AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa"
Issuer="https://idp.example.org/saml "
IssueInstant="2002-06-19T17:05:37.795Z">
NotBefore="2002-06-19T17:00:37.795Z"
NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
AuthenticationInstant="2002-06-19T17:05:17.706Z">
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
user@idp.example.org
urn:oasis:names:tc:SAML:1.0:cm:artifact
In this case, the authentication statement includes a
6. Respond to the principal's request
The Assertion Consumer Service parses the SAML
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....
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
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...
is a product of the ASIS (organization)] Security Services Technical Committee.
SAML 1.1 was ratified as an OASIS standard in September 2003. The critical aspects of SAML 1.1 are covered in detail in the official documents #SAMLCore and #SAMLBind. If you are new to SAML, you should probably read the introductory SAML
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...
topic first, and then the #SAMLOverview document from OASIS.
Prior to SAML 1.1, SAML 1.0 was adopted as an OASIS standard in November 2002. SAML has undergone one minor (V1.1) and one major revision (V2.0) since V1.0, which itself is a relatively simple protocol. SAML 1.0 is of more than historical interest, however, since the US Federal E-Authentication Initiative has adopted SAML 1.0 as its core technology.
Fortunately, versions 1.0 and 1.1 of SAML are similar. See #SAMLDiff for specific differences between the two standards. This article concentrates on SAML 1.1 since it is an important standard upon which many other standards and implementations depend.
SAML 1.1 Assertions
SAML assertions contain statements that service providers use to make access control decisions. For instance, authentication statements assert to the service provider that the principal did indeed authenticate with the identity provider at a particular time using a particular method of authentication. Other information about the principal may be disclosed in an authentication statement. For example, in the authentication statement below, the e-mail address of the principal is asserted to the service provider:<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
MajorVersion="1" MinorVersion="1"
AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa"
Issuer="
IssueInstant="2002-06-19T17:05:37.795Z">
<saml:Conditions
NotBefore="2002-06-19T17:00:37.795Z"
NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
<saml:AuthenticationStatement
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
AuthenticationInstant="2002-06-19T17:05:17.706Z">
<saml:Subject>
<saml:NameIdentifier
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
user@idp.example.org
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:bearer
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
An e-mail address (as in the above example) will suffice in a large number of situations. In some cases, however, additional information is needed before a service provider can make an access control decision. As an example, suppose that students are allowed to access scholarships data. An attribute statement can indicate whether or not the principal has an affiliation of "student", which the service provider uses to allow or deny access (resp.) to the scholarships application:
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
MajorVersion="1" MinorVersion="1"
Issuer="
<saml:Conditions NotBefore="..." NotAfter="..."/>
<saml:AuthenticationStatement
AuthenticationMethod="..."
AuthenticationInstant="...">
<saml:Subject>...</saml:Subject>
</saml:AuthenticationStatement>
<saml:AttributeStatement>
<saml:Subject>...</saml:Subject>
<saml:Attribute
AttributeName="urn:mace:dir:attribute-def:eduPersonAffiliation"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<saml:AttributeValue>member</saml:AttributeValue>
<saml:AttributeValue>student</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
Attributes are often obtained from an LDAP
Lightweight Directory Access Protocol
The Lightweight Directory Access Protocol is an application protocol for accessing and maintaining distributed directory information services over an Internet Protocol network...
directory, so consistent representations of attributes across security domains is crucial.
In the above example showing how a student might obtain access to a scholarships application, the service provider is functioning as both a policy enforcement point and a policy decision point. In some situations, it may be preferable to associate the policy decision point with the identity provider. In this case, the service provider passes a URI to the identity provider who asserts an authorization decision statement that dictates whether or not the principal should be allowed access to the secured resource at the given URI.
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
MajorVersion="1" MinorVersion="1"
Issuer="
<saml:Conditions .../>
<saml:AuthorizationDecisionStatement
Decision="Permit"
Resource="
<saml:Subject>...</saml:Subject>
<saml:Action>read</saml:Action>
</saml:AuthorizationDecisionStatement>
</saml:Assertion>
The three statement types are not mutually exclusive. For example, both authentication statements and attribute statements may be included in a single assertion (as shown above). This precludes the need to make subsequent round trips between the service provider and identity provider.
SAML 1.1 Protocols
A SAML protocol is a simple request-response protocol. A SAML requester sends a SAMLRequest
element to a responder:<samlp:Request
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
MajorVersion="1" MinorVersion="1"
RequestID="aaf23196-1773-2113-474a-fe114412ab72"
IssueInstant="2006-07-17T22:26:40Z">
<!-- insert other SAML elements here -->
</samlp:Request>
Similarly, a SAML responder returns a SAML
Response
element to the requester:<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
MajorVersion="1" MinorVersion="1"
ResponseID="b07b804c-7c29-ea16-7300-4f3d6f7928ac"
InResponseTo="aaf23196-1773-2113-474a-fe114412ab72"
IssueInstant="2006-07-17T22:26:41Z">
<!-- insert other SAML elements here, including assertions -->
</samlp:Response>
The bindings and profiles needed to affect this message exchange are detailed in the following sections.
SAML 1.1 Bindings
SAML 1.1 formally defines just one protocol bindingLanguage binding
In computing, a binding from a programming language to a library or OS service is an API providing that service in the language.Many software libraries are written in systems programming languages such as C or C++...
, the SAML SOAP binding. A compatible SAML 1.1 implementation must implement SAML over SOAP over HTTP (a synchronous protocol binding). Other transport mechanisms besides HTTP are permitted, provided the protocol-independent aspects of the SAML SOAP binding are observed (see section 3.1.2 of #SAMLBind).
The SAML 1.1 SOAP binding is built on top of version 1.1 of SOAP
SOAP
SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks...
(the numbering is purely coincidental). A SAML requester wraps a SAML
Request
element within the body of a SOAP message. Similarly, a SAML responder returns a SAML Response
element within the body of a returned SOAP message. If there is an error, the responder returns a SOAP fault code instead.Any SAML markup must be included in the SOAP body. SAML 1.1 does not define any SAML-specific SOAP headers. A requester is free to insert any SOAP headers it wishes (although none are required).
Recall that in SOAP 1.1, a
SOAPAction
HTTP header must be included with each HTTP request (although its value may be empty). A SAML requester may give the following value to the SOAPAction
header:SOAPAction:
A SAML responder must not depend on this value, however.
A secure connection is not required for SAML requests and responses, but in those situations where message integrity and confidentiality are required, HTTP over SSL 3.0 or TLS 1.0 with a server-side certificate is required.
A SAML responder may return a "403 Forbidden" response when it refuses to respond to a SAML requester. A responder must return a "500 Internal Server Error" response in the event of a SOAP error (a SOAP fault element must be included as well). Otherwise, a "200 OK" response is returned, even in the presence of a SAML processing error. Such a response will include a SAML
Status
element in the SOAP body.SAML 1.1 Profiles
In general, profiles describe the use cases and message exchanges required to ultimately transfer assertions from an identity provider to a service provider. SAML 1.1 specifies two Web Browser SSO Profiles:- Browser/POST Profile
- Browser/Artifact Profile
The Browser/POST Profile relies on a "push" operation that passes an SSO assertion by value through the browser using HTTP POST. We say that the identity provider "pushes" the assertion to the service provider.
The Browser/Artifact Profile employs a "pull" mechanism. The profile essentially passes an SSO assertion from the identity provider to the service provider by reference (through the browser using HTTP Redirect), which is subsequently dereferenced via a back-channel exchange (i.e., the service provider "pulls" the assertion from the identity provider using SAML over SOAP over HTTP).
These profiles support cross-domain single sign-on (SSO). The specification does not define any additional profiles. In particular, SAML 1.1 does not support a profile to secure a web service message nor does it support a single logout profile.
Both SAML 1.1 profiles begin at the inter-site transfer service, which is managed by the identity provider. How the principal arrives at the transfer service in the first place is not dictated by the specification. See sections 4.1 and 4.2 of #SAMLOverview for possible scenarios. In practice, a client accessing a secured resource at a service provider will be redirected to the inter-site transfer service at the identity provider, but the precise sequence of steps needed to accomplish this is not outlined by SAML 1.1. (See section 4.3 of #SAMLOverview for some rough ideas along these lines.) This scenario is thoroughly addressed in SAML 2.0.
After visiting the inter-site transfer service, the principal is transferred to the assertion consumer service at the service provider. Exactly how the principal is transferred from the inter-site transfer service to the assertion consumer service depends on the profile used. In the case of the Browser/Artifact Profile, a redirect is used; in the case of the Browser/POST Profile, the client issues a POST request (with or without user intervention).
To expedite processing by the assertion consumer service, two separate URLs are specified:
- Assertion Consumer URL (Browser/POST Profile)
- Artifact Receiver URL (Browser/Artifact Profile)
These and other endpoint locations may be recorded in metadata files.
Note that a conforming SAML 1.1 identity provider must provide an inter-site transfer service. Similarly, a SAML 1.1 service provider must provide an assertion consumer service.
Browser/POST Profile
The SAML 1.1 Browser/POST profile specifies the following four (4) steps. The terminology used in the original specification has been modified slightly to conform to that of the SAML 2.0 specification.The message flow begins with a request directed at the IdP.
1. Request the Inter-site Transfer Service at the IdP
The principal (via an HTTP user agent) requests the Inter-site Transfer Service at the identity provider:
where
target
is the desired resource at the service provider, say, GET /TransferService?TARGET=target HTTP/1.1
Host: idp.example.org
The profile does not specify how the URL to the Transfer Service (with
TARGET
parameter) is obtained by the user agent.2. Respond with an HTML form
The Inter-site Transfer Service returns an HTML document containing a
FORM
element:HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: nnnn
...
...
where the
TARGET
parameter has been preserved from step 1. The value of the SAMLResponse
parameter is the base64 encoding of a SAML Response
element such as the following:MajorVersion="1" MinorVersion="1"
ResponseID="_P1YaA+Q/wSM/t/8E3R8rNhcpPTM="
IssueInstant="2002-06-19T17:05:37.795Z">
MajorVersion="1" MinorVersion="1"
AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa"
Issuer="
IssueInstant="2002-06-19T17:05:37.795Z">
NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
AuthenticationInstant="2002-06-19T17:05:17.706Z">
user@idp.example.org
urn:oasis:names:tc:SAML:1.0:cm:bearer
The SAML Response must be digitally signed by the identity provider.
Important: It is assumed that the principal has already established a security context at the identity provider, otherwise the Inter-site Transfer Service would be unable to provide an authentication statement in the SAML
Response
element.3. Request the Assertion Consumer Service at the SP
The user agent requests the Assertion Consumer Service at the service provider:
POST /ACS/POST HTTP/1.1
Host: sp.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: nnnn
TARGET=target&SAMLResponse=response
where the values of the
TARGET
and SAMLResponse
parameters are taken from the HTML form at step 2.Note: To automate the submission of the form, the following line of JavaScript may appear anywhere on the page:
window.onload = function { document.forms[0].submit; }
This assumes of course that the page contains a single
FORM
element (forms[0]
).4. Respond to the principal's request
The Assertion Consumer Service consumes the SAML
Response
element, creates a security context at the service provider and redirects the user agent to the target resource.Browser/Artifact Profile
The SAML 1.1 Browser/Artifact profile specifies the following six (6) steps. The terminology used in the original specification has been modified slightly to conform to that of the SAML 2.0 specification.The message flow begins with a request directed at the IdP.
1. Request the Inter-site Transfer Service at the IdP
The principal (via an HTTP user agent) requests the Inter-site Transfer Service at the identity provider:
where
target
is the desired resource at the service provider, say, GET /TransferService?TARGET=target HTTP/1.1
Host: idp.example.org
The profile does not specify how the URL to the transfer service (with
TARGET
parameter) is obtained by the user agent.2. Redirect to the Assertion Consumer Servicemm
The principal is redirected to the Assertion Consumer Service at the service provider, that is, the following response is returned to the user agent:
HTTP/1.1 302 Found
Location:
where
artifact
is a reference to an assertion the identity provider is willing to provide upon request.Important: It is assumed that the principal has already established a security context at the identity provider, otherwise the Inter-site Transfer Service would be unable to provide an authentication statement.
3. Request the Assertion Consumer Service at the SP
The user agent requests the Assertion Consumer Service at the service provider:
where
target
and artifact
are as before. In other words, the following GET request is issued by the user agent over SSL/TLS:GET /ACS/Artifact?TARGET=target&SAMLart=artifact HTTP/1.1
Host: sp.example.com
4. Request the Artifact Resolution Service at the IdP
The Assertion Consumer Service at the service provider begins a back-channel exchange with the Artifact Resolution Service at the identity provider. A SAML SOAP message is bound to an HTTP POST request:
POST /ArtifactResolutionService HTTP/1.1
Host: idp.example.org
Content-Type: text/xml
Content-Length: nnn
SOAPAction:
MajorVersion="1" MinorVersion="1"
RequestID="_192.168.16.51.1024506224022"
IssueInstant="2002-06-19T17:03:44.022Z">
artifact
where
artifact
was previously sent from the identity provider to the service provider in steps 2 and 3.5. Respond with a SAML Assertion
The identity provider completes the back-channel exchange by responding with a SAML assertion bound to a SAML SOAP message:
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: nnnn
MajorVersion="1" MinorVersion="1"
ResponseID="_P1YaA+Q/wSM/t/8E3R8rNhcpPTM="
InResponseTo="_192.168.16.51.1024506224022"
IssueInstant="2002-06-19T17:05:37.795Z">
MajorVersion="1" MinorVersion="1"
AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa"
Issuer="
IssueInstant="2002-06-19T17:05:37.795Z">
NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
AuthenticationInstant="2002-06-19T17:05:17.706Z">
user@idp.example.org
urn:oasis:names:tc:SAML:1.0:cm:artifact
In this case, the authentication statement includes a
NameIdentifier
containing the principal's e-mail address.6. Respond to the principal's request
The Assertion Consumer Service parses the SAML
Response
element, creates a security context at the service provider and redirects the user agent to the target resource.