Bindings for the OASIS Security Assertion Markup Language ...

1 Bindings for the OASIS SecurityAssertion Markup Language (SAML) Standard, 15 March 2005 Document : :Scott Cantor, Internet2 Frederick Hirsch, NokiaJohn Kemp, NokiaRob Philpott, RSA SecurityEve Maler, Sun MicrosystemsSAML 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, IBMM aryann Hondo, IBMM ichael 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, NTTS teve Anderson, OpenNetworkPrateek Mishra, Principal IdentityJohn Linn, RSA SecurityRob Philpott, RSA SecurityJahan Moreh, SigabaAnne Anderson, Sun MicrosystemsEve Maler, Sun MicrosystemsRon Monzillo, Sun March 2005 Copyright OASIS Open 2005.

2 All Rights 1 of 4612345678910111213141516171819202122232 4252627282930313233343536373839404142434 4 Greg Whitehead, TrustgenixAbstract:This specification defines protocol Bindings for the use of SAML assertions and request-responsemessages in communications protocols and :This is an OASIS Standard document produced by the Security Services Technical Committee. Itwas approved by the OASIS membership on 1 March members should submit comments and potential errata to the list. Others should submit them by filling out the web form locatedat Thecommittee will publish on its web page ( ) a catalogof any changes made to this document as a result of 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 ( ).

3 March 2005 Copyright OASIS Open 2005. All Rights 2 of 4645464748495051525354555657585960 Table of Contents1 Protocol Binding guidelines for Specifying Additional Protocol Protocol General Use of Use of SSL or TLS Data Origin Message Message Security SAML SOAP Required Protocol-Independent Aspects of the SAML SOAP Basic SOAP Use of SOAP over HTTP Error Metadata Example SAML Message Exchange Using SOAP over Reverse SOAP (PAOS) Required Message HTTP Request, SAML Request in SOAP SAML Response in SOAP Request, HTTP Security Error Metadata HTTP Redirect Required Message DEFLATE Message HTTP and Caching Security Error Metadata Example SAML Message Exchange Using HTTP March 2005 Copyright OASIS Open 2005.

4 All Rights 3 of HTTP POST Required Message Message HTTP and Caching Security Error Metadata Example SAML Message Exchange Using HTTP HTTP Artifact Required Message URL Form Artifact Required Format Message HTTP and Caching Security Error Metadata Example SAML Message Exchange Using HTTP SAML URI Required Protocol-Independent Aspects of the SAML URI Basic Security MIME Use of HTTP URI HTTP and Caching Security Error Metadata Example SAML Message Exchange Using an HTTP A. Registration of MIME media type application/samlassertion+ B. C. March 2005 Copyright OASIS Open 2005. All Rights 4 of 4610810911011111211311411511611711811912 0121122123124125126127128129130131132133 1341351361371381391401411421431441451461 471481491501511 IntroductionThis document specifies SAML protocol Bindings for the use of SAML assertions and request-responsemessages in communications protocols and SAML assertions and protocols specification [SAMLCore] defines the SAML assertions and request-response messages themselves, and the SAML profiles specification [SAMLP rofile] defines specificusage patterns that reference both [SAMLCore] and Bindings defined in this specification or SAML conformance document [SAMLC onform]

5 Lists all of the specifications that comprise 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 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 otherwise specified, a binding should be understood to support the transmission of any SAML protocol message derived from the samlp:RequestAbstractType and samlp:StatusResponseTypetypes.

6 Further, when a binding refers to "SAML requests and responses", it should be understood to meanany protocol messages derived from those other terms and concepts that are specific to SAML, refer to the SAML glossary [SAMLG loss]. 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 code listings appear like : Notes like this are sometimes used to highlight non-normative 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:PrefixXML NamespaceCommentssaml:urn: OASIS :names:tc : :assertionThis is the SAML Assertion namespace[SAMLCore].

7 Samlp:urn: OASIS :names:tc: :protocolThis is the SAML protocol namespace[SAMLCore]. March 2005 Copyright OASIS Open 2005. All Rights 5 of 4615215315415515615715815916016116216316 4165166167168169170171172173174175176177 178179180181182183 PrefixXML NamespaceCommentsds: #This namespace is defined in the XML SignatureSyntax and Processing specification [XMLSig] andits governing : namespace is defined in SOAP [SOAP11].This specification uses the following typographical conventions in text: <ns:Element>, XMLA ttribute,Datatype, OtherKeyword. In some cases, angle brackets are used to indicate non-terminals, rather thanXML elements; the intent will be clear from the March 2005 Copyright OASIS Open 2005. All Rights 6 of 461841851862 guidelines for Specifying Additional ProtocolBindingsThis specification defines a selected set of protocol Bindings , but others will possibly be developed in thefuture.

8 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 SSTC welcomes submission of proposals from OASIS members for new protocol Bindings . OASIS members 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 refer to the SSTC web site [SSTCWeb] for further details on how to submit such proposals to is a checklist of issues that MUST be addressed by each protocol 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 the set of interactions between parties involved in the binding.

9 Any restrictions onapplications used by each party and the protocols involved in each interaction must be explicitlycalled the parties involved in each interaction, including how many parties are involved andwhether intermediaries may be the method of authentication of parties involved in each interaction, including whetherauthentication is required and acceptable authentication the level of support for message integrity, including the mechanisms used to ensuremessage 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 the error states, including the error states at each participant, especially those that receiveand process SAML assertions or Security considerations, including analysis of threats and description of 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 March 2005 Copyright OASIS Open 2005.

10 All Rights 7 of 4618718818919019119219319419519619719819 9200201202203204205206207208209210211212 2132142152162172182192203 Protocol BindingsThe following sections define the protocol Bindings that are specified as part of the SAML General ConsiderationsThe following sections describe normative characteristics of all protocol Bindings defined for 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 , 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 SecurityUnless stated otherwise, these Security statements apply to all Bindings .