bindings for saml 2.0 - oasisdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1...

46
Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 OASIS Standard, 15 March 2005 Document identifier: saml-bindings-2.0-os Location: http://docs.oasis-open.org/security/saml/v2.0/ Editors: Scott Cantor, Internet2 Frederick Hirsch, Nokia John Kemp, Nokia Rob Philpott, RSA Security Eve Maler, Sun Microsystems SAML V2.0 Contributors: Conor P. Cahill, AOL John Hughes, Atos Origin Hal Lockhart, BEA Systems Michael Beach, Boeing Rebekah Metz, Booz Allen Hamilton Rick Randall, Booz Allen Hamilton Thomas Wisniewski, Entrust Irving Reid, Hewlett-Packard Paula Austel, IBM Maryann Hondo, IBM Michael McIntosh, IBM Tony Nadalin, IBM Nick Ragouzis, Individual Scott Cantor, Internet2 RL 'Bob' Morgan, Internet2 Peter C Davis, Neustar Jeff Hodges, Neustar Frederick Hirsch, Nokia John Kemp, Nokia Paul Madsen, NTT Steve Anderson, OpenNetwork Prateek Mishra, Principal Identity John Linn, RSA Security Rob Philpott, RSA Security Jahan Moreh, Sigaba Anne Anderson, Sun Microsystems Eve Maler, Sun Microsystems Ron Monzillo, Sun Microsystems saml-bindings-2.0-os 15 March 2005 Copyright © OASIS Open 2005. All Rights Reserved. Page 1 of 46 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

Upload: lamnga

Post on 05-Sep-2018

226 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Bindings for the OASIS SecurityAssertion Markup Language (SAML)V2.0OASIS Standard, 15 March 2005

Document identifier:saml-bindings-2.0-os

Location:http://docs.oasis-open.org/security/saml/v2.0/

Editors:Scott Cantor, Internet2Frederick Hirsch, NokiaJohn Kemp, NokiaRob Philpott, RSA SecurityEve Maler, Sun Microsystems

SAML V2.0 Contributors:Conor P. Cahill, AOLJohn Hughes, Atos OriginHal Lockhart, BEA SystemsMichael Beach, Boeing Rebekah Metz, Booz Allen HamiltonRick Randall, Booz Allen HamiltonThomas Wisniewski, EntrustIrving Reid, Hewlett-PackardPaula Austel, IBMMaryann Hondo, IBMMichael McIntosh, IBMTony Nadalin, IBMNick Ragouzis, Individual Scott Cantor, Internet2 RL 'Bob' Morgan, Internet2 Peter C Davis, NeustarJeff Hodges, NeustarFrederick Hirsch, Nokia John Kemp, NokiaPaul Madsen, NTTSteve Anderson, OpenNetworkPrateek Mishra, Principal IdentityJohn Linn, RSA SecurityRob Philpott, RSA SecurityJahan Moreh, SigabaAnne Anderson, Sun MicrosystemsEve Maler, Sun MicrosystemsRon Monzillo, Sun Microsystems

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 1 of 46

1

2

3

4

5

67

89

101112131415

1617181920212223242526272829303132333435363738394041424344

Page 2: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Greg Whitehead, Trustgenix

Abstract:This specification defines protocol bindings for the use of SAML assertions and request-responsemessages in communications protocols and frameworks.

Status:This is an OASIS Standard document produced by the Security Services Technical Committee. Itwas approved by the OASIS membership on 1 March 2005.Committee members should submit comments and potential errata to the [email protected] list. Others should submit them by filling out the web form locatedat http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=security. Thecommittee will publish on its web page (http://www.oasis-open.org/committees/security) a catalogof any changes made to this document as a result of comments.For information on whether any patents have been disclosed that may be essential toimplementing this specification, and any offers of patent licensing terms, please refer to theIntellectual Property Rights web page for the Security Services TC (http://www.oasis-open.org/committees/security/ipr.php).

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 2 of 46

45

464748

495051

5253545556

57585960

Page 3: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Table of Contents1 Introduction..................................................................................................................................................5

1.1 Protocol Binding Concepts...................................................................................................................51.2 Notation................................................................................................................................................5

2 Guidelines for Specifying Additional Protocol Bindings...............................................................................73 Protocol Bindings.........................................................................................................................................8

3.1 General Considerations.......................................................................................................................83.1.1 Use of RelayState.........................................................................................................................83.1.2 Security.........................................................................................................................................8

3.1.2.1 Use of SSL 3.0 or TLS 1.0....................................................................................................83.1.2.2 Data Origin Authentication....................................................................................................83.1.2.3 Message Integrity..................................................................................................................83.1.2.4 Message Confidentiality........................................................................................................93.1.2.5 Security Considerations........................................................................................................9

3.2 SAML SOAP Binding...........................................................................................................................93.2.1 Required Information....................................................................................................................93.2.2 Protocol-Independent Aspects of the SAML SOAP Binding...................................................... 10

3.2.2.1 Basic Operation...................................................................................................................103.2.2.2 SOAP Headers....................................................................................................................10

3.2.3 Use of SOAP over HTTP...........................................................................................................113.2.3.1 HTTP Headers....................................................................................................................113.2.3.2 Caching...............................................................................................................................113.2.3.3 Error Reporting....................................................................................................................113.2.3.4 Metadata Considerations....................................................................................................123.2.3.5 Example SAML Message Exchange Using SOAP over HTTP...........................................12

3.3 Reverse SOAP (PAOS) Binding........................................................................................................133.3.1 Required Information..................................................................................................................133.3.2 Overview.....................................................................................................................................133.3.3 Message Exchange....................................................................................................................13

3.3.3.1 HTTP Request, SAML Request in SOAP Response..........................................................143.3.3.2 SAML Response in SOAP Request, HTTP Response.......................................................15

3.3.4 Caching.......................................................................................................................................153.3.5 Security Considerations..............................................................................................................15

3.3.5.1 Error Reporting....................................................................................................................153.3.5.2 Metadata Considerations....................................................................................................15

3.4 HTTP Redirect Binding......................................................................................................................153.4.1 Required Information..................................................................................................................163.4.2 Overview.....................................................................................................................................163.4.3 RelayState..................................................................................................................................163.4.4 Message Encoding.....................................................................................................................16

3.4.4.1 DEFLATE Encoding............................................................................................................173.4.5 Message Exchange....................................................................................................................18

3.4.5.1 HTTP and Caching Considerations.....................................................................................193.4.5.2 Security Considerations......................................................................................................19

3.4.6 Error Reporting...........................................................................................................................203.4.7 Metadata Considerations............................................................................................................203.4.8 Example SAML Message Exchange Using HTTP Redirect.......................................................20

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 3 of 46

61

62

63

64

65

66

67

68697071727374

75

76777879808182838485

86

878889909192939495

96

979899

100101102103104105106107

Page 4: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

3.5 HTTP POST Binding..........................................................................................................................213.5.1 Required Information..................................................................................................................213.5.2 Overview.....................................................................................................................................213.5.3 RelayState..................................................................................................................................223.5.4 Message Encoding.....................................................................................................................223.5.5 Message Exchange....................................................................................................................22

3.5.5.1 HTTP and Caching Considerations.....................................................................................233.5.5.2 Security Considerations......................................................................................................24

3.5.6 Error Reporting...........................................................................................................................243.5.7 Metadata Considerations............................................................................................................243.5.8 Example SAML Message Exchange Using HTTP POST.......................................................... 24

3.6 HTTP Artifact Binding........................................................................................................................263.6.1 Required Information..................................................................................................................263.6.2 Overview.....................................................................................................................................273.6.3 Message Encoding.....................................................................................................................27

3.6.3.1 RelayState...........................................................................................................................273.6.3.2 URL Encoding.....................................................................................................................273.6.3.3 Form Encoding....................................................................................................................28

3.6.4 Artifact Format............................................................................................................................283.6.4.1 Required Information...........................................................................................................283.6.4.2 Format Details.....................................................................................................................29

3.6.5 Message Exchange....................................................................................................................293.6.5.1 HTTP and Caching Considerations.....................................................................................313.6.5.2 Security Considerations......................................................................................................31

3.6.6 Error Reporting...........................................................................................................................323.6.7 Metadata Considerations............................................................................................................323.6.8 Example SAML Message Exchange Using HTTP Artifact.........................................................32

3.7 SAML URI Binding.............................................................................................................................353.7.1 Required Information..................................................................................................................353.7.2 Protocol-Independent Aspects of the SAML URI Binding..........................................................35

3.7.2.1 Basic Operation...................................................................................................................353.7.3 Security Considerations..............................................................................................................363.7.4 MIME Encapsulation...................................................................................................................363.7.5 Use of HTTP URIs.....................................................................................................................36

3.7.5.1 URI Syntax..........................................................................................................................363.7.5.2 HTTP and Caching Considerations.....................................................................................363.7.5.3 Security Considerations......................................................................................................363.7.5.4 Error Reporting....................................................................................................................373.7.5.5 Metadata Considerations....................................................................................................373.7.5.6 Example SAML Message Exchange Using an HTTP URI..................................................37

4 References................................................................................................................................................38Appendix A. Registration of MIME media type application/samlassertion+xml........................................... 40Appendix B. Acknowledgments....................................................................................................................44Appendix C. Notices.....................................................................................................................................46

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 4 of 46

108

109110111112113114115116117118

119

120121122123124125126127128129130131132133134

135

136137138139140141142143144145146147

148

149

150

151

Page 5: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

1 IntroductionThis document specifies SAML protocol bindings for the use of SAML assertions and request-responsemessages in communications protocols and frameworks.

The SAML assertions and protocols specification [SAMLCore] defines the SAML assertions and request-response messages themselves, and the SAML profiles specification [SAMLProfile] defines specificusage patterns that reference both [SAMLCore] and bindings defined in this specification or elsewhere.The SAML conformance document [SAMLConform] lists all of the specifications that comprise SAMLV2.0.

1.1 Protocol Binding ConceptsMappings of SAML request-response message exchanges onto standard messaging or communicationprotocols are called SAML protocol bindings (or just bindings). An instance of mapping SAML request-response message exchanges into a specific communication protocol <FOO> is termed a <FOO> bindingfor SAML or a SAML <FOO> binding.

For example, a SAML SOAP binding describes how SAML request and response message exchangesare mapped into SOAP message exchanges.

The intent of this specification is to specify a selected set of bindings in sufficient detail to ensure thatindependently implemented SAML-conforming software can interoperate when using standard messagingor communication protocols.

Unless otherwise specified, a binding should be understood to support the transmission of any SAMLprotocol message derived from the samlp:RequestAbstractType and samlp:StatusResponseTypetypes. Further, when a binding refers to "SAML requests and responses", it should be understood to meanany protocol messages derived from those types.

For other terms and concepts that are specific to SAML, refer to the SAML glossary [SAMLGloss].

1.2 NotationThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted asdescribed in IETF RFC 2119 [RFC2119].

Listings of productions or other normative code appear like this.

Example code listings appear like this.Note: Notes like this are sometimes used to highlight non-normative commentary.

Conventional XML namespace prefixes are used throughout this specification to stand for their respectivenamespaces as follows, whether or not a namespace declaration is present in the example:

Prefix XML Namespace Comments

saml: urn:oasis:names:tc:SAML:2.0:assertion This is the SAML V2.0 assertion namespace[SAMLCore].

samlp: urn:oasis:names:tc:SAML:2.0:protocol This is the SAML V2.0 protocol namespace[SAMLCore].

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 5 of 46

152

153154

155156157158159

160

161162163164

165166

167168169

170171172173

174

175

176177178

179

180

181

182183

Page 6: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Prefix XML Namespace Comments

ds: http://www.w3.org/2000/09/xmldsig# This namespace is defined in the XML SignatureSyntax and Processing specification [XMLSig] andits governing schema.

SOAP-ENV: http://schemas.xmlsoap.org/soap/envelope This namespace is defined in SOAP V1.1[SOAP11].

This specification uses the following typographical conventions in text: <ns:Element>, XMLAttribute,Datatype, OtherKeyword. In some cases, angle brackets are used to indicate non-terminals, rather thanXML elements; the intent will be clear from the context.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 6 of 46

184185186

Page 7: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

2 Guidelines for Specifying Additional ProtocolBindings

This specification defines a selected set of protocol bindings, but others will possibly be developed in thefuture. It is not possible for the OASIS Security Services Technical Committee (SSTC) to standardize all ofthese additional bindings for two reasons: it has limited resources and it does not own the standardizationprocess for all of the technologies used. This section offers guidelines for third parties who wish to specifyadditional bindings.

The SSTC welcomes submission of proposals from OASIS members for new protocol bindings. OASISmembers may wish to submit these proposals for consideration by the SSTC in a future version of thisspecification. Other members may simply wish to inform the committee of their work related to SAML.Please refer to the SSTC web site [SSTCWeb] for further details on how to submit such proposals to theSSTC.

Following is a checklist of issues that MUST be addressed by each protocol binding:1. Specify three pieces of identifying information: a URI that uniquely identifies the protocol binding,

postal or electronic contact information for the author, and a reference to previously definedbindings or profiles that the new binding updates or obsoletes.

2. Describe the set of interactions between parties involved in the binding. Any restrictions onapplications used by each party and the protocols involved in each interaction must be explicitlycalled out.

3. Identify the parties involved in each interaction, including how many parties are involved andwhether intermediaries may be involved.

4. Specify the method of authentication of parties involved in each interaction, including whetherauthentication is required and acceptable authentication types.

5. Identify the level of support for message integrity, including the mechanisms used to ensuremessage integrity.

6. Identify the level of support for confidentiality, including whether a third party may view the contentsof SAML messages and assertions, whether the binding requires confidentiality, and themechanisms recommended for achieving confidentiality.

7. Identify the error states, including the error states at each participant, especially those that receiveand process SAML assertions or messages.

8. Identify security considerations, including analysis of threats and description of countermeasures.

9. Identify metadata considerations, such that support for a binding involving a particularcommunications protocol or used in a particular profile can be advertised in an efficient andinteroperable way.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 7 of 46

187

188

189190191192193

194195196197198

199

200201202

203204205

206207

208209

210211

212213214

215216

217

218219220

Page 8: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

3 Protocol BindingsThe following sections define the protocol bindings that are specified as part of the SAML standard.

3.1 General ConsiderationsThe following sections describe normative characteristics of all protocol bindings defined for SAML.

3.1.1 Use of RelayStateSome bindings define a "RelayState" mechanism for preserving and conveying state information. Whensuch a mechanism is used in conveying a request message as the initial step of a SAML protocol, itplaces requirements on the selection and use of the binding subsequently used to convey the response.Namely, if a SAML request message is accompanied by RelayState data, then the SAML responderMUST return its SAML protocol response using a binding that also supports a RelayState mechanism, andit MUST place the exact RelayState data it received with the request into the corresponding RelayStateparameter in the response.

3.1.2 SecurityUnless stated otherwise, these security statements apply to all bindings. Bindings may also makeadditional statements about these security features.

3.1.2.1 Use of SSL 3.0 or TLS 1.0

Unless otherwise specified, in any SAML binding's use of SSL 3.0 [SSL3] or TLS 1.0 [RFC2246], serversMUST authenticate to clients using a X.509 v3 certificate. The client MUST establish server identity basedon contents of the certificate (typically through examination of the certificate’s subject DN field,subjectAltName attribute, etc.).

3.1.2.2 Data Origin Authentication

Authentication of both the SAML requester and the SAML responder associated with a message isOPTIONAL and depends on the environment of use. Authentication mechanisms available at the SOAPmessage exchange layer or from the underlying substrate protocol (for example in many bindings theSSL/TLS or HTTP protocol) MAY be utilized to provide data origin authentication.

Transport authentication will not meet end-end origin-authentication requirements in bindings where theSAML protocol message passes through an intermediary – in this case message authentication isrecommended.

Note that SAML itself offers mechanisms for parties to authenticate to one another, but in addition SAMLmay use other authentication mechanisms to provide security for SAML itself.

3.1.2.3 Message Integrity

Message integrity of both SAML requests and SAML responses is OPTIONAL and depends on theenvironment of use. The security layer in the underlying substrate protocol or a mechanism at the SOAPmessage exchange layer MAY be used to ensure message integrity.

Transport integrity will not meet end-end integrity requirements in bindings where the SAML protocolmessage passes through an intermediary – in this case message integrity is recommended.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 8 of 46

221

222

223

224

225

226227228229230231232

233

234235

236

237238239240

241

242243244245

246247248

249250

251

252253254

255256

Page 9: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

3.1.2.4 Message Confidentiality

Message confidentiality of both SAML requests and SAML responses is OPTIONAL and depends on theenvironment of use. The security layer in the underlying substrate protocol or a mechanism at the SOAPmessage exchange layer MAY be used to ensure message confidentiality.

Transport confidentiality will not meet end-end confidentiality requirements in bindings where the SAMLprotocol message passes through an intermediary.

3.1.2.5 Security Considerations

Before deployment, each combination of authentication, message integrity, and confidentialitymechanisms SHOULD be analyzed for vulnerability in the context of the specific protocol exchange andthe deployment environment. See specific protocol processing rules in [SAMLCore] and the SAML securityconsiderations document [SAMLSecure] for a detailed discussion.

IETF RFC 2617 [RFC2617] describes possible attacks in the HTTP environment when basic or message-digest authentication schemes are used.

Special care should be given to the impact of possible caching on security.

3.2 SAML SOAP BindingSOAP is a lightweight protocol intended for exchanging structured information in a decentralized,distributed environment [SOAP11]. It uses XML technologies to define an extensible messagingframework providing a message construct that can be exchanged over a variety of underlying protocols.The framework has been designed to be independent of any particular programming model and otherimplementation specific semantics. Two major design goals for SOAP are simplicity and extensibility.SOAP attempts to meet these goals by omitting, from the messaging framework, features that are oftenfound in distributed systems. Such features include but are not limited to "reliability", "security","correlation", "routing", and "Message Exchange Patterns" (MEPs).

A SOAP message is fundamentally a one-way transmission between SOAP nodes from a SOAP senderto a SOAP receiver, possibly routed through one or more SOAP intermediaries. SOAP messages areexpected to be combined by applications to implement more complex interaction patterns ranging fromrequest/response to multiple, back-and-forth "conversational" exchanges [SOAP-PRIMER].

SOAP defines an XML message envelope that includes header and body sections, allowing data andcontrol information to be transmitted. SOAP also defines processing rules associated with this envelopeand an HTTP binding for SOAP message transmission.

The SAML SOAP binding defines how to use SOAP to send and receive SAML requests and responses.

Like SAML, SOAP can be used over multiple underlying transports. This binding has protocol-independentaspects, but also calls out the use of SOAP over HTTP as REQUIRED (mandatory to implement).

3.2.1 Required InformationIdentification: urn:oasis:names:tc:SAML:2.0:bindings:SOAP

Contact information: [email protected]

Description: Given below.

Updates: urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 9 of 46

257

258259260

261262

263

264265266267

268269

270

271

272273274275276277278279

280281282283

284285286

287

288289

290

291

292

293

294

Page 10: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

3.2.2 Protocol-Independent Aspects of the SAML SOAP BindingThe following sections define aspects of the SAML SOAP binding that are independent of the underlyingprotocol, such as HTTP, on which the SOAP messages are transported. Note this binding only supportsthe use of SOAP 1.1.

3.2.2.1 Basic Operation

SOAP 1.1 messages consist of three elements: an envelope, header data, and a message body. SAMLrequest-response protocol elements MUST be enclosed within the SOAP message body.

SOAP 1.1 also defines an optional data encoding system. This system is not used within the SAML SOAPbinding. This means that SAML messages can be transported using SOAP without re-encoding from the"standard" SAML schema to one based on the SOAP encoding.

The system model used for SAML conversations over SOAP is a simple request-response model.1. A system entity acting as a SAML requester transmits a SAML request element within the body of

a SOAP message to a system entity acting as a SAML responder. The SAML requester MUSTNOT include more than one SAML request per SOAP message or include any additional XMLelements in the SOAP body.

2. The SAML responder MUST return either a SAML response element within the body of anotherSOAP message or generate a SOAP fault. The SAML responder MUST NOT include more thanone SAML response per SOAP message or include any additional XML elements in the SOAPbody. If a SAML responder cannot, for some reason, process a SAML request, it MUST generate aSOAP fault. SOAP fault codes MUST NOT be sent for errors within the SAML problem domain, forexample, inability to find an extension schema or as a signal that the subject is not authorized toaccess a resource in an authorization query. (SOAP 1.1 faults and fault codes are discussed in[SOAP11] Section 4.1.)

On receiving a SAML response in a SOAP message, the SAML requester MUST NOT send a fault codeor other error messages to the SAML responder. Since the format for the message interchange is asimple request-response pattern, adding additional items such as error conditions would needlesslycomplicate the protocol.

[SOAP11] references an early draft of the XML Schema specification including an obsolete namespace.SAML requesters SHOULD generate SOAP documents referencing only the final XML schemanamespace. SAML responders MUST be able to process both the XML schema namespace used in[SOAP11] as well as the final XML schema namespace.

3.2.2.2 SOAP Headers

A SAML requester in a SAML conversation over SOAP MAY add arbitrary headers to the SOAP message.This binding does not define any additional SOAP headers.

Note: The reason other headers need to be allowed is that some SOAP software andlibraries might add headers to a SOAP message that are out of the control of the SAML-aware process. Also, some headers might be needed for underlying protocols that requirerouting of messages or by message security mechanisms.

A SAML responder MUST NOT require any headers in the SOAP message in order to process the SAMLmessage correctly itself, but MAY require additional headers that address underlying routing or messagesecurity requirements.

Note: The rationale is that requiring extra headers will cause fragmentation of the SAMLstandard and will hurt interoperability.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 10 of 46

295

296297298

299

300301

302303304

305

306307308309

310311312313314315316317

318319320321

322323324325

326

327328

329330331332

333334335

336337

Page 11: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

3.2.3 Use of SOAP over HTTPA SAML processor that claims conformance to the SAML SOAP binding MUST implement SAML overSOAP over HTTP. This section describes certain specifics of using SOAP over HTTP, including HTTPheaders, caching, and error reporting.

The HTTP binding for SOAP is described in [SOAP11] Section 6.0. It requires the use of a SOAPActionheader as part of a SOAP HTTP request. A SAML responder MUST NOT depend on the value of thisheader. A SAML requester MAY set the value of the SOAPAction header as follows:

http://www.oasis-open.org/committees/security

3.2.3.1 HTTP Headers

A SAML requester in a SAML conversation over SOAP over HTTP MAY add arbitrary headers to theHTTP request. This binding does not define any additional HTTP headers.

Note: The reason other headers need to be allowed is that some HTTP software andlibraries might add headers to an HTTP message that are out of the control of the SAML-aware process. Also, some headers might be needed for underlying protocols that requirerouting of messages or by message security mechanisms.

A SAML responder MUST NOT require any headers in the HTTP request to correctly process the SAMLmessage itself, but MAY require additional headers that address underlying routing or message securityrequirements.

Note: The rationale is that requiring extra headers will cause fragmentation of the SAMLstandard and will hurt interoperability.

3.2.3.2 Caching

HTTP proxies should not cache SAML protocol messages. To ensure this, the following rules SHOULD befollowed.

When using HTTP 1.1 [RFC2616], requesters SHOULD:• Include a Cache-Control header field set to "no-cache, no-store".

• Include a Pragma header field set to "no-cache".

When using HTTP 1.1, responders SHOULD:• Include a Cache-Control header field set to "no-cache, no-store, must-revalidate,private".

• Include a Pragma header field set to "no-cache".

• NOT include a Validator, such as a Last-Modified or ETag header.

3.2.3.3 Error Reporting

A SAML responder that refuses to perform a message exchange with the SAML requester SHOULDreturn a "403 Forbidden" response. In this case, the content of the HTTP body is not significant.

As described in [SOAP11] Section 6.2, in the case of a SOAP error while processing a SOAP request, theSOAP HTTP server MUST return a "500 Internal Server Error" response and include a SOAPmessage in the response with a SOAP <SOAP-ENV:fault> element. This type of error SHOULD bereturned for SOAP-related errors detected before control is passed to the SAML processor, or when theSOAP processor reports an internal error (for example, the SOAP XML namespace is incorrect, the SAMLschema cannot be located, the SAML processor throws an exception, and so on).

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 11 of 46

338

339340341

342343344

345

346

347348

349350351352

353354355

356357

358

359360

361

362

363

364

365366

367

368

369

370371

372373374375376377

Page 12: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

In the case of a SAML processing error, the SOAP HTTP server MUST respond with "200 OK" andinclude a SAML-specified <samlp:Status> element in the SAML response within the SOAP body. Notethat the <samlp:Status> element does not appear by itself in the SOAP body, but only within a SAMLresponse of some sort.

For more information about the use of SAML status codes, see the SAML assertions and protocolsspecification [SAMLCore].

3.2.3.4 Metadata Considerations

Support for the SOAP binding SHOULD be reflected by indicating either a URL endpoint at which requestscontained in SOAP messages for a particular protocol or profile are to be sent, or alternatively with aWSDL port/endpoint definition.

3.2.3.5 Example SAML Message Exchange Using SOAP over HTTP

Following is an example of a query that asks for an assertion containing an attribute statement from aSAML attribute authority.

POST /SamlService HTTP/1.1Host: www.example.comContent-Type: text/xmlContent-Length: nnnSOAPAction: http://www.oasis-open.org/committees/security<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”> <SOAP-ENV:Body> <samlp:AttributeQuery xmlns:samlp:=”…” xmlns:saml=”…” xmlns:ds=”…” ID=”_6c3a4f8b9c2d” Version=”2.0”IssueInstant=”2004-03-27T08:41:00Z” <ds:Signature> … </ds:Signature> <saml:Subject> … </saml:Subject> </samlp:AttributeQuery> </SOAP-ENV:Body></SOAP-ENV:Envelope>

Following is an example of the corresponding response, which supplies an assertion containing theattribute statement as requested.

HTTP/1.1 200 OKContent-Type: text/xmlContent-Length: nnnn<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”> <SOAP-ENV:Body> <samlp:Response xmlns:samlp=”…” xmlns:saml=”…” xmlns:ds=”…”ID=”_6c3a4f8b9c2d” Version=”2.0” IssueInstant=”2004-03-27T08:42:00Z”> <saml:Issuer>https://www.example.com/SAML</saml:Issuer>

<ds:Signature> … </ds:Signature> <Status> <StatusCode Value=”…”/> </Status> <saml:Assertion> <saml:Subject> … </saml:Subject> <saml:AttributeStatement> … </saml:AttributeStatement> </saml:Assertion> </samlp:Response> </SOAP-Env:Body>

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 12 of 46

378379380381

382383

384

385386387

388

389390

391392393394395396397398399400401402403404405406407408

409410411412413414415416417418419420421422423424425426427428429430431432433434

Page 13: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

</SOAP-ENV:Envelope>

3.3 Reverse SOAP (PAOS) BindingThis binding leverages the Reverse HTTP Binding for SOAP specification [PAOS]. Implementers MUSTcomply with the general processing rules specified in [PAOS] in addition to those specified in thisdocument. In case of conflict, [PAOS] is normative.

3.3.1 Required InformationIdentification: urn:oasis:names:tc:SAML:2.0:bindings:PAOS

Contact information: [email protected]

Description: Given below.

Updates: None.

3.3.2 OverviewThe reverse SOAP binding is a mechanism by which an HTTP requester can advertise the ability to act asa SOAP responder or a SOAP intermediary to a SAML requester. The HTTP requester is able to supporta pattern where a SAML request is sent to it in a SOAP envelope in an HTTP response from the SAMLrequester, and the HTTP requester responds with a SAML response in a SOAP envelope in a subsequentHTTP request. This message exchange pattern supports the use case defined in the ECP SSO profile(described in the SAML profiles specification [SAMLProfile]), in which the HTTP requester is anintermediary in an authentication exchange.

3.3.3 Message ExchangeThe PAOS binding includes two component message exchange patterns:

1. The HTTP requester sends an HTTP request to a SAML requester. The SAML requester respondswith an HTTP response containing a SOAP envelope containing a SAML request message.

2. Subsequently, the HTTP requester sends an HTTP request to the original SAML requestercontaining a SOAP envelope containing a SAML response message. The SAML requesterresponds with an HTTP response, possibly in response to the original service request in step 1.

The ECP profile uses the PAOS binding to provide authentication of the client to the service providerbefore the service is provided. This occurs in the following steps, illustrated in Figure A:

1. The client requests a service using an HTTP request.

2. The service provider responds with a SAML authentication request. This is sent using a SOAPrequest, carried in the HTTP response.

3. The client returns a SOAP response carrying a SAML authentication response. This is sent using anew HTTP request.

4. Assuming the service provider authentication and authorization is successful, the service providermay respond to the original service request in the HTTP response.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 13 of 46

435

436

437438439

440

441

442

443

444

445

446447448449450451452

453

454

455456

457458459

460461

462

463464

465466

467468

Page 14: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Figure 1: PAOS Binding Message Exchanges

The HTTP requester advertises the ability to handle this reverse SOAP binding in its HTTP requests usingthe HTTP headers defined by the PAOS specification. Specifically:

• The HTTP Accept Header field MUST indicate an ability to accept the“application/vnd.paos+xml” content type.

• The HTTP PAOS Header field MUST be present and specify the PAOS version with"urn:liberty:paos:2003-08" at a minimum.

Additional PAOS headers such as the service value MAY be specified by profiles that use the PAOSbinding. The HTTP requester MAY add arbitrary headers to the HTTP request.

Note that this binding does not define a RelayState mechanism. Specific profiles that make use of thisbinding must therefore define such a mechanism, if needed. The use of a SOAP header is suggested forthis purpose.

The following sections provide more detail on the two steps of the message exchange.

3.3.3.1 HTTP Request, SAML Request in SOAP Response

In response to an arbitrary HTTP request, the HTTP responder MAY return a SAML request messageusing this binding by returning a SOAP 1.1 envelope in the HTTP response containing a single SAMLrequest message in the SOAP body, with no additional body content. The SOAP envelope MAY containarbitrary SOAP headers defined by PAOS, SAML profiles, or additional specifications.

Note that while the SAML request message is delivered to the HTTP requester, the actual intended

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 14 of 46

Service Provider

HTTP Request (Service A request)

HTTP Response

SOAP Envelope containing SAML Request (e.g. authentication request)

...

HTTP Request

HTTP Response (Service A response)

SOAP Envelope containing SAML Response (e.g. authentication response)

Service Provider

Service Provider

Service ProviderClient

Client

Client

Client

469470

471472

473474

475476

477478479

480

481

482483484485

486

Page 15: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

recipient MAY be another system entity, with the HTTP requester acting as an intermediary, as defined byspecific profiles.

3.3.3.2 SAML Response in SOAP Request, HTTP Response

When the HTTP requester delivers a SAML response message to the intended recipient using the PAOSbinding, it places it as the only element in the SOAP body in a SOAP envelope in an HTTP request. TheHTTP requester may or may not be the originator of the SAML response. The SOAP envelope MAYcontain arbitrary SOAP headers defined by PAOS, SAML profiles, or additional specifications. The SAMLexchange is considered complete and the HTTP response is unspecified by this binding.

Profiles MAY define additional constraints on the HTTP content of non-SOAP responses during theexchanges covered by this binding.

3.3.4 CachingHTTP proxies should not cache SAML protocol messages. To ensure this, the following rules SHOULD befollowed.

When using HTTP 1.1, requesters sending SAML protocol messages SHOULD:• Include a Cache-Control header field set to "no-cache, no-store".

• Include a Pragma header field set to "no-cache".

When using HTTP 1.1, responders returning SAML protocol messages SHOULD:• Include a Cache-Control header field set to "no-cache, no-store, must-revalidate,private".

• Include a Pragma header field set to "no-cache".

• NOT include a Validator, such as a Last-Modified or ETag header.

3.3.5 Security ConsiderationsThe HTTP requester in the PAOS binding may act as a SOAP intermediary and when it does, transportlayer security for origin authentication, integrity and confidentiality may not meet end-end securityrequirements. In this case security at the SOAP message layer is recommended.

3.3.5.1 Error Reporting

Standard HTTP and SOAP error conventions MUST be observed. Errors that occur during SAMLprocessing MUST NOT be signaled at the HTTP or SOAP layer and MUST be handled using SAMLresponse messages with an error <samlp:Status> element.

3.3.5.2 Metadata Considerations

Support for the PAOS binding SHOULD be reflected by indicating a URL endpoint at which HTTPrequests and/or SAML protocol messages contained in SOAP envelopes for a particular protocol or profileare to be sent. Either a single endpoint or distinct request and response endpoints MAY be supplied.

3.4 HTTP Redirect BindingThe HTTP Redirect binding defines a mechanism by which SAML protocol messages can be transmittedwithin URL parameters. Permissible URL length is theoretically infinite, but unpredictably limited inpractice. Therefore, specialized encodings are needed to carry XML messages on a URL, and larger or

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 15 of 46

487488

489

490491492493494

495496

497

498499

500

501

502

503

504505

506

507

508

509510511

512

513514515

516

517518519

520

521522523

Page 16: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

more complex message content can be sent using the HTTP POST or Artifact bindings.

This binding MAY be composed with the HTTP POST binding (see Section 3.5) and the HTTP Artifactbinding (see Section 3.6) to transmit request and response messages in a single protocol exchange usingtwo different bindings.

This binding involves the use of a message encoding. While the definition of this binding includes thedefinition of one particular message encoding, others MAY be defined and used.

3.4.1 Required InformationIdentification: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect

Contact information: [email protected]

Description: Given below.

Updates: None.

3.4.2 OverviewThe HTTP Redirect binding is intended for cases in which the SAML requester and responder need tocommunicate using an HTTP user agent (as defined in HTTP 1.1 [RFC2616]) as an intermediary. Thismay be necessary, for example, if the communicating parties do not share a direct path of communication.It may also be needed if the responder requires an interaction with the user agent in order to fulfill therequest, such as when the user agent must authenticate to it.

Note that some HTTP user agents may have the capacity to play a more active role in the protocolexchange and may support other bindings that use HTTP, such as the SOAP and Reverse SOAPbindings. This binding assumes nothing apart from the capabilities of a common web browser.

3.4.3 RelayStateRelayState data MAY be included with a SAML protocol message transmitted with this binding. The valueMUST NOT exceed 80 bytes in length and SHOULD be integrity protected by the entity creating themessage independent of any other protections that may or may not exist during message transmission.Signing is not realistic given the space limitation, but because the value is exposed to third-partytampering, the entity SHOULD ensure that the value has not been tampered with by using a checksum, apseudo-random value, or similar means.

If a SAML request message is accompanied by RelayState data, then the SAML responder MUST returnits SAML protocol response using a binding that also supports a RelayState mechanism, and it MUSTplace the exact data it received with the request into the corresponding RelayState parameter in theresponse.

If no such value is included with a SAML request message, or if the SAML response message is beinggenerated without a corresponding request, then the SAML responder MAY include RelayState data to beinterpreted by the recipient based on the use of a profile or prior agreement between the parties.

3.4.4 Message EncodingMessages are encoded for use with this binding using a URL encoding technique, and transmitted usingthe HTTP GET method. There are many possible ways to encode XML into a URL, depending on theconstraints in effect. This specification defines one such method without precluding others. Bindingendpoints SHOULD indicate which encodings they support using metadata, when appropriate. Particularencodings MUST be uniquely identified with a URI when defined. It is not a requirement that all possibleSAML messages be encodable with a particular set of rules, but the rules MUST clearly indicate whichmessages or content can or cannot be so encoded.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 16 of 46

524

525526527

528529

530

531

532

533

534

535

536537538539540

541542543

544

545546547548549550

551552553554

555556557

558

559560561562563564565

Page 17: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

A URL encoding MUST place the message entirely within the URL query string, and MUST reserve therest of the URL for the endpoint of the message recipient.

A query string parameter named SAMLEncoding is reserved to identify the encoding mechanism used. Ifthis parameter is omitted, then the value is assumed to beurn:oasis:names:tc:SAML:2.0:bindings:URL-Encoding:DEFLATE.

All endpoints that support this binding MUST support the DEFLATE encoding described in the followingsub-section.

3.4.4.1 DEFLATE Encoding

Identification: urn:oasis:names:tc:SAML:2.0:bindings:URL-Encoding:DEFLATE

SAML protocol messages can be encoded into a URL via the DEFLATE compression method (see[RFC1951]). In such an encoding, the following procedure should be applied to the original SAML protocolmessage's XML serialization:

1. Any signature on the SAML protocol message, including the <ds:Signature> XML element itself,MUST be removed. Note that if the content of the message includes another signature, such as asigned SAML assertion, this embedded signature is not removed. However, the length of such amessage after encoding essentially precludes using this mechanism. Thus SAML protocolmessages that contain signed content SHOULD NOT be encoded using this mechanism.

2. The DEFLATE compression mechanism, as specified in [RFC1951] is then applied to the entireremaining XML content of the original SAML protocol message.

3. The compressed data is subsequently base64-encoded according to the rules specified in IETFRFC 2045 [RFC2045]. Linefeeds or other whitespace MUST be removed from the result.

4. The base-64 encoded data is then URL-encoded, and added to the URL as a query stringparameter which MUST be named SAMLRequest (if the message is a SAML request) orSAMLResponse (if the message is a SAML response).

5. If RelayState data is to accompany the SAML protocol message, it MUST be URL-encoded andplaced in an additional query string parameter named RelayState.

6. If the original SAML protocol message was signed using an XML digital signature, a new signaturecovering the encoded data as specified above MUST be attached using the rules stated below.

XML digital signatures are not directly URL-encoded according to the above rules, due to space concerns.If the underlying SAML protocol message is signed with an XML signature [XMLSig], the URL-encodedform of the message MUST be signed as follows:

1. The signature algorithm identifier MUST be included as an additional query string parameter,named SigAlg. The value of this parameter MUST be a URI that identifies the algorithm used tosign the URL-encoded SAML protocol message, specified according to [XMLSig] or whateverspecification governs the algorithm.

2. To construct the signature, a string consisting of the concatenation of the RelayState (if present),SigAlg, and SAMLRequest (or SAMLResponse) query string parameters (each one URL-encoded) is constructed in one of the following ways (ordered as below):SAMLRequest=value&RelayState=value&SigAlg=valueSAMLResponse=value&RelayState=value&SigAlg=value

3. The resulting string of bytes is the octet string to be fed into the signature algorithm. Any othercontent in the original query string is not included and not signed.

4. The signature value MUST be encoded using the base64 encoding (see RFC 2045 [RFC2045]) withany whitespace removed, and included as a query string parameter named Signature. Note thatsome characters in the base64-encoded signature value may themselves require URL-encodingbefore being added.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 17 of 46

566567

568569570

571572

573

574

575576577

578579580581582

583584

585586

587588589

590591

592593

594595596

597598599600

601602603

604605

606607

608609610611

Page 18: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

5. The following signature algorithms (see [XMLSig]) and their URI representations MUST besupported with this encoding mechanism:

• DSAwithSHA1 – http://www.w3.org/2000/09/xmldsig#dsa-sha1• RSAwithSHA1 – http://www.w3.org/2000/09/xmldsig#rsa-sha1

Note that when verifying signatures, the order of the query string parameters on the resulting URL to beverified is not prescribed by this binding. The parameters may appear in any order. Before verifying asignature, if any, the relying party MUST ensure that the parameter values to be verified are ordered asrequired by the signing rules above.

Further, note that URL-encoding is not canonical; that is, there are multiple legal encodings for a givenvalue. The relying party MUST therefore perform the verification step using the original URL-encodedvalues it received on the query string. It is not sufficient to re-encode the parameters after they have beenprocessed by software because the resulting encoding may not match the signer's encoding.

Finally, note that if there is no RelayState value, the entire parameter should be omitted from thesignature computation (and not included as an empty parameter name).

3.4.5 Message ExchangeThe system model used for SAML conversations via this binding is a request-response model, but thesemessages are sent to the user agent in an HTTP response and delivered to the message recipient in anHTTP request. The HTTP interactions before, between, and after these exchanges take place isunspecified. Both the SAML requester and the SAML responder are assumed to be HTTP responders.See the following sequence diagram illustrating the messages exchanged.

1. Initially, the user agent makes an arbitrary HTTP request to a system entity. In the course ofprocessing the request, the system entity decides to initiate a SAML protocol exchange.

2. The system entity acting as a SAML requester responds to the HTTP request from the user agent instep 1 by returning a SAML request. The SAML request is returned encoded into the HTTP

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 18 of 46

User Agent SAML ResponderSAML Requester

1. User Agent accesses some resource at the SAML Requester using an HTTP request

2. SAML request returned in HTTP Redirect URL to SAML responder, encoded into Location header

3. SAML responder interacts with User Agent, subject to constraints in the SAML request

4. SAML response returned in HTTP Redirect URL to SAML requester, encoded into Location header

5. HTTP response sent to user agent from SAML requester upon completion of SAML exchange

I need to initiate a SAML protocol exchange.

612613

614615

616617618619

620621622623

624625

626

627628629630631

632633

634635

Page 19: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

response's Location header, and the HTTP status MUST be either 303 or 302. The SAML requesterMAY include additional presentation and content in the HTTP response to facilitate the user agent'stransmission of the message, as defined in HTTP 1.1 [RFC2616]. The user agent delivers theSAML request by issuing an HTTP GET request to the SAML responder.

3. In general, the SAML responder MAY respond to the SAML request by immediately returning aSAML response or MAY return arbitrary content to facilitate subsequent interaction with the useragent necessary to fulfill the request. Specific protocols and profiles may include mechanisms toindicate the requester's level of willingness to permit this kind of interaction (for example, theIsPassive attribute in <samlp:AuthnRequest>) .

4. Eventually the responder SHOULD return a SAML response to the user agent to be returned to theSAML requester. The SAML response is returned in the same fashion as described for the SAMLrequest in step 2.

5. Upon receiving the SAML response, the SAML requester returns an arbitrary HTTP response to theuser agent.

3.4.5.1 HTTP and Caching Considerations

HTTP proxies and the user agent intermediary should not cache SAML protocol messages. To ensurethis, the following rules SHOULD be followed.

When returning SAML protocol messages using HTTP 1.1, HTTP responders SHOULD:• Include a Cache-Control header field set to "no-cache, no-store".

• Include a Pragma header field set to "no-cache".

There are no other restrictions on the use of HTTP headers.

3.4.5.2 Security Considerations

The presence of the user agent intermediary means that the requester and responder cannot rely on thetransport layer for end-end authentication, integrity and confidentiality. URL-encoded messages MAY besigned to provide origin authentication and integrity if the encoding method specifies a means for signing.

If the message is signed, the Destination XML attribute in the root SAML element of the protocolmessage MUST contain the URL to which the sender has instructed the user agent to deliver themessage. The recipient MUST then verify that the value matches the location at which the message hasbeen received.

This binding SHOULD NOT be used if the content of the request or response should not be exposed tothe user agent intermediary. Otherwise, confidentiality of both SAML requests and SAML responses isOPTIONAL and depends on the environment of use. If confidentiality is necessary, SSL 3.0 [SSL3] or TLS1.0 [RFC2246] SHOULD be used to protect the message in transit between the user agent and the SAMLrequester and responder.

Note also that URL-encoded messages may be exposed in a variety of HTTP logs as well as the HTTP"Referer" header.

Before deployment, each combination of authentication, message integrity, and confidentialitymechanisms SHOULD be analyzed for vulnerability in the context of the specific protocol exchange, andthe deployment environment. See specific protocol processing rules in [SAMLCore], and the SAMLsecurity considerations document [SAMLSecure] for a detailed discussion.

In general, this binding relies on message-level authentication and integrity protection via signing anddoes not support confidentiality of messages from the user agent intermediary.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 19 of 46

636637638639

640641642643644

645646647

648649

650

651652

653

654

655

656

657

658659660

661662663664

665666667668669

670671

672673674675

676677

Page 20: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

3.4.6 Error ReportingA SAML responder that refuses to perform a message exchange with the SAML requester SHOULDreturn a SAML response message with a second-level <samlp:StatusCode> value ofurn:oasis:names:tc:SAML:2.0:status:RequestDenied.

HTTP interactions during the message exchange MUST NOT use HTTP error status codes to indicatefailures in SAML processing, since the user agent is not a full party to the SAML protocol exchange.

For more information about SAML status codes, see the SAML assertions and protocols specification[SAMLCore].

3.4.7 Metadata ConsiderationsSupport for the HTTP Redirect binding SHOULD be reflected by indicating URL endpoints at whichrequests and responses for a particular protocol or profile should be sent. Either a single endpoint ordistinct request and response endpoints MAY be supplied.

3.4.8 Example SAML Message Exchange Using HTTP RedirectIn this example, a <LogoutRequest> and <LogoutResponse> message pair is exchanged using theHTTP Redirect binding.

First, here are the actual SAML protocol messages being exchanged:<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="d2b7c388cec36fa7c39c28fd298644a8" IssueInstant="2004-01-21T19:00:49Z" Version="2.0"> <Issuer>https://IdentityProvider.com/SAML</Issuer> <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">005a06e0-ad82-110d-a556-004005b13a2b</NameID> <samlp:SessionIndex>1</samlp:SessionIndex></samlp:LogoutRequest>

<samlp:LogoutResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="b0730d21b628110d8b7e004005b13a2b"InResponseTo="d2b7c388cec36fa7c39c28fd298644a8" IssueInstant="2004-01-21T19:00:49Z" Version="2.0"> <Issuer>https://ServiceProvider.com/SAML</Issuer> <samlp:Status> <samlp:StatusCodeValue="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:Status></samlp:LogoutResponse>

The initial HTTP request from the user agent in step 1 is not defined by this binding. To initiate the logoutprotocol exchange, the SAML requester returns the following HTTP response, containing a signed SAMLrequest message. The SAMLRequest parameter value is actually derived from the request messageabove. The signature portion is only illustrative and not the result of an actual computation. Note that theline feeds in the HTTP Location header below are an artifact of the document, and there are no linefeeds in the actual header value.

HTTP/1.1 302 Object MovedDate: 21 Jan 2004 07:00:49 GMT

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 20 of 46

678

679680681

682683

684685

686

687688689

690

691692

693694695696697698699700701702

703704705706707708709710711712713

714715716717718719

720721

Page 21: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Location:https://ServiceProvider.com/SAML/SLO/Browser?SAMLRequest=fVFdS8MwFH0f7D%2BUvGdNsq62oSsIQyhMESc%2B%2BJYlmRbWpObeyvz3puv2IMjyFM7HPedyK1DdsZdb%2F%2BEHfLFfgwVMTt3RgTwzazIEJ72CFqRTnQWJWu7uH7dSLJjsg0ev%2FZFMlttiBWADtt6R%2BSyJr9msiRH7O70sCm31Mj%2Bo%2BC%2B1KA5GlEWeZaogSQMw2MYBKodrIhjLKONU8FdeSsZkVr6T5M0GiHMjvWCknqZXZ2OoPxF7kGnaGOuwxZ%2Fn4L9bY8NC%2By4du1XpRXnxPcXizSZ58KFTeHujEWkNPZylsh9bAMYYUjO2Uiy3jCpTCMo5M1StVjmN9SO150sl9lU6RV2Dp0vsLIy7NM7YU82r9B90PrvCf85W%2FwL8zSVQzAEAAA%3D%3D&RelayState=0043bfc1bc45110dae17004005b13a2b&SigAlg=http%3A%2F%2Fwww.w3.org%2F200%2F09%2Fxmldsig%23rsa-sha1&Signature=NOTAREALSIGNATUREBUTTHEREALONEWOULDGOHEREContent-Type: text/html; charset=iso-8859-1

After any unspecified interactions may have taken place, the SAML responder returns the HTTP responsebelow containing the signed SAML response message. Again, the SAMLResponse parameter value isactually derived from the response message above. The signature portion is only illustrative and not theresult of an actual computation.

HTTP/1.1 302 Object MovedDate: 21 Jan 2004 07:00:49 GMTLocation:https://IdentityProvider.com/SAML/SLO/Response?SAMLResponse=fVFNa4QwEL0X%2Bh8k912TaDUGFUp7EbZQ6rKH3mKcbQVNJBOX%2FvxaXQ9tYec0vHlv3nzkqIZ%2BlAf7YSf%2FBjhagxB8Db1BuZQKMjkjrcIOpVEDoPRa1o8vB8n3VI7OeqttT1bJbbJCBOc7a8j9XTBH9VyQhqYRbTlrEi4Yo61oUqA0pvShYZHiDQkqs411tAVpeZPqSAgNOkrOas4zzcW55ZlI4liJrTXiBJVBr4wvCJ877ijbcXZkmaRUxtk7CU7gcB5mLu8pKVddvghd%2Ben9iDIMa3CXTsOrs5euBbfXdgh%2F9snDK%2FEqW69Ye%2BUnvGL%2F8CfbQnBS%2FQS3z4QLW9aT1oBIws0j%2FGOyAb9%2FV34Dw5k779IBAAA%3D&RelayState=0043bfc1bc45110dae17004005b13a2b&SigAlg=http%3A%2F%2Fwww.w3.org%2F200%2F09%2Fxmldsig%23rsa-sha1&Signature=NOTAREALSIGNATUREBUTTHEREALONEWOULDGOHEREContent-Type: text/html; charset=iso-8859-1

3.5 HTTP POST BindingThe HTTP POST binding defines a mechanism by which SAML protocol messages may be transmittedwithin the base64-encoded content of an HTML form control.

This binding MAY be composed with the HTTP Redirect binding (see Section 3.4) and the HTTP Artifactbinding (see Section 3.6) to transmit request and response messages in a single protocol exchange usingtwo different bindings.

3.5.1 Required InformationIdentification: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

Contact information: [email protected]

Description: Given below.

Updates: Effectively replaces the binding aspects of the Browser/POST profile in SAML V1.1[SAML11Bind].

3.5.2 OverviewThe HTTP POST binding is intended for cases in which the SAML requester and responder need tocommunicate using an HTTP user agent (as defined in HTTP 1.1 [RFC2616]) as an intermediary. Thismay be necessary, for example, if the communicating parties do not share a direct path of communication.It may also be needed if the responder requires an interaction with the user agent in order to fulfill therequest, such as when the user agent must authenticate to it.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 21 of 46

722723724725726727728729730731732733734

735736737738

739740741742743744745746747748749750751752

753

754755

756757758

759

760

761

762

763764

765

766767768769770

Page 22: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Note that some HTTP user agents may have the capacity to play a more active role in the protocolexchange and may support other bindings that use HTTP, such as the SOAP and Reverse SOAPbindings. This binding assumes nothing apart from the capabilities of a common web browser.

3.5.3 RelayStateRelayState data MAY be included with a SAML protocol message transmitted with this binding. The valueMUST NOT exceed 80 bytes in length and SHOULD be integrity protected by the entity creating themessage independent of any other protections that may or may not exist during message transmission.Signing is not realistic given the space limitation, but because the value is exposed to third-partytampering, the entity SHOULD ensure that the value has not been tampered with by using a checksum, apseudo-random value, or similar means.

If a SAML request message is accompanied by RelayState data, then the SAML responder MUST returnits SAML protocol response using a binding that also supports a RelayState mechanism, and it MUSTplace the exact data it received with the request into the corresponding RelayState parameter in theresponse.

If no such value is included with a SAML request message, or if the SAML response message is beinggenerated without a corresponding request, then the SAML responder MAY include RelayState data to beinterpreted by the recipient based on the use of a profile or prior agreement between the parties.

3.5.4 Message EncodingMessages are encoded for use with this binding by encoding the XML into an HTML form control and aretransmitted using the HTTP POST method. A SAML protocol message is form-encoded by applying thebase-64 encoding rules to the XML representation of the message and placing the result in a hidden formcontrol within a form as defined by [HTML401] Section 17. The HTML document MUST adhere to theXHTML specification, [XHTML]. The base64-encoded value MAY be line-wrapped at a reasonable lengthin accordance with common practice.

If the message is a SAML request, then the form control MUST be named SAMLRequest. If the messageis a SAML response, then the form control MUST be named SAMLResponse. Any additional form controlsor presentation MAY be included but MUST NOT be required in order for the recipient to process themessage.

If a “RelayState” value is to accompany the SAML protocol message, it MUST be placed in an additionalhidden form control named RelayState within the same form with the SAML message.

The action attribute of the form MUST be the recipient's HTTP endpoint for the protocol or profile usingthis binding to which the SAML message is to be delivered. The method attribute MUST be "POST".

Any technique supported by the user agent MAY be used to cause the submission of the form, and anyform content necessary to support this MAY be included, such as submit controls and client-side scriptingcommands. However, the recipient MUST be able to process the message without regard for themechanism by which the form submission is initiated.

Note that any form control values included MUST be transformed so as to be safe to include in theXHTML document. This includes transforming characters such as quotes into HTML entities, etc.

3.5.5 Message ExchangeThe system model used for SAML conversations via this binding is a request-response model, but thesemessages are sent to the user agent in an HTTP response and delivered to the message recipient in anHTTP request. The HTTP interactions before, between, and after these exchanges take place isunspecified. Both the SAML requester and responder are assumed to be HTTP responders. See thefollowing diagram illustrating the messages exchanged.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 22 of 46

771772773

774

775776777778779780

781782783784

785786787

788

789790791792793794

795796797798

799800

801802

803804805806

807808

809

810811812813814

Page 23: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

1. Initially, the user agent makes an arbitrary HTTP request to a system entity. In the course ofprocessing the request, the system entity decides to initiate a SAML protocol exchange.

2. The system entity acting as a SAML requester responds to an HTTP request from the user agent byreturning a SAML request. The request is returned in an XHTML document containing the form andcontent defined in Section 3.5.4. The user agent delivers the SAML request by issuing an HTTPPOST request to the SAML responder.

3. In general, the SAML responder MAY respond to the SAML request by immediately returning aSAML response or it MAY return arbitrary content to facilitate subsequent interaction with the useragent necessary to fulfill the request. Specific protocols and profiles may include mechanisms toindicate the requester's level of willingness to permit this kind of interaction (for example, theIsPassive attribute in <samlp:AuthnRequest>).

4. Eventually the responder SHOULD return a SAML response to the user agent to be returned to theSAML requester. The SAML response is returned in the same fashion as described for the SAMLrequest in step 2.

5. Upon receiving the SAML response, the SAML requester returns an arbitrary HTTP response to theuser agent.

3.5.5.1 HTTP and Caching Considerations

HTTP proxies and the user agent intermediary should not cache SAML protocol messages. To ensurethis, the following rules SHOULD be followed.

When returning SAML protocol messages using HTTP 1.1, HTTP responders SHOULD:• Include a Cache-Control header field set to "no-cache, no-store".

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 23 of 46

User Agent SAML ResponderSAML Requester

1. User Agent accesses some resource at the SAML Requester using an HTTP request

2. SAML request returned in XHTML form targeted at SAML Responder, encoded into base64. User Agent submits form in HTTP POST to SAML Responser

3. SAML responder interacts with User Agent, subject to constraints in the SAML request

4. SAML response returned in XHTML form targeted at SAML Requester, encoded into base64. User Agent submits form in HTTP POST to SAML Requester

5. HTTP response sent to user agent from SAMLRrequester upon completion of SAML exchange

I need to initiate a SAML protocol exchange.

815816

817818819820

821822823824825

826827828

829830

831

832833

834

835

Page 24: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

• Include a Pragma header field set to "no-cache".

There are no other restrictions on the use of HTTP headers.

3.5.5.2 Security Considerations

The presence of the user agent intermediary means that the requester and responder cannot rely on thetransport layer for end-end authentication, integrity or confidentiality protection and must authenticate themessages received instead. SAML provides for a signature on protocol messages for authentication andintegrity for such cases. Form-encoded messages MAY be signed before the base64 encoding is applied.

If the message is signed, the Destination XML attribute in the root SAML element of the protocolmessage MUST contain the URL to which the sender has instructed the user agent to deliver themessage. The recipient MUST then verify that the value matches the location at which the message hasbeen received.

This binding SHOULD NOT be used if the content of the request or response should not be exposed tothe user agent intermediary. Otherwise, confidentiality of both SAML requests and SAML responses isOPTIONAL and depends on the environment of use. If confidentiality is necessary, SSL 3.0 [SSL3] or TLS1.0 [RFC2246] SHOULD be used to protect the message in transit between the user agent and the SAMLrequester and responder.

In general, this binding relies on message-level authentication and integrity protection via signing anddoes not support confidentiality of messages from the user agent intermediary.

Note also that there is no mechanism defined to protect the integrity of the relationship between the SAMLprotocol message and the "RelayState" value, if any. That is, an attacker can potentially recombine a pairof valid HTTP responses by switching the "RelayState" values associated with each SAML protocolmessage. The individual "RelayState" and SAML message values can be integrity protected, but not thecombination. As a result, the producer and consumer of "RelayState" information MUST take care not toassociate sensitive state information with the "RelayState" value without taking additional precautions(such as based on the information in the SAML message).

3.5.6 Error ReportingA SAML responder that refuses to perform a message exchange with the SAML requester SHOULDreturn a response message with a second-level <samlp:StatusCode> value ofurn:oasis:names:tc:SAML:2.0:status:RequestDenied.

HTTP interactions during the message exchange MUST NOT use HTTP error status codes to indicatefailures in SAML processing, since the user agent is not a full party to the SAML protocol exchange.

For more information about SAML status codes, see the SAML assertions and protocols specification[SAMLCore].

3.5.7 Metadata ConsiderationsSupport for the HTTP POST binding SHOULD be reflected by indicating URL endpoints at which requestsand responses for a particular protocol or profile should be sent. Either a single endpoint or distinctrequest and response endpoints MAY be supplied.

3.5.8 Example SAML Message Exchange Using HTTP POSTIn this example, a <LogoutRequest> and <LogoutResponse> message pair is exchanged using theHTTP POST binding.

First, here are the actual SAML protocol messages being exchanged:

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 24 of 46

836

837

838

839840841842

843844845846

847848849850851

852853

854855856857858859860

861

862863864

865866

867868

869

870871872

873

874875

876

Page 25: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="d2b7c388cec36fa7c39c28fd298644a8" IssueInstant="2004-01-21T19:00:49Z" Version="2.0"> <Issuer>https://IdentityProvider.com/SAML</Issuer> <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">005a06e0-ad82-110d-a556-004005b13a2b</NameID> <samlp:SessionIndex>1</samlp:SessionIndex></samlp:LogoutRequest>

<samlp:LogoutResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="b0730d21b628110d8b7e004005b13a2b"InResponseTo="d2b7c388cec36fa7c39c28fd298644a8" IssueInstant="2004-01-21T19:00:49Z" Version="2.0"> <Issuer>https://ServiceProvider.com/SAML</Issuer> <samlp:Status> <samlp:StatusCodeValue="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:Status></samlp:LogoutResponse>

The initial HTTP request from the user agent in step 1 is not defined by this binding. To initiate the logoutprotocol exchange, the SAML requester returns the following HTTP response, containing a SAML requestmessage. The SAMLRequest parameter value is actually derived from the request message above.

HTTP/1.1 200 OKDate: 21 Jan 2004 07:00:49 GMTContent-Type: text/html; charset=iso-8859-1

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN""http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"><body onload="document.forms[0].submit()">

<noscript><p><strong>Note:</strong> Since your browser does not support JavaScript,you must press the Continue button once to proceed.</p></noscript>

<form action="https://ServiceProvider.com/SAML/SLO/Browser"method="post"><div><input type="hidden" name="RelayState"value="0043bfc1bc45110dae17004005b13a2b"/><input type="hidden" name="SAMLRequest"value="PHNhbWxwOkxvZ291dFJlcXVlc3QgeG1sbnM6c2FtbHA9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpwcm90b2NvbCIgeG1sbnM9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iDQogICAgSUQ9ImQyYjdjMzg4Y2VjMzZmYTdjMzljMjhmZDI5ODY0NGE4IiBJc3N1ZUluc3RhbnQ9IjIwMDQtMDEtMjFUMTk6MDA6NDlaIiBWZXJzaW9uPSIyLjAiPg0KICAgIDxJc3N1ZXI+aHR0cHM6Ly9JZGVudGl0eVByb3ZpZGVyLmNvbS9TQU1MPC9Jc3N1ZXI+DQogICAgPE5hbWVJRCBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0OnBlcnNpc3RlbnQiPjAwNWEwNmUwLWFkODItMTEwZC1hNTU2LTAwNDAwNWIxM2EyYjwvTmFtZUlEPg0KICAgIDxzYW1scDpTZXNzaW9uSW5kZXg+MTwvc2FtbHA6U2Vzc2lvbkluZGV4Pg0KPC9zYW1scDpMb2dvdXRSZXF1ZXN0Pg=="/></div><noscript><div><input type="submit" value="Continue"/></div></noscript></form></body>

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 25 of 46

877878879880881882883884885

886887888889890891892893894895896

897898899

900901902

903904905906907

908909910911912913

914915916917918919920921922923924925926927928929930931932933934935936937

Page 26: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

</html>

After any unspecified interactions may have taken place, the SAML responder returns the HTTP responsebelow containing the SAML response message. Again, the SAMLResponse parameter value is actuallyderived from the response message above.

HTTP/1.1 200 OKDate: 21 Jan 2004 07:00:49 GMTContent-Type: text/html; charset=iso-8859-1

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN""http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"><body onload="document.forms[0].submit()">

<noscript><p><strong>Note:</strong> Since your browser does not support JavaScript,you must press the Continue button once to proceed.</p></noscript>

<form action="https://IdentityProvider.com/SAML/SLO/Response"method="post"><div><input type="hidden" name="RelayState"value="0043bfc1bc45110dae17004005b13a2b"/><input type="hidden" name="SAMLResponse"value="PHNhbWxwOkxvZ291dFJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIg0KICAgIElEPSJiMDczMGQyMWI2MjgxMTBkOGI3ZTAwNDAwNWIxM2EyYiIgSW5SZXNwb25zZVRvPSJkMmI3YzM4OGNlYzM2ZmE3YzM5YzI4ZmQyOTg2NDRhOCINCiAgICBJc3N1ZUluc3RhbnQ9IjIwMDQtMDEtMjFUMTk6MDA6NDlaIiBWZXJzaW9uPSIyLjAiPg0KICAgIDxJc3N1ZXI+aHR0cHM6Ly9TZXJ2aWNlUHJvdmlkZXIuY29tL1NBTUw8L0lzc3Vlcj4NCiAgICA8c2FtbHA6U3RhdHVzPg0KICAgICAgICA8c2FtbHA6U3RhdHVzQ29kZSBWYWx1ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnN0YXR1czpTdWNjZXNzIi8+DQogICAgPC9zYW1scDpTdGF0dXM+DQo8L3NhbWxwOkxvZ291dFJlc3BvbnNlPg=="/></div><noscript><div><input type="submit" value="Continue"/></div></noscript></form></body></html>

3.6 HTTP Artifact BindingIn the HTTP Artifact binding, the SAML request, the SAML response, or both are transmitted by referenceusing a small stand-in called an artifact. A separate, synchronous binding, such as the SAML SOAPbinding, is used to exchange the artifact for the actual protocol message using the artifact resolutionprotocol defined in the SAML assertions and protocols specification [SAMLCore].

This binding MAY be composed with the HTTP Redirect binding (see Section 3.4) and the HTTP POSTbinding (see Section 3.5) to transmit request and response messages in a single protocol exchange usingtwo different bindings.

3.6.1 Required InformationIdentification: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 26 of 46

938

939940941

942943944

945946947948949

950951952953954955

956957958959960961962963964965966967968969970971972973974975976977978979980

981

982983984985

986987988

989

990

Page 27: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Contact information: [email protected]

Description: Given below.

Updates: Effectively replaces the binding aspects of the Browser/Artifact profile in SAML V1.1[SAML11Bind].

3.6.2 OverviewThe HTTP Artifact binding is intended for cases in which the SAML requester and responder need tocommunicate using an HTTP user agent as an intermediary, but the intermediary's limitations preclude ordiscourage the transmission of an entire message (or message exchange) through it. This may be fortechnical reasons or because of a reluctance to expose the message content to the intermediary (and ifthe use of encryption is not practical).

Note that because of the need to subsequently resolve the artifact using another synchronous binding,such as SOAP, a direct communication path must exist between the SAML message sender and recipientin the reverse direction of the artifact's transmission (the receiver of the message and artifact must beable to send a <samlp:ArtifactResolve> request back to the artifact issuer). The artifact issuer mustalso maintain state while the artifact is pending, which has implications for load-balanced environments.

3.6.3 Message EncodingThere are two methods of encoding an artifact for use with this binding. One is to encode the artifact into aURL parameter and the other is to place the artifact in an HTML form control. When URL encoding isused, the HTTP GET method is used to deliver the message, while POST is used with form encoding. Allendpoints that support this binding MUST support both techniques.

3.6.3.1 RelayState

RelayState data MAY be included with a SAML artifact transmitted with this binding. The value MUSTNOT exceed 80 bytes in length and SHOULD be integrity protected by the entity creating the messageindependent of any other protections that may or may not exist during message transmission. Signing isnot realistic given the space limitation, but because the value is exposed to third-party tampering, theentity SHOULD ensure that the value has not been tampered with by using a checksum, a pseudo-random value, or similar means.

If an artifact that represents a SAML request is accompanied by RelayState data, then the SAMLresponder MUST return its SAML protocol response using a binding that also supports a RelayStatemechanism, and it MUST place the exact data it received with the artifact into the correspondingRelayState parameter in the response.

If no such value is included with an artifact representing a SAML request, or if the SAML responsemessage is being generated without a corresponding request, then the SAML responder MAY includeRelayState data to be interpreted by the recipient based on the use of a profile or prior agreementbetween the parties.

3.6.3.2 URL Encoding

To encode an artifact into a URL, the artifact value is URL-encoded and placed in a query stringparameter named SAMLart.

If a “RelayState” value is to accompany the SAML artifact, it MUST be URL-encoded and placed in anadditional query string parameter named RelayState.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 27 of 46

991

992

993994

995

996997998999

1000

10011002100310041005

1006

1007100810091010

1011

101210131014101510161017

1018101910201021

1022102310241025

1026

10271028

10291030

Page 28: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

3.6.3.3 Form Encoding

A SAML artifact is form-encoded by placing it in a hidden form control within a form as defined by[HTML401], chapter 17. The HTML document MUST adhere to the XHTML specification, [XHTML]. Theform control MUST be named SAMLart. Any additional form controls or presentation MAY be included butMUST NOT be required in order for the recipient to process the artifact.

If a “RelayState” value is to accompany the SAML artifact, it MUST be placed in an additional hidden formcontrol named RelayState, within the same form with the SAML message.

The action attribute of the form MUST be the recipient's HTTP endpoint for the protocol or profile usingthis binding to which the artifact is to be delivered. The method attribute MUST be set to "POST".

Any technique supported by the user agent MAY be used to cause the submission of the form, and anyform content necessary to support this MAY be included, such as submit controls and client-side scriptingcommands. However, the recipient MUST be able to process the artifact without regard for themechanism by which the form submission is initiated.

Note that any form control values included MUST be transformed so as to be safe to include in theXHTML document. This includes transforming characters such as quotes into HTML entities, etc.

3.6.4 Artifact FormatWith respect to this binding, an artifact is a short, opaque string. Different types can be defined and usedwithout affecting the binding. The important characteristics are the ability of an artifact receiver to identifythe issuer of the artifact, resistance to tampering and forgery, uniqueness, and compactness.

The general format of any artifact includes a mandatory two-byte artifact type code and a two-byte indexvalue identifying a specific endpoint of the artifact resolution service of the issuer, as follows:

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

The notation B64(TypeCode EndpointIndex RemainingArtifact) stands for the application ofthe base64 [RFC2045] transformation to the catenation of the TypeCode, EndpointIndex, andRemainingArtifact.

The following practices are RECOMMENDED for the creation of SAML artifacts:• Each issuer is assigned an identifying URI, also known as the issuer's entity (or provider) ID. See

Section 8.3.6 of [SAMLCore] for a discussion of this kind of identifier.

• The issuer constructs the SourceID component of the artifact by taking the SHA-1 hash of theidentification URL. The hash value is NOT encoded into hexadecimal.

• The MessageHandle value is constructed from a cryptographically strong random orpseudorandom number sequence [RFC1750] generated by the issuer. The sequence consists ofvalues of at least 16 bytes in size. These values should be padded as needed to a total length of 20bytes.

The following describes the single artifact type defined by SAML V2.0.

3.6.4.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:artifact-04

Contact information: [email protected]

Description: Given below.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 28 of 46

1031

1032103310341035

10361037

10381039

1040104110421043

10441045

1046

104710481049

10501051

1052

1053

1054

105510561057

1058

10591060

10611062

1063106410651066

1067

1068

1069

1070

1071

Page 29: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Updates: None.

3.6.4.2 Format Details

SAML V2.0 defines an artifact type of type code 0x0004. This artifact type is defined as follows:TypeCode := 0x0004RemainingArtifact := SourceID MessageHandleSourceID := 20-byte_sequenceMessageHandle := 20-byte_sequence

SourceID is a 20-byte sequence used by the artifact receiver to determine artifact issuer identity and theset of possible resolution endpoints.

It is assumed that the destination site will maintain a table of SourceID values as well as one or moreindexed URL endpoints (or addresses) for the corresponding SAML responder. The SAML metadataspecification [SAMLMeta] MAY be used for this purpose. On receiving the SAML artifact, the receiverdetermines if the SourceID belongs to a known artifact issuer and obtains the location of the SAMLresponder using the EndpointIndex before sending a SAML <samlp:ArtifactResolve> messageto it.

Any two artifact issuers with a common receiver MUST use distinct SourceID values. Construction ofMessageHandle values is governed by the principle that they SHOULD have no predictable relationshipto the contents of the referenced message at the issuing site and it MUST be infeasible to construct orguess the value of a valid, outstanding message handle.

3.6.5 Message ExchangeThe system model used for SAML conversations by means of this binding is a request-response model inwhich an artifact reference takes the place of the actual message content, and the artifact reference issent to the user agent in an HTTP response and delivered to the message recipient in an HTTP request.The HTTP interactions before, between, and after these exchanges take place is unspecified. Both theSAML requester and responder are assumed to be HTTP responders.

Additionally, it is assumed that on receipt of an artifact by way of the user agent, the recipient invokes aseparate, direct exchange with the artifact issuer using the Artifact Resolution Protocol defined in[SAMLCore]. This exchange MUST use a binding that does not use the HTTP user agent as anintermediary, such as the SOAP binding. On the successful acquisition of a SAML protocol message, theartifact is discarded and the processing of the primary SAML protocol exchange resumes (or ends, if themessage is a response).

Issuing and delivering an artifact, along with the subsequent resolution step, constitutes half of the overallSAML protocol exchange. This binding can be used to deliver either or both halves of a SAML protocolexchange. A binding composable with it, such as the HTTP Redirect (see Section 3.4) or POST (seeSection 3.5) binding, MAY be used to carry the other half of the exchange. The following sequenceassumes that the artifact binding is used for both halves. See the diagram below illustrating the messagesexchanged.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 29 of 46

1072

1073

1074

1075

1076

1077

1078

10791080

108110821083108410851086

1087108810891090

1091

10921093109410951096

109710981099110011011102

110311041105110611071108

Page 30: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

1. Initially, the user agent makes an arbitrary HTTP request to a system entity. In the course ofprocessing the request, the system entity decides to initiate a SAML protocol exchange.

2. The system entity acting as a SAML requester responds to an HTTP request from the user agent byreturning an artifact representing a SAML request.

• If URL-encoded, the artifact is returned encoded into the HTTP response's Locationheader, and the HTTP status MUST be either 303 or 302. The SAML requester MAYinclude additional presentation and content in the HTTP response to facilitate the useragent's transmission of the message, as defined in HTTP 1.1 [RFC2616]. The user

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 30 of 46

User Agent SAML ResponderSAML Requester

1. User Agent accesses some resource at the SAML Requester using an HTTP request

2. SAML artifact returned in HTTP Redirect URL encoded into Location header or XHTML form control targeted at SAML Responder

5. SAML Responder interacts with User Agent, subject to constraints in the SAML request

6. SAML artifact returned in HTTP Redirect URL encoded into Location header or XHTML form control targeted at SAML Requester

9. HTTP response sent to user agent from SAML requester upon completion of SAML exchange

I need to initiate a SAML protocol exchange.

3. <ArtifactResolve> message sent by SAML Responder directly to SAML Requester

4. <ArtifactResponse> message returned by SAML Requester containing original SAML request message inside

7. <ArtifactResolve> message sent by SAML Requester directly to SAML Responder

8. <ArtifactResponse> message returned by SAML Responder containing original SAML response message inside

11091110

11111112

1113111411151116

Page 31: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

agent delivers the artifact by issuing an HTTP GET request to the SAML responder.

• If form-encoded, then the artifact is returned in an XHTML document containing theform and content defined in Section 3.6.3.3. The user agent delivers the artifact byissuing an HTTP POST request to the SAML responder.

3. The SAML responder determines the SAML requester by examining the artifact (the exact processdepends on the type of artifact), and issues a <samlp:ArtifactResolve> request containingthe artifact to the SAML requester using a direct SAML binding, temporarily reversing roles.

4. Assuming the necessary conditions are met, the SAML requester returns a<samlp:ArtifactResponse> containing the original SAML request message it wishes theSAML responder to process.

5. In general, the SAML responder MAY respond to the SAML request by immediately returning aSAML artifact or MAY return arbitrary content to facilitate subsequent interaction with the user agentnecessary to fulfill the request. Specific protocols and profiles may include mechanisms to indicatethe requester's level of willingness to permit this kind of interaction (for example, the IsPassiveattribute in <samlp:AuthnRequest>).

6. Eventually the responder SHOULD return a SAML artifact to the user agent to be returned to theSAML requester. The SAML response artifact is returned in the same fashion as described for theSAML request artifact in step 2.The SAML requester determines the SAML responder by examiningthe artifact, and issues a <samlp:ArtifactResolve> request containing the artifact to the SAMLresponder using a direct SAML binding, as in step 3.

7. Assuming the necessary conditions are met, the SAML responder returns a<samlp:ArtifactResponse> containing the SAML response message it wishes the requester toprocess, as in step 4.

8. Upon receiving the SAML response, the SAML requester returns an arbitrary HTTP response to theuser agent.

3.6.5.1 HTTP and Caching Considerations

HTTP proxies and the user agent intermediary should not cache SAML artifacts. To ensure this, thefollowing rules SHOULD be followed.

When returning SAML artifacts using HTTP 1.1, HTTP responders SHOULD:• Include a Cache-Control header field set to "no-cache, no-store".

• Include a Pragma header field set to "no-cache".

There are no other restrictions on the use of HTTP headers.

3.6.5.2 Security Considerations

This binding uses a combination of indirect transmission of a message reference followed by a directexchange to return the actual message. As a result, the message reference (artifact) need not itself beauthenticated or integrity protected, but the callback request/response exchange that returns the actualmessage MAY be mutually authenticated and integrity protected, depending on the environment of use.

If the actual SAML protocol message is intended for a specific recipient, then the artifact's issuer MUSTauthenticate the sender of the subsequent <samlp:ArtifactResolve> message before returning theactual message.

The transmission of an artifact to and from the user agent SHOULD be protected with confidentiality; SSL3.0 [SSL3] or TLS 1.0 [RFC2246] SHOULD be used. The callback request/response exchange thatreturns the actual message MAY be protected, depending on the environment of use.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 31 of 46

1117

111811191120

112111221123

112411251126

11271128112911301131

11321133113411351136

113711381139

11401141

1142

11431144

1145

1146

1147

1148

1149

1150115111521153

115411551156

115711581159

Page 32: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

In general, this binding relies on the artifact as a hard-to-forge short-term reference and applies othersecurity measures to the callback request/response that returns the actual message. All artifacts MUSThave a single-use semantic enforced by the artifact issuer.

Furthermore, it is RECOMMENDED that artifact receivers also enforce a single-use semantic on theartifact values they receive, to prevent an attacker from interfering with the resolution of an artifact by auser agent and then resubmitting it to the artifact receiver. If an attempt to resolve an artifact does notcomplete successfully, the artifact SHOULD be placed into a blocked artifact list for a period of time thatexceeds a reasonable acceptance period during which the artifact issuer would resolve the artifact.

Note also that there is no mechanism defined to protect the integrity of the relationship between theartifact and the "RelayState" value, if any. That is, an attacker can potentially recombine a pair of validHTTP responses by switching the "RelayState" values associated with each artifact. As a result, theproducer/consumer of "RelayState" information MUST take care not to associate sensitive stateinformation with the "RelayState" value without taking additional precautions (such as based on theinformation in the SAML protocol message retrieved via artifact).

3.6.6 Error ReportingA SAML responder that refuses to perform a message exchange with the SAML requester SHOULDreturn a response message with a second-level <samlp:StatusCode> value ofurn:oasis:names:tc:SAML:2.0:status:RequestDenied.

HTTP interactions during the message exchange MUST NOT use HTTP error status codes to indicatefailures in SAML processing, since the user agent is not a full party to the SAML protocol exchange.

If the issuer of an artifact receives a <samlp:ArtifactResolve> message that it can understand, itMUST return a <samlp:ArtifactResponse> with a <samlp:StatusCode> value ofurn:oasis:names:tc:SAML:2.0:status:Success, even if it does not return the correspondingmessage (for example because the artifact requester is not authorized to receive the message or theartifact is no longer valid).

For more information about SAML status codes, see the SAML assertions and protocols specification[SAMLCore].

3.6.7 Metadata ConsiderationsSupport for the HTTP Artifact binding SHOULD be reflected by indicating URL endpoints at whichrequests and responses for a particular protocol or profile should be sent. Either a single endpoint ordistinct request and response endpoints MAY be supplied. One or more indexed endpoints for processing<samlp:ArtifactResolve> messages SHOULD also be described.

3.6.8 Example SAML Message Exchange Using HTTP ArtifactIn this example, a <LogoutRequest> and <LogoutResponse> message pair is exchanged using theHTTP Artifact binding, with the artifact resolution taking place using the SOAP binding bound to HTTP.

First, here are the actual SAML protocol messages being exchanged:<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="d2b7c388cec36fa7c39c28fd298644a8" IssueInstant="2004-01-21T19:00:49Z" Version="2.0"> <Issuer>https://IdentityProvider.com/SAML</Issuer> <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">005a06e0-ad82-110d-a556-004005b13a2b</NameID> <samlp:SessionIndex>1</samlp:SessionIndex></samlp:LogoutRequest>

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 32 of 46

116011611162

11631164116511661167

116811691170117111721173

1174

117511761177

11781179

11801181118211831184

11851186

1187

1188118911901191

1192

11931194

1195119611971198119912001201120212031204

Page 33: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

<samlp:LogoutResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="b0730d21b628110d8b7e004005b13a2b"InResponseTo="d2b7c388cec36fa7c39c28fd298644a8" IssueInstant="2004-01-21T19:00:49Z" Version="2.0"> <Issuer>https://ServiceProvider.com/SAML</Issuer> <samlp:Status> <samlp:StatusCodeValue="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:Status></samlp:LogoutResponse>

The initial HTTP request from the user agent in step 1 is not defined by this binding. To initiate the logoutprotocol exchange, the SAML requester returns the following HTTP response, containing a SAML artifact.Note that the line feeds in the HTTP Location header below are a result of document formatting, andthere are no line feeds in the actual header value.

HTTP/1.1 302 Object MovedDate: 21 Jan 2004 07:00:49 GMTLocation:https://ServiceProvider.com/SAML/SLO/Browser?SAMLart=AAQAADWNEw5VT47wcO4zX%2FiEzMmFQvGknDfws2ZtqSGdkNSbsW1cmVR0bzU%3D&RelayState=0043bfc1bc45110dae17004005b13a2bContent-Type: text/html; charset=iso-8859-1

The SAML responder then resolves the artifact it received into the actual SAML request using the ArtifactResolution protocol and the SOAP binding in steps 3 and 4, as follows:Step 3:

POST /SAML/Artifact/Resolve HTTP/1.1Host: IdentityProvider.comContent-Type: text/xmlContent-Length: nnnSOAPAction: http://www.oasis-open.org/committees/security<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <samlp:ArtifactResolve

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns="urn:oasis:names:tc:SAML:2.0:assertion"ID="_6c3a4f8b9c2d" Version="2.0"IssueInstant="2004-01-21T19:00:49Z"><Issuer>https://ServiceProvider.com/SAML</Issuer><Artifact>AAQAADWNEw5VT47wcO4zX/iEzMmFQvGknDfws2ZtqSGdkNSbsW1cmVR0bzU=</Artifact>

</samlp:ArtifactResolve> </SOAP-ENV:Body></SOAP-ENV:Envelope>

Step 4:HTTP/1.1 200 OKDate: 21 Jan 2004 07:00:49 GMTContent-Type: text/xmlContent-Length: nnnn

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <samlp:ArtifactResponse

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns="urn:oasis:names:tc:SAML:2.0:assertion"ID="_FQvGknDfws2Z" Version="2.0"InResponseTo="_6c3a4f8b9c2d"

IssueInstant="2004-01-21T19:00:49Z"><Issuer>https://IdentityProvider.com/SAML</Issuer>

<samlp:Status>

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 33 of 46

12051206120712081209121012111212121312141215

1216121712181219

1220122112221223122412251226

12271228

1229

12301231123212331234123512361237123812391240124112421243124412451246124712481249

1250

1251125212531254

12551256125712581259126012611262126312641265

Page 34: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

<samlp:StatusCodeValue="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status><samlp:LogoutRequest ID="d2b7c388cec36fa7c39c28fd298644a8"

IssueInstant="2004-01-21T19:00:49Z"Version="2.0">

<Issuer>https://IdentityProvider.com/SAML</Issuer> <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">005a06e0-ad82-110d-a556-004005b13a2b</NameID> <samlp:SessionIndex>1</samlp:SessionIndex>

</samlp:LogoutRequest> </samlp:ArtifactResponse> </SOAP-ENV:Body></SOAP-ENV:Envelope>

After any unspecified interactions may have taken place, the SAML responder returns a second SAMLartifact in its HTTP response in step 6:

HTTP/1.1 302 Object MovedDate: 21 Jan 2004 07:05:49 GMTLocation:https://IdentityProvider.com/SAML/SLO/Response?SAMLart=AAQAAFGIZXv5%2BQaBaE5qYurHWJO1nAgLAsqfnyiDHIggbFU0mlSGFTyQiPc%3D&RelayState=0043bfc1bc45110dae17004005b13a2bContent-Type: text/html; charset=iso-8859-1

The SAML responder then resolves the artifact it received into the actual SAML request using the ArtifactResolution protocol and the SOAP binding in steps 7 and 8, as follows:Step 7:

POST /SAML/Artifact/Resolve HTTP/1.1Host: ServiceProvider.comContent-Type: text/xmlContent-Length: nnnSOAPAction: http://www.oasis-open.org/committees/security<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <samlp:ArtifactResolve

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns="urn:oasis:names:tc:SAML:2.0:assertion"ID="_ec36fa7c39" Version="2.0"IssueInstant="2004-01-21T19:05:49Z"><Issuer>https://IdentityProvider.com/SAML</Issuer><Artifact>AAQAAFGIZXv5+QaBaE5qYurHWJO1nAgLAsqfnyiDHIggbFU0mlSGFTyQiPc=</Artifact>

</samlp:ArtifactResolve> </SOAP-ENV:Body></SOAP-ENV:Envelope>

Step 8:HTTP/1.1 200 OKDate: 21 Jan 2004 07:05:49 GMTContent-Type: text/xmlContent-Length: nnnn

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <samlp:ArtifactResponse

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns="urn:oasis:names:tc:SAML:2.0:assertion"ID="_FQvGknDfws2Z" Version="2.0"InResponseTo="_ec36fa7c39"

IssueInstant="2004-01-21T19:05:49Z"><Issuer>https://ServiceProvider.com/SAML</Issuer>

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 34 of 46

12661267126812691270127112721273127412751276127712781279

12801281

1282128312841285128612871288

12891290

1291

12921293129412951296129712981299130013011302130313041305130613071308130913101311

13121313131413151316

1317131813191320132113221323132413251326

Page 35: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

<samlp:Status><samlp:StatusCode

Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status><samlp:LogoutResponse ID="_b0730d21b628110d8b7e004005b13a2b"

InResponseTo="_d2b7c388cec36fa7c39c28fd298644a8"IssueInstant="2004-01-21T19:05:49Z"Version="2.0">

<Issuer>https://ServiceProvider.com/SAML</Issuer><samlp:Status>

<samlp:StatusCodeValue="urn:oasis:names:tc:SAML:2.0:status:Success"/>

</samlp:Status></samlp:LogoutResponse>

</samlp:ArtifactResponse> </SOAP-ENV:Body></SOAP-ENV:Envelope>

3.7 SAML URI BindingURIs are a protocol-independent means of referring to a resource. This binding is not a general SAMLrequest/response binding, but rather supports the encapsulation of a <samlp:AssertionIDRequest>message with a single <saml:AssertionIDRef> into the resolution of a URI. The result of a successfulrequest is a SAML <saml:Assertion> element (but not a complete SAML response).

Like SOAP, URI resolution can occur over multiple underlying transports. This binding has transport-independent aspects, but also calls out the use of HTTP with SSL 3.0 [SSL3] or TLS 1.0 [RFC2246] asREQUIRED (mandatory to implement).

3.7.1 Required InformationIdentification: urn:oasis:names:tc:SAML:2.0:bindings:URI

Contact information: [email protected]

Description: Given below.

Updates: None

3.7.2 Protocol-Independent Aspects of the SAML URI BindingThe following sections define aspects of the SAML URI binding that are independent of the underlyingtransport protocol of the URI resolution process.

3.7.2.1 Basic Operation

A SAML URI reference identifies a specific SAML assertion. The result of resolving the URI MUST be amessage containing the assertion, or a transport-specific error. The specific format of the messagedepends on the underlying transport protocol. If the transport protocol permits the returned content to bedescribed, such as HTTP 1.1 [RFC2616], then the assertion MAY be encoded in whatever format ispermitted. If not, the assertion MUST be returned in a form which can be unambiguously interpreted as ortransformed into an XML serialization of the assertion.

It MUST be the case that if the same URI reference is resolved in the future, then either the same SAMLassertion, or an error, is returned. That is, the reference MAY be persistent but MUST consistentlyreference the same assertion, if any.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 35 of 46

13271328132913301331133213331334133513361337133813391340134113421343

1344

1345134613471348

134913501351

1352

1353

1354

1355

1356

1357

13581359

1360

136113621363136413651366

136713681369

Page 36: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

3.7.3 Security ConsiderationsIndirect use of a SAML assertion presents dangers if the binding of the reference to the result is notsecure. The particular threats and their severity depend on the use to which the assertion is being put. Ingeneral, the result of resolving a URI reference to a SAML assertion SHOULD only be trusted if therequester can be certain of the identity of the responder and that the contents have not been modified intransit.

It is often not sufficient that the assertion itself be signed, because URI references are by their naturesomewhat opaque to the requester. The requester SHOULD have independent means to ensure that theassertion returned is actually the one that is represented by the URI; this is accomplished by bothauthenticating the responder and relying on the integrity of the response.

3.7.4 MIME EncapsulationFor resolution protocols that support MIME as a content description and packaging mechanism, theresulting assertion SHOULD be returned as a MIME entity of type application/samlassertion+xml,as defined by [SAMLmime].

3.7.5 Use of HTTP URIsA SAML authority that claims conformance to the SAML URI binding MUST implement support for HTTP.This section describes certain specifics of using HTTP URIs, including URI syntax, HTTP headers, anderror reporting.

3.7.5.1 URI Syntax

In general, there are no restrictions on the permissible syntax of a SAML URI reference as long as theSAML authority responsible for the reference creates the message containing it. However, authoritiesMUST support a URL endpoint at which an HTTP request can be sent with a single query stringparameter named ID. There MUST be no query string in the endpoint URL itself independent of thisparameter.

For example, if the documented endpoint at an authority is "https://saml.example.edu/assertions", arequest for an assertion with an ID of abcde can be sent to:

https://saml.example.edu/assertions?ID=abcdeNote that the use of wildcards is not allowed for such ID queries.

3.7.5.2 HTTP and Caching Considerations

HTTP proxies MUST NOT cache SAML assertions. To ensure this, the following rules SHOULD befollowed.

When returning SAML assertions using HTTP 1.1, HTTP responders SHOULD:• Include a Cache-Control header field set to "no-cache, no-store".

• Include a Pragma header field set to "no-cache".

3.7.5.3 Security Considerations

RFC 2617 [RFC2617] describes possible attacks in the HTTP environment when basic or message-digestauthentication schemes are used.

Use of SSL 3.0 [SSL3] or TLS 1.0 [RFC2246] is STRONGLY RECOMMENDED as a means ofauthentication, integrity protection, and confidentiality.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 36 of 46

1370

13711372137313741375

1376137713781379

1380

138113821383

1384

138513861387

1388

13891390139113921393

13941395

1396

1397

1398

13991400

1401

1402

1403

1404

14051406

14071408

Page 37: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

3.7.5.4 Error Reporting

As an HTTP protocol exchange, the appropriate HTTP status code SHOULD be used to indicate the resultof a request. For example, a SAML responder that refuses to perform a message exchange with theSAML requester SHOULD return a "403 Forbidden" response. If the assertion specified is unknown tothe responder, then a "404 Not Found" response SHOULD be returned. In these cases, the content ofthe HTTP body is not significant.

3.7.5.5 Metadata Considerations

Support for the URI binding over HTTP SHOULD be reflected by indicating a URL endpoint at whichrequests for arbitrary assertions are to be sent.

3.7.5.6 Example SAML Message Exchange Using an HTTP URI

Following is an example of a request for an assertion.GET /SamlService?ID=abcde HTTP/1.1Host: www.example.com

Following is an example of the corresponding response, which supplies the requested assertion.HTTP/1.1 200 OKContent-Type: application/samlassertion+xmlCache-Control: no-cache, no-storePragma: no-cacheContent-Length: nnnn

<saml:Assertion ID="abcde" ...>...</saml:Assertion>

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 37 of 46

1409

14101411141214131414

1415

14161417

1418

141914201421

142214231424142514261427

142814291430

Page 38: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

4 References[HTML401] D. Raggett et al. HTML 4.01 Specification. World Wide Web Consortium

Recommendation, December 1999. See http://www.w3.org/TR/html4.[Liberty] The Liberty Alliance Project. See http://www.projectliberty.org.[PAOS] R. Aarts. Liberty Reverse HTTP Binding for SOAP Specification Version 1.0.

Liberty Alliance Project, 2003. See https://www.projectliberty.org/specs/liberty-paos-v1.0.pdf.

[RFC1750] D. Eastlake et al. Randomness Recommendations for Security. IETF RFC 1750,December 1994. See http://www.ietf.org/rfc/rfc1750.txt.

[RFC2045] N. Freed et al. Multipurpose Internet Mail Extensions (MIME) Part One: Format ofInternet Message Bodies, IETF RFC 2045, November 1996. Seehttp://www.ietf.org/rfc/rfc2045.txt.

[RFC2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETFRFC 2119, March 1997. See http://www.ietf.org/rfc/rfc2119.txt.

[RFC2246] T. Dierks et al. The TLS Protocol Version 1.0. IETF RFC 2246, January 1999.See http://www.ietf.org/rfc/rfc2246.txt.

[RFC2279] F. Yergeau. UTF-8, a transformation format of ISO 10646. IETF RFC 2279,January 1998. See http://www.ietf.org/rfc/rfc2279.txt.

[RFC2616] R. Fielding et al. Hypertext Transfer Protocol – HTTP/1.1. IETF RFC 2616, June1999. See http://www.ietf.org/rfc/rfc2616.txt.

[RFC2617] J. Franks et al. HTTP Authentication: Basic and Digest Access Authentication.IETF RFC 2617, June 1999. See http://www.ietf.org/rfc/rfc2617.txt.

[SAML11Bind] E. Maler et al. Bindings and Profiles for the OASIS Security Assertion MarkupLanguage (SAML). OASIS, September 2003. Document ID oasis-sstc-saml-bindings-1.1. See http://www.oasis-open.org/committees/security/.

[SAMLConform] P. Mishra et al. Conformance Requirements for the OASIS Security AssertionMarkup Language (SAML) V2.0. OASIS SSTC, March 2005. Document ID saml-conformance-2.0-os. See http://www.oasis-open.org/committees/security/.

[SAMLCore] S. Cantor et al. Assertions and Protocols for the OASIS Security AssertionMarkup Language (SAML) V2.0. OASIS SSTC, March 2005. Document ID saml-core-2.0-os. See http://www.oasis-open.org/committees/security/.

[SAMLGloss] J. Hodges et al. Glossary for the OASIS Security Assertion Markup Language(SAML) V2.0. OASIS SSTC, March 2005. Document ID saml-glossary-2.0-os.See http://www.oasis-open.org/committees/security/.

[SAMLMeta] S. Cantor et al. Metadata for the OASIS Security Assertion Markup Language(SAML) V2.0. OASIS SSTC, March 2005. Document ID saml-metadata-2.0-os.See http://www.oasis-open.org/committees/security/.

[SAMLmime] application/saml+xml Media Type Registration, IETF Internet-Draft,http://www.ietf.org/internet-drafts/draft-hodges-saml-mediatype-01.txt.

[SAMLProfile] S. Cantor et al. Profiles for the OASIS Security Assertion Markup Language(SAML) V2.0. OASIS SSTC, March 2005. Document ID saml-profiles-2.0-os. Seehttp://www.oasis-open.org/committees/security/.

[SAMLSecure] F. Hirsch et al. Security and Privacy Considerations for the OASIS SecurityAssertion Markup Language (SAML) V2.0. OASIS SSTC, March 2005. DocumentID saml-sec-consider-2.0-os. See http://www.oasis-open.org/committees/security/.

[SOAP11] D. Box et al. Simple Object Access Protocol (SOAP) 1.1. World Wide Web

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 38 of 46

1431

14321433

1434

143514361437

14381439

144014411442

14431444

14451446

14471448

14491450

14511452

145314541455

145614571458

145914601461

146214631464

146514661467

14681469

147014711472

1473147414751476

1477

Page 39: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Consortium Note, May 2000. See http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.

[SOAP-PRIMER] N. Mitra. SOAP Version 1.2 Part 0: Primer. World Wide Web ConsortiumRecommendation, June 2003. See http://www.w3.org/TR/soap12-part0/,

[SSL3] A. Frier et al. The SSL 3.0 Protocol. Netscape Communications Corp, November1996.

[SSTCWeb] OASIS Security Services Technical Committee website, http://www.oasis-open.org/committees/security.

[XHTML] XHTML 1.0 The Extensible HyperText Markup Language (Second Edition). WorldWide Web Consortium Recommendation, August 2002. Seehttp://www.w3.org/TR/xhtml1/.

[XMLSig] D. Eastlake et al. XML-Signature Syntax and Processing. World Wide WebConsortium Recommendation, February 2002. Seehttp://www.w3.org/TR/xmldsig-core/.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 39 of 46

14781479

14801481

14821483

14841485

148614871488

148914901491

Page 40: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Appendix A. Registration of MIME media typeapplication/samlassertion+xml

IntroductionThis document defines a MIME media type -- application/samlassertion+xml -- for usewith the XML serialization of SAML (Security Assertion Markup Language) assertions.

The SAML specification sets -- [SAMLv1.0], [SAMLv1.1], [SAMLv2.0] -- are work products of theOASIS Security Services Technical Committee [SSTC]. The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. Using SAML, onecan assert that an authentication event pertaining to some subject has occured and convey saidassertion to a relying party, for example.

SAML assertions, which are explicitly versioned, are defined by [SAMLv1Core], [SAMLv11Core],and [SAMLv2Core].

MIME media type nameapplication

MIME subtype namesamlassertion+xml

Required parametersNone

Optional parameterscharsetSame as charset parameter of application/xml [RFC3023].

Encoding considerationsSame as for application/xml [RFC3023].

Security considerationsPer their specification, samlassertion+xml-typed objects do not contain executable content.However, SAML assertions are XML-based objects [XML]. As such, they have all of the generalsecurity considerations presented in Section 10 of [RFC3023], as well as additional ones, sincethey are explicit security objects. For example, samlassertion+xml-typed objects will oftencontain data that may identify or pertain to a natural person, and may be used as a basis forsessions and access control decisions.

To counter potential issues, samlassertion+xml-typed objects contain data that should besigned appropriately by the sender. Any such signature must be verified by the recipient of thedata - both as a valid signature, and as being the signature of the sender. Issuers ofsamlassertion+xml-typed objects containing SAMLv2 assertions may also encrypt all, orportions of, the assertions (see [SAMLv2Core]).

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 40 of 46

1492

1493

1494

14951496

14971498149915001501

15021503

1504

1505

1506

1507

1508

1509

1510

15111512

1513

1514

1515

151615171518151915201521

15221523152415251526

Page 41: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

In addition, SAML profiles and protocol bindings specify use of secure channels as appropriate.

[SAMLv2.0] incorporates various privacy-protection techniques in its design. For example: opaquehandles, specific to interactions between specific system entities, may be assigned to subjects.The handles are mappable to wider-context identifiers (e.g. email addresses, account identifiers,etc) by only the specific parties.

For a more detailed discussion of SAML security considerations and specific security-relateddesign techniques, please refer to the SAML specifications listed in the below bibliography. Thespecifications containing security-specific information have been explicitly listed for each versionof SAML.

Interoperability considerationsSAML assertions are explicitly versioned. Relying parties should ensure that they observeassertion version information and behave accordingly. See chapters on SAML Versioning in[SAMLv1Core], [SAMLv11Core], or [SAMLv2Core], as appropriate.

Published specification[SAMLv2Bind] explicitly specifies use of the application/samlassertion+xml MIME mediatype. However, it is conceivable that non-SAMLv2 assertions (i.e., SAMLv1 and/or SAMLv1.1)might in practice be conveyed using SAMLv2 bindings.

Applications which use this media typePotentially any application implementing SAML, as well as those applications implementingspecifications based on SAML, e.g. those available from the Liberty Alliance [LAP].

Additional information

Magic number(s)In general, the same as for application/xml [RFC3023]. In particular, the XML root element of thereturned object will have a namespace-qualified name with:

– a local name of: Assertion

– a namespace URI of: one of the version-specific SAML assertion XMLnamespace URIs, as defined by the appropriate version-specific SAML "core"specification (see bibliography).

With SAMLv2.0 specifically , the root element of the returned object may be either<saml:Assertion> or <saml:EncryptedAssertion>, where "saml" represents any XMLnamespace prefix that maps to the SAMLv2.0 assertion namespace URI:

urn:oasis:names:tc:SAML:2.0:assertion

File extension(s)None

Macintosh File Type Code(s)None

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 41 of 46

1527

1528152915301531

1532153315341535

1536

153715381539

1540

154115421543

1544

15451546

1547

1548

15491550

1551

155215531554

155515561557

1558

1559

1560

1561

1562

Page 42: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Person & email address to contact for further informationThis registration is made on behalf of the OASIS Security Services Technical Committee (SSTC)Please refer to the SSTC website for current information on committee chairperson(s) and theircontact addresses: http://www.oasis-open.org/committees/security/. Committee members shouldsubmit comments and potential errata to the [email protected] list. Othersshould submit them by filling out the web form located at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=security.

Additionally, the SAML developer community email distribution list, [email protected], may be employed to discuss usage of the application/samlassertion+xmlMIME media type. The "saml-dev" mailing list is publicly archived here: http://lists.oasis-open.org/archives/saml-dev/. To post to the "saml-dev" mailing list, one must subscribe to it. Tosubscribe, send a message with the single word "subscribe" in the message body, to: [email protected].

Intended usageCOMMON

Author/Change controllerThe SAML specification sets are a work product of the OASIS Security Services TechnicalCommittee (SSTC). OASIS and the SSTC have change control over the SAML specification sets.

Bibliography[LAP] “Liberty Alliance Project”. See http://www.projectliberty.org/[OASIS] “Organization for the Advancement of Structured Information Systems”.

See http://www.oasis-open.org/[RFC3023] M. Murata, S. St.Laurent, D. Kohn, “XML Media Types”, IETF Request for

Comments 3023, January 2001. Available as http://www.rfc-editor.org/rfc/rfc3023.txt

[SAMLv1.0] OASIS Security Services Technical Committee, “Security AssertionMarkup Language (SAML) Version 1.0 Specification Set”. OASISStandard 200205, November 2002. Available as http://www.oasis-open.org/committees/download.php/2290/oasis-sstc-saml-1.0.zip

[SAMLv1Bind] Prateek Mishra et al., “Bindings and Profiles for the OASIS SecurityAssertion Markup Language (SAML)”, OASIS, November 2002.Document ID oasis-sstc-saml-bindings-1.0. See http://www.oasis-open.org/committees/security/

[SAMLv1Core] Phillip Hallam-Baker et al., “Assertions and Protocol for the OASISSecurity Assertion Markup Language (SAML)”, OASIS, November 2002.Document ID oasis-sstc-saml-core-1.0. See http://www.oasis-open.org/committees/security/

[SAMLv1Sec] Chris McLaren et al., “Security Considerations for the OASIS SecurityAssertion Markup Language (SAML)”, OASIS, November 2002.Document ID oasis-sstc-saml-sec-consider-1.0. See http://www.oasis-open.org/committees/security/

[SAMLv1.1] OASIS Security Services Technical Committee, “Security AssertionMarkup Language (SAML) Version 1.1 Specification Set”. OASISStandard 200308, August 2003. Available as http://www.oasis-open.org/committees/download.php/3400/oasis-sstc-saml-1.1-pdf-xsd.zip

[SAMLv11Bind] E. Maler et al. “Bindings and Profiles for the OASIS Security AssertionMarkup Language (SAML)”. OASIS, September 2003. Document ID

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 42 of 46

1563

156415651566156715681569

157015711572157315741575

1576

1577

1578

15791580

1581

1582

15831584

158515861587

1588158915901591

1592159315941595

1596159715981599

1600160116021603

1604160516061607

16081609

Page 43: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

oasis-sstc-saml-bindings-1.1. http://www.oasis-open.org/committees/security/

[SAMLv11Core] E. Maler et al. “Assertions and Protocol for the OASIS Security AssertionMarkup Language (SAML)”. OASIS, September 2003. Document IDoasis-sstc-saml-core-1.1. http://www.oasis-open.org/committees/security/

[SAMLv11Sec] E. Maler et al. “Security Considerations for the OASIS Security AssertionMarkup Language (SAML)”. OASIS, September 2003. Document IDoasis-sstc-saml-sec-consider-1.1. http://www.oasis-open.org/committees/security/

[SAMLv2.0] OASIS Security Services Technical Committee, “Security AssertionMarkup Language (SAML) Version 2.0 Specification Set”. OASISStandard, 15-Mar-2005. Available at: http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip

[SAMLv2Bind] S. Cantor et al., “Bindings for the OASIS Security Assertion MarkupLanguage (SAML) V2.0”. OASIS, March 2005. Document ID saml-bindings-2.0-os. Available at: http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

[SAMLv2Core] S. Cantor et al., “Assertions and Protocols for the OASIS SecurityAssertion Markup Language (SAML) V2.0”. OASIS, March 2005.Document ID saml-core-2.0-os. Available at: http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

[SAMLv2Prof] S. Cantor et al., “Profiles for the OASIS Security Assertion MarkupLanguage (SAML) V2.0”. OASIS, March 2005. Document ID saml-profiles-2.0-os. Available at: http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

[SAMLv2Sec] F. Hirsch et al., “Security and Privacy Considerations for the OASISSecurity Assertion Markup Language (SAML) V2.0”. OASIS, March 2005.Document ID saml-sec-consider-2.0-os. Available at: http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

[SSTC] “OASIS Security Services Technical Committee”. See http://www.oasis-open.org/committees/security/

[XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler, FrançoisYergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", WorldWide Web Consortium Recommendation REC-xml, Feb 2004, Availableas http://www.w3.org/TR/REC-xml/

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 43 of 46

16101611

161216131614

1615161616171618

1619162016211622

1623162416251626

1627162816291630

1631163216331634

1635163616371638

16391640

1641164216431644

Page 44: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Appendix B. AcknowledgmentsThe editors would like to acknowledge the contributions of the OASIS Security Services TechnicalCommittee, whose voting members at the time of publication were:

• Conor Cahill, AOL• John Hughes, Atos Origin• Hal Lockhart, BEA Systems• Mike Beach, Boeing• Rebekah Metz, Booz Allen Hamilton• Rick Randall, Booz Allen Hamilton• Ronald Jacobson, Computer Associates• Gavenraj Sodhi, Computer Associates• Thomas Wisniewski, Entrust• Carolina Canales-Valenzuela, Ericsson• Dana Kaufman, Forum Systems• Irving Reid, Hewlett-Packard• Guy Denton, IBM• Heather Hinton, IBM• Maryann Hondo, IBM• Michael McIntosh, IBM• Anthony Nadalin, IBM• Nick Ragouzis, Individual• Scott Cantor, Internet2• Bob Morgan, Internet2• Peter Davis, Neustar• Jeff Hodges, Neustar• Frederick Hirsch, Nokia• Senthil Sengodan, Nokia• Abbie Barbir, Nortel Networks• Scott Kiester, Novell• Cameron Morris, Novell• Paul Madsen, NTT• Steve Anderson, OpenNetwork• Ari Kermaier, Oracle• Vamsi Motukuru, Oracle• Darren Platt, Ping Identity• Prateek Mishra, Principal Identity• Jim Lien, RSA Security• John Linn, RSA Security• Rob Philpott, RSA Security• Dipak Chopra, SAP• Jahan Moreh, Sigaba• Bhavna Bhatnagar, Sun Microsystems

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 44 of 46

1645

16461647

1648

1649

1650

1651

1652

1653

1654

1655

1656

1657

1658

1659

1660

1661

1662

1663

1664

1665

1666

1667

1668

1669

1670

1671

1672

1673

1674

1675

1676

1677

1678

1679

1680

1681

1682

1683

1684

1685

1686

Page 45: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

• Eve Maler, Sun Microsystems• Ronald Monzillo, Sun Microsystems• Emily Xu, Sun Microsystems• Greg Whitehead, Trustgenix

The editors also would like to acknowledge the following former SSTC members for their contributions tothis or previous versions of the OASIS Security Assertions Markup Language Standard:

• Stephen Farrell, Baltimore Technologies• David Orchard, BEA Systems• Krishna Sankar, Cisco Systems• Zahid Ahmed, CommerceOne• Tim Alsop, CyberSafe Limited• Carlisle Adams, Entrust• Tim Moses, Entrust• Nigel Edwards, Hewlett-Packard• Joe Pato, Hewlett-Packard• Bob Blakley, IBM• Marlena Erdos, IBM• Marc Chanliau, Netegrity• Chris McLaren, Netegrity• Lynne Rosenthal, NIST • Mark Skall, NIST• Charles Knouse, Oblix• Simon Godik, Overxeer• Charles Norwood, SAIC• Evan Prodromou, Securant• Robert Griffin, RSA Security (former editor)• Sai Allarvarpu, Sun Microsystems• Gary Ellison, Sun Microsystems• Chris Ferris, Sun Microsystems• Mike Myers, Traceroute Security • Phillip Hallam-Baker, VeriSign (former editor)• James Vanderbeek, Vodafone• Mark O’Neill, Vordel• Tony Palmer, Vordel

Finally, the editors wish to acknowledge the following people for their contributions of material used asinput to the OASIS Security Assertions Markup Language specifications:

• Thomas Gross, IBM• Birgit Pfitzmann, IBM

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 45 of 46

1687

1688

1689

1690

16911692

1693

1694

1695

1696

1697

1698

1699

1700

1701

1702

1703

1704

1705

1706

1707

1708

1709

1710

1711

1712

1713

1714

1715

1716

1717

1718

1719

1720

17211722

1723

1724

Page 46: Bindings for SAML 2.0 - OASISdocs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf · 1 Introduction This document specifies SAML protocol bindings for the use of SAML assertions

Appendix C. NoticesOASIS takes no position regarding the validity or scope of any intellectual property or other rights thatmight be claimed to pertain to the implementation or use of the technology described in this document orthe extent to which any license under such rights might or might not be available; neither does it representthat it has made any effort to identify any such rights. Information on OASIS's procedures with respect torights in OASIS specifications can be found at the OASIS website. Copies of claims of rights madeavailable for publication and any assurances of licenses to be made available, or the result of an attemptmade to obtain a general license or permission for the use of such proprietary rights by implementors orusers of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, orother proprietary rights which may cover technology that may be required to implement this specification.Please address the information to the OASIS Executive Director.

Copyright © OASIS Open 2005. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works thatcomment on or otherwise explain it or assist in its implementation may be prepared, copied, published anddistributed, in whole or in part, without restriction of any kind, provided that the above copyright notice andthis paragraph are included on all such copies and derivative works. However, this document itself maynot be modified in any way, such as by removing the copyright notice or references to OASIS, except asneeded for the purpose of developing OASIS specifications, in which case the procedures for copyrightsdefined in the OASIS Intellectual Property Rights document must be followed, or as required to translate itinto languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successorsor assigns.

This document and the information contained herein is provided on an “AS IS” basis and OASISDISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANYWARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS ORANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

saml-bindings-2.0-os 15 March 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 46 of 46

1725

17261727172817291730173117321733

173417351736

1737

17381739174017411742174317441745

17461747

1748174917501751