1 2 3 4

Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0
OASIS Standard, 15 March 2005
Document identifier: saml-profiles-2.0-os Location: http://docs.oasis-open.org/security/saml/v2.0/ Editors: John Hughes, Atos Origin Scott Cantor, Internet2 Jeff Hodges, Neustar Frederick Hirsch, Nokia Prateek Mishra, Principal Identity 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
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 1 of 66

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

45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63

Eve Maler, Sun Microsystems Ron Monzillo, Sun Microsystems Greg Whitehead, Trustgenix Abstract: This specification defines profiles for the use of SAML assertions and request-response messages in communications protocols and frameworks, as well as profiles for SAML attribute value syntax and naming conventions. Status: This is an OASIS Standard document produced by the Security Services Technical Committee. It was 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 located at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=security. The committee will publish on its web page (http://www.oasis-open.org/committees/security) a catalog of any changes made to this document. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights web page for the Security Services TC (http://www.oasisopen.org/committees/security/ipr.php).

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 2 of 66

64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109

Table of Contents
1 Introduction.................................................................................................................................................. 7 1.1 Profile Concepts..................................................................................................................................7 1.2 Notation................................................................................................................................................7 2 Specification of Additional Profiles............................................................................................................10 2.1 Guidelines for Specifying Profiles......................................................................................................10 2.2 Guidelines for Specifying Attribute Profiles........................................................................................10 3 Confirmation Method Identifiers................................................................................................................12 3.1 Holder of Key.....................................................................................................................................12 3.2 Sender Vouches................................................................................................................................. 2 1 3.3 Bearer................................................................................................................................................13 4 SSO Profiles of SAML...............................................................................................................................14 4.1 Web Browser SSO Profile.................................................................................................................14 4.1.1 Required Information..................................................................................................................14 4.1.2 Profile Overview.......................................................................................................................... 4 1 4.1.3 Profile Description....................................................................................................................... 6 1 4.1.3.1 HTTP Request to Service Provider.....................................................................................16 4.1.3.2 Service Provider Determines Identity Provider................................................................... 16 4.1.3.3 <AuthnRequest> Is Issued by Service Provider to Identity Provider...................................16 4.1.3.4 Identity Provider Identifies Principal....................................................................................17 4.1.3.5 Identity Provider Issues <Response> to Service Provider..................................................17 4.1.3.6 Service Provider Grants or Denies Access to User Agent..................................................17 4.1.4 Use of Authentication Request Protocol.....................................................................................18 4.1.4.1 <AuthnRequest> Usage......................................................................................................18 4.1.4.2 <Response> Usage............................................................................................................. 8 1 4.1.4.3 <Response> Message Processing Rules...........................................................................19 4.1.4.4 Artifact-Specific <Response> Message Processing Rules.................................................20 4.1.4.5 POST-Specific Processing Rules........................................................................................20 4.1.5 Unsolicited Responses...............................................................................................................20 4.1.6 Use of Metadata.........................................................................................................................20 4.2 Enhanced Client or Proxy (ECP) Profile............................................................................................21 4.2.1 Required Information..................................................................................................................21 4.2.2 Profile Overview.......................................................................................................................... 1 2 4.2.3 Profile Description....................................................................................................................... 4 2 4.2.3.1 ECP issues HTTP Request to Service Provider.................................................................24 4.2.3.2 Service Provider Issues <AuthnRequest> to ECP..............................................................25 4.2.3.3 ECP Determines Identity Provider.......................................................................................25 4.2.3.4 ECP issues <AuthnRequest> to Identity Provider...............................................................25 4.2.3.5 Identity Provider Identifies Principal....................................................................................25 4.2.3.6 Identity Provider issues <Response> to ECP, targeted at service provider....................... 26 4.2.3.7 ECP Conveys <Response> Message to Service Provider................................................. 26 4.2.3.8 Service Provider Grants or Denies Access to Principal......................................................26 4.2.4 ECP Profile Schema Usage.......................................................................................................26 4.2.4.1 PAOS Request Header Block: SP to ECP..........................................................................27 4.2.4.2 ECP Request Header Block: SP to ECP.............................................................................28 4.2.4.3 ECP RelayState Header Block: SP to ECP.........................................................................28
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 3 of 66

110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155

4.2.4.4 ECP Response Header Block: IdP to ECP.........................................................................29 4.2.4.5 PAOS Response Header Block: ECP to SP.......................................................................30 4.2.5 Security Considerations..............................................................................................................31 4.3 Identity Provider Discovery Profile.....................................................................................................31 4.3.1 Common Domain Cookie...........................................................................................................31 4.3.2 Setting the Common Domain Cookie.........................................................................................32 4.3.3 Obtaining the Common Domain Cookie.....................................................................................32 4.4 Single Logout Profile..........................................................................................................................32 4.4.1 Required Information..................................................................................................................33 4.4.2 Profile Overview.......................................................................................................................... 3 3 4.4.3 Profile Description....................................................................................................................... 4 3 4.4.3.1 <LogoutRequest> Issued by Session Participant to Identity Provider................................ 34 4.4.3.2 Identity Provider Determines Session Participants.............................................................35 4.4.3.3 <LogoutRequest> Issued by Identity Provider to Session Participant/Authority................. 35 4.4.3.4 Session Participant/Authority Issues <LogoutResponse> to Identity Provider................... 36 4.4.3.5 Identity Provider Issues <LogoutResponse> to Session Participant...................................36 4.4.4 Use of Single Logout Protocol....................................................................................................37 4.4.4.1 <LogoutRequest> Usage....................................................................................................37 4.4.4.2 <LogoutResponse> Usage.................................................................................................37 4.4.5 Use of Metadata.........................................................................................................................37 4.5 Name Identifier Management Profile.................................................................................................37 4.5.1 Required Information..................................................................................................................38 4.5.2 Profile Overview.......................................................................................................................... 8 3 4.5.3 Profile Description....................................................................................................................... 8 3 4.5.3.1 <ManageNameIDRequest> Issued by Requesting Identity/Service Provider.....................39 4.5.3.2 <ManageNameIDResponse> issued by Responding Identity/Service Provider................. 39 4.5.4 Use of Name Identifier Management Protocol...........................................................................40 4.5.4.1 <ManageNameIDRequest> Usage.....................................................................................40 4.5.4.2 <ManageNameIDResponse> Usage..................................................................................40 4.5.5 Use of Metadata.........................................................................................................................40 5 Artifact Resolution Profile..........................................................................................................................41 5.1 Required Information.........................................................................................................................41 5.2 Profile Overview.................................................................................................................................41 5.3 Profile Description..............................................................................................................................42 5.3.1 <ArtifactResolve> issued by Requesting Entity..........................................................................42 5.3.2 <ArtifactResponse> issued by Responding Entity......................................................................42 5.4 Use of Artifact Resolution Protocol....................................................................................................42 5.4.1 <ArtifactResolve> Usage............................................................................................................42 5.4.2 <ArtifactResponse> Usage.........................................................................................................43 5.5 Use of Metadata................................................................................................................................. 3 4 6 Assertion Query/Request Profile...............................................................................................................44 6.1 Required Information.........................................................................................................................44 6.2 Profile Overview.................................................................................................................................44 6.3 Profile Description..............................................................................................................................45 6.3.1 Query/Request issued by SAML Requester...............................................................................45 6.3.2 <Response> issued by SAML Authority.....................................................................................45
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 4 of 66

156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199

6.4 Use of Query/Request Protocol.........................................................................................................45 6.4.1 Query/Request Usage................................................................................................................45 6.4.2 <Response> Usage....................................................................................................................45 6.5 Use of Metadata................................................................................................................................. 6 4 7 Name Identifier Mapping Profile................................................................................................................47 7.1 Required Information.........................................................................................................................47 7.2 Profile Overview.................................................................................................................................47 7.3 Profile Description..............................................................................................................................48 7.3.1 <NameIDMappingRequest> issued by Requesting Entity..........................................................48 7.3.2 <NameIDMappingResponse> issued by Identity Provider.........................................................48 7.4 Use of Name Identifier Mapping Protocol..........................................................................................48 7.4.1 <NameIDMappingRequest> Usage............................................................................................48 7.4.2 <NameIDMappingResponse> Usage.........................................................................................48 7.4.2.1 Limiting Use of Mapped Identifier........................................................................................49 7.5 Use of Metadata................................................................................................................................. 9 4 8 SAML Attribute Profiles.............................................................................................................................50 8.1 Basic Attribute Profile.........................................................................................................................50 8.1.1 Required Information..................................................................................................................50 8.1.2 SAML Attribute Naming..............................................................................................................50 8.1.2.1 Attribute Name Comparison................................................................................................50 8.1.3 Profile-Specific XML Attributes...................................................................................................50 8.1.4 SAML Attribute Values................................................................................................................ 0 5 8.1.5 Example......................................................................................................................................50 8.2 X.500/LDAP Attribute Profile..............................................................................................................50 8.2.1 Required Information..................................................................................................................51 8.2.2 SAML Attribute Naming..............................................................................................................51 8.2.2.1 Attribute Name Comparison................................................................................................51 8.2.3 Profile-Specific XML Attributes...................................................................................................51 8.2.4 SAML Attribute Values................................................................................................................ 1 5 8.2.5 Profile-Specific Schema.............................................................................................................52 8.2.6 Example......................................................................................................................................53 8.3 UUID Attribute Profile.........................................................................................................................53 8.3.1 Required Information..................................................................................................................53 8.3.2 UUID and GUID Background......................................................................................................53 8.3.3 SAML Attribute Naming..............................................................................................................54 8.3.3.1 Attribute Name Comparison................................................................................................54 8.3.4 Profile-Specific XML Attributes...................................................................................................54 8.3.5 SAML Attribute Values................................................................................................................ 4 5 8.3.6 Example......................................................................................................................................54 8.4 DCE PAC Attribute Profile.................................................................................................................. 5 5 8.4.1 Required Information..................................................................................................................55 8.4.2 PAC Description.........................................................................................................................55 8.4.3 SAML Attribute Naming..............................................................................................................55 8.4.3.1 Attribute Name Comparison................................................................................................55
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 5 of 66

200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219

8.4.4 Profile-Specific XML Attributes...................................................................................................55 8.4.5 SAML Attribute Values................................................................................................................ 6 5 8.4.6 Attribute Definitions..................................................................................................................... 6 5 8.4.6.1 Realm..................................................................................................................................56 8.4.6.2 Principal...............................................................................................................................57 8.4.6.3 Primary Group.....................................................................................................................57 8.4.6.4 Groups................................................................................................................................. 7 5 8.4.6.5 Foreign Groups...................................................................................................................57 8.4.7 Example......................................................................................................................................58 8.5 XACML Attribute Profile.....................................................................................................................58 8.5.1 Required Information..................................................................................................................59 8.5.2 SAML Attribute Naming..............................................................................................................59 8.5.2.1 Attribute Name Comparison................................................................................................59 8.5.3 Profile-Specific XML Attributes...................................................................................................59 8.5.4 SAML Attribute Values................................................................................................................ 9 5 8.5.5 Profile-Specific Schema.............................................................................................................59 8.5.6 Example......................................................................................................................................60 9 References................................................................................................................................................61 Appendix A. Acknowledgments....................................................................................................................64 Appendix B. Notices.....................................................................................................................................66

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 6 of 66

220 221 222 223 224 225 226 227

1 Introduction
This document specifies profiles that define the use of SAML assertions and request-response messages in communications protocols and frameworks, as well as profiles that define SAML attribute value syntax and naming conventions. The SAML assertions and protocols specification [SAMLCore] defines the SAML assertions and requestresponse protocol messages themselves, and the SAML bindings specification [SAMLBind] defines bindings of SAML protocol messages to underlying communications and messaging protocols. The SAML conformance document [SAMLConform] lists all of the specifications that comprise SAML V2.0.

228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253

1.1 Profile Concepts

One type of SAML profile outlines a set of rules describing how to embed SAML assertions into and extract them from a framework or protocol. Such a profile describes how SAML assertions are embedded in or combined with other objects (for example, files of various types, or protocol data units of communication protocols) by an originating party, communicated from the originating party to a receiving party, and subsequently processed at the destination. A particular set of rules for embedding SAML assertions into and extracting them from a specific class of <FOO> objects is termed a <FOO> profile of SAML. For example, a SOAP profile of SAML describes how SAML assertions can be added to SOAP messages, how SOAP headers are affected by SAML assertions, and how SAML-related error states should be reflected in SOAP messages. Another type of SAML profile defines a set of constraints on the use of a general SAML protocol or assertion capability for a particular environment or context of use. Profiles of this nature may constrain optionality, require the use of specific SAML functionality (for example, attributes, conditions, or bindings), and in other respects define the processing rules to be followed by profile actors. A particular example of the latter are those that address SAML attributes. The SAML <Attribute> element provides a great deal of flexibility in attribute naming, value syntax, and including in-band metadata through the use of XML attributes. Interoperability is achieved by constraining this flexibility when warranted by adhering to profiles that define how to use these elements with greater specificity than the generic rules defined by [SAMLCore]. Attribute profiles provide the definitions necessary to constrain SAML attribute expression when dealing with particular types of attribute information or when interacting with external systems or other open standards that require greater strictness. The intent of this specification is to specify a selected set of profiles of various kinds in sufficient detail to ensure that independently implemented products will interoperate. For other terms and concepts that are specific to SAML, refer to the SAML glossary [SAMLGloss].

254 255 256 257 258 259 260 261

1.2 Notation
This specification uses schema documents conforming to W3C XML Schema [Schema1] and normative text to describe the syntax and semantics of XML-encoded SAML assertions and protocol messages. In cases of disagreement between the SAML profile schema documents and schema listings in this specification, the schema documents take precedence. Note that in some cases the normative text of this specification imposes constraints beyond those indicated by the schema documents. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 7 of 66

262

described in IETF RFC 2119 [RFC2119].

263 264 265 266 267

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 respective namespaces as follows, whether or not a namespace declaration is present in the example:

Prefix

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

Comments This is the SAML V2.0 assertion namespace [SAMLCore]. The prefix is generally elided in mentions of SAML assertion-related elements in text. This is the SAML V2.0 protocol namespace [SAMLCore]. The prefix is generally elided in mentions of XML protocol-related elements in text. This is the SAML V2.0 metadata namespace [SAMLMeta]. This is the SAML V2.0 ECP profile namespace, specified in this document and in a schema [SAMLECP-xsd]. This is the XML Signature namespace [XMLSig]. This is the XML Encryption namespace [XMLEnc]. This is the SOAP V1.1 namespace [SOAP1.1]. This is the Liberty Alliance PAOS namespace.

saml:

samlp:

urn:oasis:names:tc:SAML:2.0:protocol

md:
ecp:

urn:oasis:names:tc:SAML:2.0:metadata urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp

ds: xenc: SOAP-ENV: paos: dce:

http://www.w3.org/2000/09/xmldsig# http://www.w3.org/2001/04/xmlenc# http://schemas.xmlsoap.org/soap/envelope urn:liberty:paos:2003-08

urn:oasis:names:tc:SAML:2.0:profiles:attribute: This is the SAML V2.0 DCE PAC attribute profile namespace, specified in this DCE

document and in a schema [SAMLDCE-xsd].

x500:

urn:oasis:names:tc:SAML:2.0:profiles:attribute: This is the SAML V2.0 X.500/LDAP attribute profile namespace, specified in this X500
document and in a schema [SAMLX500xsd].

xacmlprof: urn:oasis:names:tc:SAML:2.0:profiles:attribute: This is the SAML V2.0 XACML attribute profile namespace, specified in this XACML
xsi: http://www.w3.org/2001/XMLSchema-instance

document and in a schema [SAMLXAC-xsd]. This namespace is defined in the W3C XML Schema specification [Schema1] for schema-related markup that appears in XML instances.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 8 of 66

268 269 270

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

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 9 of 66

271 272 273 274 275 276 277 278 279

2 Specification of Additional Profiles

This specification defines a selected set of profiles, but others will possibly be developed in the future. It is not possible for the OASIS Security Services Technical Committee to standardize all of these additional profiles for two reasons: it has limited resources and it does not own the standardization process for all of the technologies used. The following sections offer guidelines for specifying profiles. The SSTC welcomes proposals for new profiles. OASIS members may wish to submit these proposals for consideration by the SSTC in a future version of this specification. Other members may simply wish to inform the committee of their work related to SAML. Please refer to the SSTC website [SAMLWeb] for further details on how to submit such proposals to the SSTC.

280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301

2.1 Guidelines for Specifying Profiles

This section provides a checklist of issues that MUST be addressed by each profile. 1. Specify a URI that uniquely identifies the profile, postal or electronic contact information for the author, and provide reference to previously defined profiles that the new profile updates or obsoletes. 2. Describe the set of interactions between parties involved in the profile. Any restrictions on applications used by each party and the protocols involved in each interaction must be explicitly called out. 3. Identify the parties involved in each interaction, including how many parties are involved and whether intermediaries may be involved. 4. Specify the method of authentication of parties involved in each interaction, including whether authentication is required and acceptable authentication types. 5. Identify the level of support for message integrity, including the mechanisms used to ensure message integrity. 6. Identify the level of support for confidentiality, including whether a third party may view the contents of SAML messages and assertions, whether the profile requires confidentiality, and the mechanisms recommended for achieving confidentiality. 7. Identify the error states, including the error states at each participant, especially those that receive and process SAML assertions or messages. 8. Identify security considerations, including analysis of threats and description of countermeasures. 9. Identify SAML confirmation method identifiers defined and/or utilized by the profile. 10.Identify relevant SAML metadata defined and/or utilized by the profile.

302 303 304 305 306 307 308 309 310

2.2 Guidelines for Specifying Attribute Profiles

This section provides a checklist of items that MUST in particular be addressed by attribute profiles. 1. Specify a URI that uniquely identifies the profile, postal or electronic contact information for the author, and provide reference to previously defined profiles that the new profile updates or obsoletes. 2. Syntax and restrictions on the acceptable values of the NameFormat and Name attributes of SAML <Attribute> elements. 3. Any additional namespace-qualified XML attributes defined by the profile that may be used in SAML <Attribute> elements.
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 10 of 66

311 312 313 314

4. Rules for determining the equality of SAML <Attribute> elements as defined by the profile, for use when processing attributes, queries, etc. 5. Syntax and restrictions on values acceptable in the SAML <AttributeValue> element, including whether the xsi:type XML attribute can or should be used.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 11 of 66

315 316 317 318 319 320 321 322 323 324 325 326 327 328

3 Confirmation Method Identifiers

The SAML assertion and protocol specification [SAMLCore] defines the <SubjectConfirmation> element as a Method plus optional <SubjectConfirmationData>. The <SubjectConfirmation> element SHOULD be used by the relying party to confirm that the request or message came from a system entity that is associated with the subject of the assertion, within the context of a particular profile. The Method attribute indicates the specific method that the relying party should use to make this determination. This may or may not have any relationship to an authentication that was performed previously. Unlike the authentication context, the subject confirmation method will often be accompanied by additional information, such as a certificate or key, in the <SubjectConfirmationData> element that will allow the relying party to perform the necessary verification. A common set of attributes is also defined and MAY be used to constrain the conditions under which the verification can take place. It is anticipated that profiles will define and use several different values for <ConfirmationMethod>, each corresponding to a different SAML usage scenario. The following methods are defined for use by profiles defined within this specification and other profiles that find them useful.

329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358

3.1 Holder of Key

URI: urn:oasis:names:tc:SAML:2.0:cm:holder-of-key One or more <ds:KeyInfo> elements MUST be present within the <SubjectConfirmationData> element. An xsi:type attribute MAY be present in the <SubjectConfirmationData> element and, if present, MUST be set to saml:KeyInfoConfirmationDataType (the namespace prefix is arbitrary but must reference the SAML assertion namespace). As described in [XMLSig], each <ds:KeyInfo> element holds a key or information that enables an application to obtain a key. The holder of a specified key is considered to be the subject of the assertion by the asserting party. Note that in accordance with [XMLSig], each <ds:KeyInfo> element MUST identify a single cryptographic key. Multiple keys MAY be identified with separate <ds:KeyInfo> elements, such as when different confirmation keys are needed for different relying parties. Example: The holder of the key named "By-Tor" or the holder of the key named "Snow Dog" can confirm itself as the subject.
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"> <SubjectConfirmationData xsi:type="saml:KeyInfoConfirmationDataType"> <ds:KeyInfo> <ds:KeyName>By-Tor</ds:KeyName> </ds:KeyInfo> <ds:KeyInfo> <ds:KeyName>Snow Dog</ds:KeyName> </ds:KeyInfo> </SubjectConfirmationData> </SubjectConfirmation>

3.2 Sender Vouches

URI: urn:oasis:names:tc:SAML:2.0:cm:sender-vouches Indicates that no other information is available about the context of use of the assertion. The relying party SHOULD utilize other means to determine if it should process the assertion further, subject to optional constraints on confirmation using the attributes that MAY be present in the <SubjectConfirmationData> element, as defined by [SAMLCore].
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 12 of 66

359 360 361 362 363 364 365 366 367 368 369 370 371 372

3.3 Bearer
URI: urn:oasis:names:tc:SAML:2.0:cm:bearer The subject of the assertion is the bearer of the assertion, subject to optional constraints on confirmation using the attributes that MAY be present in the <SubjectConfirmationData> element, as defined by [SAMLCore]. Example: The bearer of the assertion can confirm itself as the subject, provided the assertion is delivered in a message sent to "https://www.serviceprovider.com/saml/consumer" before 1:37 PM GMT on March 19th, 2004, in response to a request with ID "_1234567890".
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <SubjectConfirmationData InResponseTo="_1234567890" Recipient="https://www.serviceprovider.com/saml/consumer" NotOnOrAfter="2004-03-19T13:27:00Z" </SubjectConfirmationData> </SubjectConfirmation>

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 13 of 66

373 374 375 376 377 378 379 380

4 SSO Profiles of SAML

A set of profiles is defined to support single sign-on (SSO) of browsers and other client devices.

A web browser-based profile of the Authentication Request protocol in [SAMLCore] is defined to support web single sign-on, supporting Scenario 1-1 of the original SAML requirements document . An additional web SSO profile is defined to support enhanced clients. A profile of the Single Logout and Name Identifier Management protocols in [SAMLCore] is defined over both front-channel (browser) and back-channel bindings. An additional profile is defined for identity provider discovery using cookies.

381 382 383 384 385 386 387 388 389 390 391 392

4.1 Web Browser SSO Profile

In the scenario supported by the web browser SSO profile, a web user either accesses a resource at a service provider, or accesses an identity provider such that the service provider and desired resource are understood or implicit. The web user authenticates (or has already authenticated) to the identity provider, which then produces an authentication assertion (possibly with input from the service provider) and the service provider consumes the assertion to establish a security context for the web user. During this process, a name identifier might also be established between the providers for the principal, subject to the parameters of the interaction and the consent of the parties. To implement this scenario, a profile of the SAML Authentication Request protocol is used, in conjunction with the HTTP Redirect, HTTP POST and HTTP Artifact bindings. It is assumed that the user is using a standard commercial browser and can authenticate to the identity provider by some means outside the scope of SAML.

393 394 395 396 397 398 399

4.1.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:profiles:SSO:browser Contact information: [email protected] SAML Confirmation Method Identifiers: The SAML V2.0 "bearer" confirmation method identifier, urn:oasis:names:tc:SAML:2.0:cm:bearer, is used by this profile. Description: Given below. Updates: SAML V1.1 browser artifact and POST profiles and bearer confirmation method.

400 401 402 403

4.1.2 Profile Overview

Figure 1 illustrates the basic template for achieving SSO. The following steps are described by the profile. Within an individual step, there may be one or more actual message exchanges depending on the binding used for that step and other implementation-dependent behavior.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 14 of 66

User Agent

Service Provider

Identity Provider

Do I have a security context for this UA? Hm, no, so I'm going to establish one...

1. User Agent attempts to access some resource at the Service Provider

2. Service Provider determines Identity Provider to use (methods vary, details not shown)

3. <AuthnRequest> message issued by Service Provider to Identity Provider

4. Identity Provider identifies Principal (methods vary, details not shown)

5. <Response> message issued by Identity Provider to Service Provider

6. Based on the Identity Provider's response identifying (or not) the Principal, the Service Provider either returns the resource or an (HTTP) error

Figure 1
404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419

1. HTTP Request to Service Provider In step 1, the principal, via an HTTP User Agent, makes an HTTP request for a secured resource at the service provider without a security context. 2. Service Provider Determines Identity Provider In step 2, the service provider obtains the location of an endpoint at an identity provider for the authentication request protocol that supports its preferred binding. The means by which this is accomplished is implementation-dependent. The service provider MAY use the SAML identity provider discovery profile described in Section 4.3. 3. <AuthnRequest> issued by Service Provider to Identity Provider In step 3, the service provider issues an <AuthnRequest> message to be delivered by the user agent to the identity provider. Either the HTTP Redirect, HTTP POST, or HTTP Artifact binding can be used to transfer the message to the identity provider through the user agent. 4. Identity Provider identifies Principal In step 4, the principal is identified by the identity provider by some means outside the scope of this profile. This may require a new act of authentication, or it may reuse an existing authenticated session.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 15 of 66

420 421 422 423 424 425 426 427 428 429 430 431

5. Identity Provider issues <Response> to Service Provider In step 5, the identity provider issues a <Response> message to be delivered by the user agent to the service provider. Either the HTTP POST, or HTTP Artifact binding can be used to transfer the message to the service provider through the user agent. The message may indicate an error, or will include (at least) an authentication assertion. The HTTP Redirect binding MUST NOT be used, as the response will typically exceed the URL length permitted by most user agents. 6. Service Provider grants or denies access to Principal In step 6, having received the response from the identity provider, the service provider can respond to the principal's user agent with its own error, or can establish its own security context for the principal and return the requested resource. Note that an identity provider can initiate this profile at step 5 and issue a <Response> message to a service provider without the preceding steps.

432 433 434 435 436 437 438 439 440

4.1.3 Profile Description

If the profile is initiated by the service provider, start with Section 4.1.3.1. If initiated by the identity provider, start with Section 4.1.3.5. In the descriptions below, the following are referred to: Single Sign-On Service This is the authentication request protocol endpoint at the identity provider to which the <AuthnRequest> message (or artifact representing it) is delivered by the user agent. Assertion Consumer Service This is the authentication request protocol endpoint at the service provider to which the <Response> message (or artifact representing it) is delivered by the user agent.

441 442 443 444 445 446 447

4.1.3.1 HTTP Request to Service Provider

If the first access is to the service provider, an arbitrary request for a resource can initiate the profile. There are no restrictions on the form of the request. The service provider is free to use any means it wishes to associate the subsequent interactions with the original request. Each of the bindings provide a RelayState mechanism that the service provider MAY use to associate the profile exchange with the original request. The service provider SHOULD reveal as little of the request as possible in the RelayState value unless the use of the profile does not require such privacy measures.

448 449 450 451 452 453 454

4.1.3.2 Service Provider Determines Identity Provider

This step is implementation-dependent. The service provider MAY use the SAML identity provider discovery profile, described in Section 4.3. The service provider MAY also choose to redirect the user agent to another service that is able to determine an appropriate identity provider. In such a case, the service provider may issue an <AuthnRequest> (as in the next step) to this service to be relayed to the identity provider, or it may rely on the intermediary service to issue an <AuthnRequest> message on its behalf.

455 456 457 458 459 460

4.1.3.3 <AuthnRequest> Is Issued by Service Provider to Identity Provider

Once an identity provider is selected, the location of its single sign-on service is determined, based on the SAML binding chosen by the service provider for sending the <AuthnRequest>. Metadata (as in [SAMLMeta]) MAY be used for this purpose. In response to an HTTP request by the user agent, an HTTP response is returned containing an <AuthnRequest> message or an artifact, depending on the SAML binding used, to be delivered to the identity provider's single sign-on service.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 16 of 66

461 462 463 464 465 466 467 468 469 470 471 472 473 474

The exact format of this HTTP response and the subsequent HTTP request to the single sign-on service is defined by the SAML binding used. Profile-specific rules for the contents of the <AuthnRequest> message are included in Section 4.1.4.1. If the HTTP Redirect or POST binding is used, the <AuthnRequest> message is delivered directly to the identity provider in this step. If the HTTP Artifact binding is used, the Artifact Resolution profile defined in Section 5 is used by the identity provider, which makes a callback to the service provider to retrieve the <AuthnRequest> message, using, for example, the SOAP binding. It is RECOMMENDED that the HTTP exchanges in this step be made over either SSL 3.0 [SSL3] or TLS 1.0 [RFC2246] to maintain confidentiality and message integrity. The <AuthnRequest> message MAY be signed, if authentication of the request issuer is required. The HTTP Artifact binding, if used, also provides for an alternate means of authenticating the request issuer when the artifact is dereferenced. The identity provider MUST process the <AuthnRequest> message as described in [SAMLCore]. This may constrain the subsequent interactions with the user agent, for example if the IsPassive attribute is included.

475 476 477 478 479 480 481 482

4.1.3.4 Identity Provider Identifies Principal

At any time during the previous step or subsequent to it, the identity provider MUST establish the identity of the principal (unless it returns an error to the service provider). The ForceAuthn <AuthnRequest> attribute, if present with a value of true, obligates the identity provider to freshly establish this identity, rather than relying on an existing session it may have with the principal. Otherwise, and in all other respects, the identity provider may use any means to authenticate the user agent, subject to any requirements included in the <AuthnRequest> in the form of the <RequestedAuthnContext> element.

483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502

4.1.3.5 Identity Provider Issues <Response> to Service Provider

Regardless of the success or failure of the <AuthnRequest>, the identity provider SHOULD produce an HTTP response to the user agent containing a <Response> message or an artifact, depending on the SAML binding used, to be delivered to the service provider's assertion consumer service. The exact format of this HTTP response and the subsequent HTTP request to the assertion consumer service is defined by the SAML binding used. Profile-specific rules on the contents of the <Response> are included in Section 4.1.4.2. If the HTTP POST binding is used, the <Response> message is delivered directly to the service provider in this step. If the HTTP Artifact binding is used, the Artifact Resolution profile defined in Section 5 is used by the service provider, which makes a callback to the identity provider to retrieve the <Response> message, using for example the SOAP binding. The location of the assertion consumer service MAY be determined using metadata (as in [SAMLMeta]). The identity provider MUST have some means to establish that this location is in fact controlled by the service provider. A service provider MAY indicate the SAML binding and the specific assertion consumer service to use in its <AuthnRequest> and the identity provider MUST honor them if it can. It is RECOMMENDED that the HTTP requests in this step be made over either SSL 3.0 [SSL3] or TLS 1.0 [RFC2246] to maintain confidentiality and message integrity. The <Assertion> element(s) in the <Response> MUST be signed, if the HTTP POST binding is used, and MAY be signed if the HTTPArtifact binding is used. The service provider MUST process the <Response> message and any enclosed <Assertion> elements as described in [SAMLCore].

503 504 505

4.1.3.6 Service Provider Grants or Denies Access to User Agent

To complete the profile, the service provider processes the <Response> and <Assertion>(s) and grants or denies access to the resource. The service provider MAY establish a security context with the
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 17 of 66

506 507 508

user agent using any session mechanism it chooses. Any subsequent use of the <Assertion>(s) provided are at the discretion of the service provider and other relying parties, subject to any restrictions on use contained within them.

509 510 511 512 513

4.1.4 Use of Authentication Request Protocol

This profile is based on the Authentication Request protocol defined in [SAMLCore]. In the nomenclature of actors enumerated in Section 3.4 of that document, the service provider is the request issuer and the relying party, and the principal is the presenter, requested subject, and confirming entity. There may be additional relying parties or confirming entities at the discretion of the identity provider (see below).

514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536

4.1.4.1 <AuthnRequest> Usage

A service provider MAY include any message content described in [SAMLCore], Section 3.4.1. All processing rules are as defined in [SAMLCore]. The <Issuer> element MUST be present and MUST contain the unique identifier of the requesting service provider; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity. If the identity provider cannot or will not satisfy the request, it MUST respond with a <Response> message containing an appropriate error status code or codes. If the service provider wishes to permit the identity provider to establish a new identifier for the principal if none exists, it MUST include a <NameIDPolicy> element with the AllowCreate attribute set to "true". Otherwise, only a principal for whom the identity provider has previously established an identifier usable by the service provider can be authenticated successfully. Note that the service provider MAY include a <Subject> element in the request that names the actual identity about which it wishes to receive an assertion. This element MUST NOT contain any <SubjectConfirmation> elements. If the identity provider does not recognize the principal as that identity, then it MUST respond with a <Response> message containing an error status and no assertions. The <AuthnRequest> message MAY be signed (as directed by the SAML binding used). If the HTTP Artifact binding is used, authentication of the parties is OPTIONAL and any mechanism permitted by the binding MAY be used. Note that if the <AuthnRequest> is not authenticated and/or integrity protected, the information in it MUST NOT be trusted except as advisory. Whether the request is signed or not, the identity provider MUST ensure that any <AssertionConsumerServiceURL> or <AssertionConsumerServiceIndex> elements in the request are verified as belonging to the service provider to whom the response will be sent. Failure to do so can result in a man-in-the-middle attack.

537 538 539 540 541 542 543 544 545 546 547 548

4.1.4.2 <Response> Usage

If the identity provider wishes to return an error, it MUST NOT include any assertions in the <Response> message. Otherwise, if the request is successful (or if the response is not associated with a request), the <Response> element MUST conform to the following:

The <Issuer> element MAY be omitted, but if present it MUST contain the unique identifier of the issuing identity provider; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity. It MUST contain at least one <Assertion>. Each assertion's <Issuer> element MUST contain the unique identifier of the issuing identity provider; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity. The set of one or more assertions MUST contain at least one <AuthnStatement> that reflects the authentication of the principal to the identity provider.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 18 of 66

549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572

At least one assertion containing an <AuthnStatement> MUST contain a <Subject> element with at least one <SubjectConfirmation> element containing a Method of urn:oasis:names:tc:SAML:2.0:cm:bearer. If the identity provider supports the Single Logout profile, defined in Section 4.4, any such authentication statements MUST include a SessionIndex attribute to enable per-session logout requests by the service provider. The bearer <SubjectConfirmation> element described above MUST contain a <SubjectConfirmationData> element that contains a Recipient attribute containing the service provider's assertion consumer service URL and a NotOnOrAfter attribute that limits the window during which the assertion can be delivered. It MAY contain an Address attribute limiting the client address from which the assertion can be delivered. It MUST NOT contain a NotBefore attribute. If the containing message is in response to an <AuthnRequest>, then the InResponseTo attribute MUST match the request's ID. Other statements and confirmation methods MAY be included in the assertion(s) at the discretion of the identity provider. In particular, <AttributeStatement> elements MAY be included. The <AuthnRequest> MAY contain an AttributeConsumingServiceIndex XML attribute referencing information about desired or required attributes in [SAMLMeta]. The identity provider MAY ignore this, or send other attributes at its discretion. The assertion(s) containing a bearer subject confirmation MUST contain an <AudienceRestriction> including the service provider's unique identifier as an <Audience>. Other conditions (and other <Audience> elements) MAY be included as requested by the service provider or at the discretion of the identity provider. (Of course, all such conditions MUST be understood by and accepted by the service provider in order for the assertion to be considered valid.) The identity provider is NOT obligated to honor the requested set of <Conditions> in the <AuthnRequest>, if any.

573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591

4.1.4.3 <Response> Message Processing Rules

Regardless of the SAML binding used, the service provider MUST do the following:

Verify any signatures present on the assertion(s) or the response Verify that the Recipient attribute in any bearer <SubjectConfirmationData> matches the assertion consumer service URL to which the <Response> or artifact was delivered Verify that the NotOnOrAfter attribute in any bearer <SubjectConfirmationData> has not passed, subject to allowable clock skew between the providers Verify that the InResponseTo attribute in the bearer <SubjectConfirmationData> equals the ID of its original <AuthnRequest> message, unless the response is unsolicited (see Section 4.1.5 ), in which case the attribute MUST NOT be present Verify that any assertions relied upon are valid in other respects

If any bearer <SubjectConfirmationData> includes an Address attribute, the service provider MAY check the user agent's client address against it. Any assertion which is not valid, or whose subject confirmation requirements cannot be met SHOULD be discarded and SHOULD NOT be used to establish a security context for the principal. If an <AuthnStatement> used to establish a security context for the principal contains a SessionNotOnOrAfter attribute, the security context SHOULD be discarded once this time is reached, unless the service provider reestablishes the principal's identity by repeating the use of this profile.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 19 of 66

592 593 594 595 596 597 598

4.1.4.4 Artifact-Specific <Response> Message Processing Rules

If the HTTP Artifact binding is used to deliver the <Response>, the dereferencing of the artifact using the Artifact Resolution profile MUST be mutually authenticated, integrity protected, and confidential. The identity provider MUST ensure that only the service provider to whom the <Response> message has been issued is given the message as the result of an <ArtifactResolve> request. Either the SAML binding used to dereference the artifact or message signatures can be used to authenticate the parties and protect the messages.

599 600 601 602 603 604

4.1.4.5 POST-Specific Processing Rules

If the HTTP POST binding is used to deliver the <Response>, the enclosed assertion(s) MUST be signed. The service provider MUST ensure that bearer assertions are not replayed, by maintaining the set of used ID values for the length of time for which the assertion would be considered valid based on the NotOnOrAfter attribute in the <SubjectConfirmationData>.

605 606 607 608 609 610 611 612 613 614 615 616

4.1.5 Unsolicited Responses

An identity provider MAY initiate this profile by delivering an unsolicited <Response> message to a service provider. An unsolicited <Response> MUST NOT contain an InResponseTo attribute, nor should any bearer <SubjectConfirmationData> elements contain one. If metadata as specified in [SAMLMeta] is used, the <Response> or artifact SHOULD be delivered to the <md:AssertionConsumerService> endpoint of the service provider designated as the default. Of special mention is that the identity provider MAY include a binding-specific "RelayState" parameter that indicates, based on mutual agreement with the service provider, how to handle subsequent interactions with the user agent. This MAY be the URL of a resource at the service provider. The service provider SHOULD be prepared to handle unsolicited responses by designating a default location to send the user agent subsequent to processing a response successfully.

617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633

4.1.6 Use of Metadata

[SAMLMeta] defines an endpoint element, <md:SingleSignOnService>, to describe supported bindings and location(s) to which a service provider may send requests to an identity provider using this profile. The <md:IDPSSODescriptor> element's WantAuthnRequestsSigned attribute MAY be used by an identity provider to document a requirement that requests be signed. The <md:SPSSODescriptor> element's AuthnRequestsSigned attribute MAY be used by a service provider to document the intention to sign all of its requests. The providers MAY document the key(s) used to sign requests, responses, and assertions with <md:KeyDescriptor> elements with a use attribute of sign. When encrypting SAML elements, <md:KeyDescriptor> elements with a use attribute of encrypt MAY be used to document supported encryption algorithms and settings, and public keys used to receive bulk encryption keys. The indexed endpoint element <md:AssertionConsumerService> is used to describe supported bindings and location(s) to which an identity provider may send responses to a service provider using this profile. The index attribute is used to distinguish the possible endpoints that may be specified by reference in the <AuthnRequest> message. The isDefault attribute is used to specify the endpoint to use if not specified in a request.
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 20 of 66

634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650

The <md:SPSSODescriptor> element's WantAssertionsSigned attribute MAY be used by a service provider to document a requirement that assertions delivered with this profile be signed. This is in addition to any requirements for signing imposed by the use of a particular binding. Note that the identity provider is not obligated by this, but is being made aware of the likelihood that an unsigned assertion will be insufficient. If the request or response message is delivered using the HTTP Artifact binding, the artifact issuer MUST provide at least one <md:ArtifactResolutionService> endpoint element in its metadata. The <md:IDPSSODescriptor> MAY contain <md:NameIDFormat>, <md:AttributeProfile>, and <saml:Attribute> elements to indicate the general ability to support particular name identifier formats, attribute profiles, or specific attributes and values. The ability to support any such features during a given authentication exchange is dependent on policy and the discretion of the identity provider. The <md:SPSSODescriptor> element MAY also be used to document the service provider's need or desire for SAML attributes to be delivered along with authentication information. The actual inclusion of attributes is always at the discretion of the identity provider. One or more <md:AttributeConsumingService> elements MAY be included in its metadata, each with an index attribute to distinguish different services that MAY be specified by reference in the <AuthnRequest> message. The isDefault attribute is used to specify a default set of attribute requirements.

651 652 653 654 655 656 657 658 659 660 661 662 663 664 665

4.2 Enhanced Client or Proxy (ECP) Profile

An enhanced client or proxy (ECP) is a system entity that knows how to contact an appropriate identity provider, possibly in a context-dependent fashion, and also supports the Reverse SOAP (PAOS) binding [SAMLBind]. An example scenario enabled by this profile is as follows: A principal, wielding an ECP, uses it to either access a resource at a service provider, or access an identity provider such that the service provider and desired resource are understood or implicit. The principal authenticates (or has already authenticated) with the identity provider, which then produces an authentication assertion (possibly with input from the service provider). The service provider then consumes the assertion and subsequently establishes a security context for the principal. During this process, a name identifier might also be established between the providers for the principal, subject to the parameters of the interaction and the consent of the principal. This profile is based on the SAML Authentication Request protocol [SAMLCore] in conjunction with the PAOS binding. Note: The means by which a principal authenticates with an identity provider is outside of the scope of SAML.

666 667 668 669 670 671 672 673

4.2.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp (this is also the target namespace assigned in the corresponding ECP profile schema document [SAMLECP-xsd]) Contact information: [email protected] SAML Confirmation Method Identifiers: The SAML V2.0 "bearer" confirmation method identifier, urn:oasis:names:tc:SAML:2.0:cm:bearer, is used by this profile. Description: Given below. Updates: None.

674 675

4.2.2 Profile Overview

As introduced above, the ECP profile specifies interactions between enhanced clients or proxies and
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 21 of 66

676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710

service providers and identity providers. It is a specific application of the SSO profile described in Section 4.1. If not otherwise specified by this profile, and if not specific to the use of browser-based bindings, the rules specified in Section 4.1 MUST be observed. An ECP is a client or proxy that satisfies the following two conditions: It has, or knows how to obtain, information about the identity provider that the principal associated with the ECP wishes to use, in the context of an interaction with a service provider. This allows a service provider to make an authentication request to the ECP without the need to know or discover the appropriate identity provider (effectively bypassing step 2 of the SSO profile in Section 4.1). It is able to use a reverse SOAP (PAOS) binding as profiled here for an authentication request and response. This enables a service provider to obtain an authentication assertion via an ECP that is not otherwise (i.e. outside of the context of the immediate interaction) necessarily directly addressable nor continuously available. It also leverages the benefits of SOAP while using a well-defined exchange pattern and profile to enable interoperability. The ECP may be viewed as a SOAP intermediary between the service provider and the identity provider. An enhanced client may be a browser or some other user agent that supports the functionality described in this profile. An enhanced proxy is an HTTP proxy (for example a WAP gateway) that emulates an enhanced client. Unless stated otherwise, all statements referring to enhanced clients are to be understood as statements about both enhanced clients as well as enhanced client proxies. Since the enhanced client sends and receives messages in the body of HTTP requests and responses, it has no arbitrary restrictions on the size of the protocol messages. This profile leverages the Reverse SOAP (PAOS) binding [SAMLBind]. Implementers of this profile MUST follow the rules for HTTP indications of PAOS support specified in that binding, in addition to those specified in this profile. This profile utilizes a PAOS SOAP header block conveyed between the HTTP responder and the ECP but does not define PAOS itself. The SAML PAOS binding specification [SAMLBind] is normative in the event of questions regarding PAOS. This profile defines SOAP header blocks that accompany the SAML requests and responses. These header blocks may be composed with other SOAP header blocks as necessary, for example with the SOAP Message Security header block to add security features if needed, for example a digital signature applied to the authentication request. Two sets of request/response SOAP header blocks are used: PAOS header blocks for generic PAOS information and ECP profile-specific header blocks to convey information specific to ECP profile functionality. Figure 2 shows the processing flow in the ECP profile.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 22 of 66

Enhanced Client or Proxy (ECP)

Service Provider

Identity Provider

1. ECP attempts access of some resource at the Serv ice Prov ider v ia an HTTP request w ith HTTP headers denoting the request as being from an ECP

Do I have a security context for this ECP and Principal? Hm, no, so I'm going to establish one...

2. <AuthnRequest> message issued by Serv ice Prov ider using PAOS binding (i.e. HTTP 200 OK response)

3. ECP determines Identity Prov ider to use (methods v ary , details not show n)

4. ECP issues <AuthnRequest> to the identity prov ider using SAML SOAP binding

5. Identity Prov ider identifies Principal (methods v ary , details not show n)

6. Identity Prov ider issues <Response> message to ECP using SAML SOAP binding, targeted at serv ice prov ider 7. ECP conv ey s <Response> message to serv ice prov ider using PAOS binding (i.e.. HTTP POST) 8. Based on the Identity Prov ider's response identify ing (or not) the Principal, the Serv ice Prov ider either returns the resource, or an (HTTP) error, in an HTTP response (e.g. HTTP 200 OK)

Figure 2

711 712 713 714 715 716 717 718 719 720 721 722

Figure 2 illustrates the basic template for SSO using an ECP. The following steps are described by the profile. Within an individual step, there may be one or more actual message exchanges depending on the binding used for that step and other implementation-dependent behavior. 1. ECP issues HTTP Request to Service Provider In step 1, the Principal, via an ECP, makes an HTTP request for a secured resource at a service provider, where the service provider does not have an established security context for the ECP and Principal. 2. Service Provider issues <AuthnRequest> to ECP In step 2, the service provider issues an <AuthnRequest> message to the ECP, which is to be delivered by the ECP to the appropriate identity provider. The Reverse SOAP (PAOS) binding [SAMLBind] is used here. 3. ECP Determines Identity Provider
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 23 of 66

723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746

In step 3, the ECP obtains the location of an endpoint at an identity provider for the authentication request protocol that supports its preferred binding. The means by which this is accomplished is implementation-dependent. The ECP MAY use the SAML identity provider discovery profile described in Section 4.3. 4. ECP conveys <AuthnRequest> to Identity Provider In step 4, the ECP conveys the <AuthnRequest> to the identity provider identified in step 3 using a modified form of the SAML SOAP binding [SAMLBind] with the additional allowance that the identity provider may exchange arbitrary HTTP messages with the ECP before responding to the SAML request. 5. Identity Provider identifies Principal In step 5, the Principal is identified by the identity provider by some means outside the scope of this profile. This may require a new act of authentication, or it may reuse an existing authenticated session. 6. Identity Provider issues <Response> to ECP, targeted at Service Provider In step 6, the identity provider issues a <Response> message, using the SAML SOAP binding, to be delivered by the ECP to the service provider. The message may indicate an error, or will include (at least) an authentication assertion. 7. ECP conveys <Response> message to Service Provider In step 7, the ECP conveys the <Response> message to the service provider using the PAOS binding. 8. Service Provider grants or denies access to Principal In step 8, having received the <Response> message from the identity provider, the service provider either establishes its own security context for the principal and return the requested resource, or responds to the principal's ECP with an error.

747 748

4.2.3 Profile Description

The following sections provide detailed definitions of the individual steps.

749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764

4.2.3.1 ECP issues HTTP Request to Service Provider

The ECP sends an HTTP request to a service provider, specifying some resource. This HTTP request MUST conform to the PAOS binding, which means it must include the following HTTP header fields: 1. The HTTP Accept Header field indicating the ability to accept the MIME type application/vnd.paos+xml 2. The HTTP PAOS Header field specifying the PAOS version with urn:liberty:paos:2003-08 at minimum. 3. Furthermore, support for this profile MUST be specified in the HTTP PAOS Header field as a service value, with the value urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp. This value should correspond to the service attribute in the PAOS Request SOAP header block For example, a user agent may request a page from a service provider as follows:
GET /index HTTP/1.1 Host: identity-service.example.com Accept: text/html; application/vnd.paos+xml PAOS: ver='urn:liberty:paos:2003-08' ; 'urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp'

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 24 of 66

765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785

4.2.3.2 Service Provider Issues <AuthnRequest> to ECP

When the service provider requires a security context for the principal before allowing access to the specified resource, that is, before providing a service or data, it can respond to the HTTP request using the PAOS binding with an <AuthnRequest> message in the HTTP response. The service provider will issue an HTTP 200 OK response to the ECP containing a single SOAP envelope. The SOAP envelope MUST contain: 1. An <AuthnRequest> element in the SOAP body, intended for the ultimate SOAP recipient, the identity provider. 2. A PAOS SOAP header block targeted at the ECP using the SOAP actor value of http://schemas.xmlsoap.org/soap/actor/next. This header block provides control information such as the URL to which to send the response in this solicit-response message exchange pattern. 3. An ECP profile-specific Request SOAP header block targeted at the ECP using the SOAP actor http://schemas.xmlsoap.org/soap/actor/next. The ECP Request header block defines information related to the authentication request that the ECP may need to process it, such as a list of identity providers acceptable to the service provider, whether the ECP may interact with the principal through the client, and the service provider's human-readable name that may be displayed to the principal. The SOAP envelope MAY contain an ECP RelayState SOAP header block targeted at the ECP using the SOAP actor value of http://schemas.xmlsoap.org/soap/actor/next. The header contains state information to be returned by the ECP along with the SAML response.

786 787

4.2.3.3 ECP Determines Identity Provider

The ECP will determine which identity provider is appropriate and route the SOAP message appropriately.

788 789 790 791 792 793 794 795 796 797 798 799

4.2.3.4 ECP issues <AuthnRequest> to Identity Provider

The ECP MUST remove the PAOS, ECP RelayState, and ECP Request header blocks before passing the <AuthnRequest> message on to the identity provider, using a modified form of the SAML SOAP binding. The SAML request is submitted via SOAP in the usual fashion, but the identity provider MAY respond to the ECP's HTTP request with an HTTP response containing, for example, an HTML login form or some other presentation-oriented response. A sequence of HTTP exchanges MAY take place, but ultimately the identity provider MUST complete the SAML SOAP exchange and return a SAML response via the SOAP binding. Note that the <AuthnRequest> element may itself be signed by the service provider. In this and other respects, the message rules specified in the browser SSO profile in Section 4.1.4.1 MUST be followed. Prior to or subsequent to this step, the identity provider MUST establish the identity of the principal by some means, or it MUST return an error <Response>, as described in Section 4.2.3.6 below.

800 801 802 803 804 805 806 807

4.2.3.5 Identity Provider Identifies Principal

At any time during the previous step or subsequent to it, the identity provider MUST establish the identity of the principal (unless it returns an error to the service provider). The ForceAuthn <AuthnRequest> attribute, if present with a value of true, obligates the identity provider to freshly establish this identity, rather than relying on an existing session it may have with the principal. Otherwise, and in all other respects, the identity provider may use any means to authenticate the user agent, subject to any requirements included in the <AuthnRequest> in the form of the <RequestedAuthnContext> element.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 25 of 66

808 809 810 811 812 813 814 815

4.2.3.6 Identity Provider issues <Response> to ECP, targeted at service provider

The identity provider returns a SAML <Response> message (or SOAP fault) when presented with an authentication request, after having established the identity of the principal. The SAML response is conveyed using the SAML SOAP binding in a SOAP message with a <Response> element in the SOAP body, intended for the service provider as the ultimate SOAP receiver. The rules for the response specified in the browser SSO profile in Section 4.1.4.2 MUST be followed. The identity provider's response message MUST contain a profile-specific ECP Response SOAP header block, and MAY contain an ECP RelayState header block, both targeted at the ECP.

816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833

4.2.3.7 ECP Conveys <Response> Message to Service Provider

The ECP removes the header block(s), and MAY add a PAOS Response SOAP header block and an ECP RelayState header block before forwarding the SOAP response to the service provider using the PAOS binding. The <paos:Response> SOAP header block in the response to the service provider is generally used to correlate this response to an earlier request from the service provider. In this profile, the correlation refToMessageID attribute is not required since the SAML <Response> element's InResponseTo attribute may be used for this purpose, but if the <paos:Request> SOAP Header block had a messageID then the <paos:Response> SOAP header block MUST be used. The <ecp:RelayState> header block value is typically provided by the service provider to the ECP with its request, but if the identity provider is producing an unsolicited response (without having received a corresponding SAML request), then it MAY include a RelayState header block that indicates, based on mutual agreement with the service provider, how to handle subsequent interactions with the ECP. This MAY be the URL of a resource at the service provider. If the service provider included an <ecp:RelayState> SOAP header block in its request to the ECP, or if the identity provider included an <ecp:RelayState> SOAP header block with its response, then the ECP MUST include an identical header block with the SAML response sent to the service provider. The service provider's value for this header block (if any) MUST take precedence.

834 835 836 837 838 839

4.2.3.8 Service Provider Grants or Denies Access to Principal

Once the service provider has received the SAML response in an HTTP request (in a SOAP envelope using PAOS), it may respond with the service data in the HTTP response. In consuming the response, the rules specified in the browser SSO profile in Section 4.1.4.3 and 4.1.4.5 MUST be followed. That is, the same processing rules used when receiving the <Response> with the HTTP POST binding apply to the use of PAOS.

840 841 842 843 844 845 846 847 848 849 850 851 852 853

4.2.4 ECP Profile Schema Usage

The ECP Profile XML schema [SAMLECP-xsd] defines the SOAP Request/Response header blocks used by this profile. Following is a complete listing of this schema document.
<schema targetNamespace="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" elementFormDefault="unqualified" attributeFormDefault="unqualified" blockDefault="substitution" version="2.0">

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 26 of 66

854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899

<import namespace="urn:oasis:names:tc:SAML:2.0:protocol" schemaLocation="saml-schema-protocol-2.0.xsd"/> <import namespace="urn:oasis:names:tc:SAML:2.0:assertion" schemaLocation="saml-schema-assertion-2.0.xsd"/> <import namespace="http://schemas.xmlsoap.org/soap/envelope/" schemaLocation="http://schemas.xmlsoap.org/soap/envelope/"/> <annotation> <documentation> Document identifier: saml-schema-ecp-2.0 Location: http://docs.oasis-open.org/security/saml/v2.0/ Revision history: V2.0 (March, 2005): Custom schema for ECP profile, first published in SAML 2.0. </documentation> </annotation> <element name="Request" type="ecp:RequestType"/> <complexType name="RequestType"> <sequence> <element ref="saml:Issuer"/> <element ref="samlp:IDPList" minOccurs="0"/> </sequence> <attribute ref="S:mustUnderstand" use="required"/> <attribute ref="S:actor" use="required"/> <attribute name="ProviderName" type="string" use="optional"/> <attribute name="IsPassive" type="boolean" use="optional"/> </complexType> <element name="Response" type="ecp:ResponseType"/> <complexType name="ResponseType"> <attribute ref="S:mustUnderstand" use="required"/> <attribute ref="S:actor" use="required"/> <attribute name="AssertionConsumerServiceURL" type="anyURI" use="required"/> </complexType> <element name="RelayState" type="ecp:RelayStateType"/> <complexType name="RelayStateType"> <simpleContent> <extension base="string"> <attribute ref="S:mustUnderstand" use="required"/> <attribute ref="S:actor" use="required"/> </extension> </simpleContent> </complexType> </schema>

The following sections describe how these XML constructs are to be used.

900 901 902 903 904 905 906 907 908 909 910 911

4.2.4.1 PAOS Request Header Block: SP to ECP

The PAOS Request header block signals the use of PAOS processing and includes the following attributes: responseConsumerURL [Required] Specifies where the ECP is to send an error response. Also used to verify the correctness of the identity provider's response, by cross checking this location against the AssertionServiceConsumerURL in the ECP response header block. This value MUST be the same as the AssertionServiceConsumerURL (or the URL referenced in metadata) conveyed in the <AuthnRequest>. service [Required] Indicates that the PAOS service being used is this SAML authentication profile. The value MUST be urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp.
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 27 of 66

912 913 914 915 916 917 918 919 920 921

SOAP-ENV:mustUnderstand [Required] The value MUST be 1 (true). A SOAP fault MUST be generated if the PAOS header block is not understood. SOAP-ENV:actor [Required] The value MUST be http://schemas.xmlsoap.org/soap/actor/next. messageID [Optional] Allows optional response correlation. It MAY be used in this profile, but is NOT required, since this functionality is provided by the SAML protocol layer, via the ID attribute in the <AuthnRequest> and the InResponseTo attribute in the <Response>. The PAOS Request SOAP header block has no element content.

922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943

4.2.4.2 ECP Request Header Block: SP to ECP

The ECP Request SOAP header block is used to convey information needed by the ECP to process the authentication request. It is mandatory and its presence signals the use of this profile. It contains the following elements and attributes: SOAP-ENV:mustUnderstand [Required] The value MUST be 1 (true). A SOAP fault MUST be generated if the ECP header block is not understood. SOAP-ENV:actor [Required] The value MUST be http://schemas.xmlsoap.org/soap/actor/next. ProviderName [Optional] A human-readable name for the requesting service provider. IsPassive [Optional] A boolean value. If true, the identity provider and the client itself MUST NOT take control of the user interface from the request issuer and interact with the principal in a noticeable fashion. If a value is not provided, the default is true. <saml:Issuer> [Required] This element MUST contain the unique identifier of the requesting service provider; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameidformat:entity. <samlp:IDPList> [Optional] Optional list of identity providers that the service provider recognizes and from which the ECP may choose to service the request. See [SAMLCore] for details on the content of this element.

944 945 946 947 948 949 950

4.2.4.3 ECP RelayState Header Block: SP to ECP

The ECP RelayState SOAP header block is used to convey state information from the service provider that it will need later when processing the response from the ECP. It is optional, but if used, the ECP MUST include an identical header block in the response in step 5. It contains the following attributes: SOAP-ENV:mustUnderstand [Required] The value MUST be 1 (true). A SOAP fault MUST be generated if the header block is not understood. SOAP-ENV:actor [Required]
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 28 of 66

951 952 953 954 955 956 957

The value MUST be http://schemas.xmlsoap.org/soap/actor/next. The content of the header block element is a string containing state information created by the requester. If provided, the ECP MUST include the same value in a RelayState header block when responding to the service provider in step 5. The string value MUST NOT exceed 80 bytes in length and SHOULD be integrity protected by the requester independent of any other protections that may or may not exist during message transmission. The following is an example of the SOAP authentication request from the service provider to the ECP:
<SOAP-ENV:Envelope xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <paos:Request xmlns:paos="urn:liberty:paos:2003-08" responseConsumerURL="http://identity-service.example.com/abc" messageID="6c3a4f8b9c2d" SOAPENV:actor="http://schemas.xmlsoap.org/soap/actor/next" SOAPENV:mustUnderstand="1" service="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"> </paos:Request> <ecp:Request xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" SOAP-ENV:mustUnderstand="1" SOAPENV:actor="http://schemas.xmlsoap.org/soap/actor/next" ProviderName="Service Provider X" IsPassive="0"> <saml:Issuer>https://ServiceProvider.example.com</saml:Issuer> <samlp:IDPList> <samlp:IDPEntry ProviderID="https://IdentityProvider.example.com" Name="Identity Provider X" Loc="https://IdentityProvider.example.com/saml2/sso" </samlp:IDPEntry> <samlp:GetComplete> https://ServiceProvider.example.com/idplist?id=604be136-fe91-441e-afb8 </samlp:GetComplete> </samlp:IDPList> </ecp:Request> <ecp:RelayState xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" SOAP-ENV:mustUnderstand="1" SOAPENV:actor="http://schemas.xmlsoap.org/soap/actor/next"> ... </ecp:RelayState> </SOAP-ENV:Header> <SOAP-ENV:Body> <samlp:AuthnRequest> ... </samlp:AuthnRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007

As noted above, the PAOS and ECP header blocks are removed from the SOAP message by the ECP before the authentication request is forwarded to the identity provider. An example authentication request from the ECP to the identity provider is as follows:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" <SOAP-ENV:Body> <samlp:AuthnRequest> ... </samlp:AuthnRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

4.2.4.4 ECP Response Header Block: IdP to ECP

The ECP response SOAP header block MUST be used on the response from the identity provider to the ECP. It contains the following attributes: SOAP-ENV:mustUnderstand [Required]
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 29 of 66

1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053

The value MUST be 1 (true). A SOAP fault MUST be generated if the ECP header block is not understood. SOAP-ENV:actor [Required] The value MUST be http://schemas.xmlsoap.org/soap/actor/next. AssertionConsumerServiceURL [Required] Set by the identity provider based on the <AuthnRequest> message or the service provider's metadata obtained by the identity provider. The ECP MUST confirm that this value corresponds to the value the ECP obtained in the responseConsumerURL in the PAOS Request SOAP header block it received from the service provider. Since the responseConsumerURL MAY be relative and the AssertionConsumerServiceURL is absolute, some processing/normalization may be required. This mechanism is used for security purposes to confirm the correct response destination. If the values do not match, then the ECP MUST generate a SOAP fault response to the service provider and MUST NOT return the SAML response. The ECP Response SOAP header has no element content. Following is an example of an IdP-to-ECP response.
<SOAP-ENV:Envelope xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <ecp:Response SOAP-ENV:mustUnderstand="1" SOAPENV:actor="http://schemas.xmlsoap.org/soap/actor/next" AssertionConsumerServiceURL="https://ServiceProvider.example.com/ecp_assertion _consumer"/> </SOAP-ENV:Header> <SOAP-ENV:Body> <samlp:Response> ... </samlp:Response> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

4.2.4.5 PAOS Response Header Block: ECP to SP

The PAOS Response header block includes the following attributes: SOAP-ENV:mustUnderstand [Required] The value MUST be 1 (true). A SOAP fault MUST be generated if the PAOS header block is not understood. SOAP-ENV:actor [Required] The value MUST be http://schemas.xmlsoap.org/soap/actor/next. refToMessageID [Optional] Allows correlation with the PAOS request. This optional attribute (and the header block as a whole) MUST be added by the ECP if the corresponding PAOS request specified the messageID attribute. Note that the equivalent functionality is provided in SAML using <AuthnRequest> and <Response> correlation. The PAOS Response SOAP header has no element content. Following is an example of an ECP-to-SP response.
<SOAP-ENV:Envelope xmlns:paos="urn:liberty:paos:2003-08"
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 30 of 66

1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <paos:Response refToMessageID="6c3a4f8b9c2d" SOAPENV:actor="http://schemas.xmlsoap.org/soap/actor/next/" SOAPENV:mustUnderstand="1"/> <ecp:RelayState xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" SOAP-ENV:mustUnderstand="1" SOAPENV:actor="http://schemas.xmlsoap.org/soap/actor/next"> ... </ecp:RelayState> </SOAP-ENV:Header> <SOAP-ENV:Body> <samlp:Response> ... </samlp:Response> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

4.2.5 Security Considerations

The <AuthnRequest> message SHOULD be signed. Per the rules specified by the browser SSO profile, the assertions enclosed in the <Response> MUST be signed. The delivery of the response in the SOAP envelope via PAOS is essentially analogous to the use of the HTTP POST binding and security countermeasures appropriate to that binding are used. The SOAP headers SHOULD be integrity protected, such as with SOAP Message Security or through the use of SSL/TLS over every HTTP exchange with the client. The service provider SHOULD be authenticated to the ECP, for example with server-side TLS authentication. The ECP SHOULD be authenticated to the identity provider, such as by maintaining an authenticated session. Any HTTP exchanges subsequent to the delivery of the <AuthnRequest> message and before the identity provider returns a <Response> MUST be securely associated with the original request.

1082 1083 1084 1085 1086 1087 1088 1089 1090 1091

4.3 Identity Provider Discovery Profile

This section defines a profile by which a service provider can discover which identity providers a principal is using with the Web Browser SSO profile. In deployments having more than one identity provider, service providers need a means to discover which identity provider(s) a principal uses. The discovery profile relies on a cookie that is written in a domain that is common between identity providers and service providers in a deployment. The domain that the deployment predetermines is known as the common domain in this profile, and the cookie containing the list of identity providers is known as the common domain cookie. Which entities host web servers in the common domain is a deployment issue and is outside the scope of this profile.

1092 1093 1094 1095 1096 1097 1098 1099 1100 1101

4.3.1 Common Domain Cookie

The name of the cookie MUST be "_saml_idp". The format of the cookie value MUST be a set of one or more base-64 encoded URI values separated by a single space character. Each URI is the unique identifier of an identity provider, as defined in Section 8.3.6 of [SAMLCore]. The final set of values is then URL encoded. The common domain cookie writing service (see below) SHOULD append the identity provider's unique identifier to the list. If the identifier is already present in the list, it MAY remove and append it. The intent is that the most recently established identity provider session is the last one in the list. The cookie MUST be set with a Path prefix of "/". The Domain MUST be set to ".[common-domain]" where [common-domain] is the common domain established within the deployment for use with this profile.
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 31 of 66

1102 1103 1104 1105

There MUST be a leading period. The cookie MUST be marked as secure. Cookie syntax should be in accordance with IETF RFC 2965 [RFC2965] or [NSCookie]. The cookie MAY be either session-only or persistent. This choice may be made within a deployment, but should apply uniformly to all identity providers in the deployment.

1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116

4.3.2 Setting the Common Domain Cookie

After the identity provider authenticates a principal, it MAY set the common domain cookie. The means by which the identity provider sets the cookie are implementation-specific so long as the cookie is successfully set with the parameters given above. One possible implementation strategy follows and should be considered non-normative. The identity provider may:

Have previously established a DNS and IP alias for itself in the common domain. Redirect the user agent to itself using the DNS alias using a URL specifying "https" as the URL scheme. The structure of the URL is private to the implementation and may include session information needed to identify the user agent. Set the cookie on the redirected user agent using the parameters specified above. Redirect the user agent back to itself, or, if appropriate, to the service provider.

1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132

4.3.3 Obtaining the Common Domain Cookie

When a service provider needs to discover which identity providers a principal uses, it invokes an exchange designed to present the common domain cookie to the service provider after it is read by an HTTP server in the common domain. If the HTTP server in the common domain is operated by the service provider or if other arrangements are in place, the service provider MAY utilize the HTTP server in the common domain to relay its <AuthnRequest> to the identity provider for an optimized single sign-on process. The specific means by which the service provider reads the cookie are implementation-specific so long as it is able to cause the user agent to present cookies that have been set with the parameters given in Section 4.3.1. One possible implementation strategy is described as follows and should be considered non-normative. Additionally, it may be sub-optimal for some applications.

Have previously established a DNS and IP alias for itself in the common domain. Redirect the user agent to itself using the DNS alias using a URL specifying "https" as the URL scheme. The structure of the URL is private to the implementation and may include session information needed to identify the user agent. Redirect the user agent back to itself, or, if appropriate, to the identity provider.

1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143

4.4 Single Logout Profile

Once a principal has authenticated to an identity provider, the authenticating entity may establish a session with the principal (typically by means of a cookie, URL re-writing, or some other implementationspecific means). The identity provider may subsequently issue assertions to service providers or other relying parties, based on this authentication event; a relying party may use this to establish its own session with the principal. In such a situation, the identity provider can act as a session authority and the relying parties as session participants. At some later time, the principal may wish to terminate his or her session either with an individual session participant, or with all session participants in a given session managed by the session authority. The former case is considered out of scope of this specification. The latter case, however, may be satisfied using this profile of the SAML Single Logout protocol ([SAMLCore] Section 3.7).

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 32 of 66

1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154

Note that a principal (or an administrator terminating a principal's session) may choose to terminate this "global" session either by contacting the session authority, or an individual session participant. Also note that an identity provider acting as a session authority may itself act as a session participant in situations in which it is the relying party for another identity provider's assertions regarding that principal. The profile allows the protocol to be combined with a synchronous binding, such as the SOAP binding, or with asynchronous "front-channel" bindings, such as the HTTP Redirect, POST, or Artifact bindings. A front-channel binding may be required, for example, in cases in which a principal's session state exists solely in a user agent in the form of a cookie and a direct interaction between the user agent and the session participant or session authority is required. As will be discussed below, session participants should if possible use a "front-channel" binding when initiating this profile to maximize the likelihood that the session authority can propagate the logout successfully to all participants.

1155 1156 1157 1158 1159

4.4.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:profiles:SSO:logout Contact information: [email protected] Description: Given below. Updates: None

1160 1161

4.4.2 Profile Overview

Figure 3 illustrates the basic template for achieving single logout:

Session Participant

Another Session Participant

User Agent

Identity Provider

1. <LogoutRequest> issued by Session Participant 2. Identity Provider determines session participants: Are any other
system entities participating in this session?

3. <LogoutRequest> issued to other session participant, if another session participant exists.

4. Principal's local session is terminated, and <LogoutResponse> returned.

5. <LogoutResponse> issued to originating Session Participant.

Steps 3 and 4 are repeated for each other session participant discovered in Step 2.

Figure 3

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 33 of 66

1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193

The grayed-out user agent illustrates that the message exchange may pass through the user agent or may be a direct exchange between system entities, depending on the SAML binding used to implement the profile. The following steps are described by the profile. Within an individual step, there may be one or more actual message exchanges depending on the binding used for that step and other implementationdependent behavior. 1. <LogoutRequest> issued by Session Participant to Identity Provider In step 1, the session participant initiates single logout and terminates a principal's session(s) by sending a <LogoutRequest> message to the identity provider from whom it received the corresponding authentication assertion. The request may be sent directly to the identity provider or sent indirectly through the user agent. 2. Identity Provider determines Session Participants In step 2, the identity provider uses the contents of the <LogoutRequest> message (or if initiating logout itself, some other mechanism) to determine the session(s) being terminated. If there are no other session participants, the profile proceeds with step 5. Otherwise, steps 3 and 4 are repeated for each session participant identified. 3. <LogoutRequest> issued by Identity Provider to Session Participant/Authority In step 3, the identity provider issues a <LogoutRequest> message to a session participant or session authority related to one or more of the session(s) being terminated. The request may be sent directly to the entity or sent indirectly through the user agent (if consistent with the form of the request in step 1). 4. Session Participant/Authority issues <LogoutResponse> to Identity Provider In step 4, a session participant or session authority terminates the principal's session(s) as directed by the request (if possible) and returns a <LogoutResponse> to the identity provider. The response may be returned directly to the identity provider or indirectly through the user agent (if consistent with the form of the request in step 3). 5. Identity Provider issues <LogoutResponse> to Session Participant In step 5, the identity provider issues a <LogoutResponse> message to the original requesting session participant. The response may be returned directly to the session participant or indirectly through the user agent (if consistent with the form of the request in step 1). Note that an identity provider (acting as session authority) can initiate this profile at step 2 and issue a <LogoutRequest> to all session participants, also skipping step 5.

1194 1195 1196 1197 1198 1199 1200

4.4.3 Profile Description

If the profile is initiated by a session participant, start with Section 4.4.3.1. If initiated by the identity provider, start with Section 4.4.3.2. In the descriptions below, the following is referred to: Single Logout Service This is the single logout protocol endpoint at an identity provider or session participant to which the <LogoutRequest> or <LogoutResponse> messages (or an artifact representing them) are delivered. The same or different endpoints MAY be used for requests and responses.

1201 1202 1203

4.4.3.1 <LogoutRequest> Issued by Session Participant to Identity Provider

If the logout profile is initiated by a session participant, it examines the authentication assertion(s) it received pertaining to the session(s) being terminated, and collects the SessionIndex value(s) it
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 34 of 66

1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237

received from the identity provider. If multiple identity providers are involved, then the profile MUST be repeated independently for each one. To initiate the profile, the session participant issues a <LogoutRequest> message to the identity provider's single logout service request endpoint containing one or more applicable <SessionIndex> elements. At least one element MUST be included. Metadata (as in [SAMLMeta]) MAY be used to determine the location of this endpoint and the bindings supported by the identity provider. Asynchronous Bindings (Front-Channel) The session participant SHOULD (if the principal's user agent is present) use an asynchronous binding, such as the HTTP Redirect, POST, or Artifact bindings [SAMLBind], to send the request to the identity provider through the user agent. The identity provider SHOULD then propagate any required logout messages to additional session participants as required using either a synchronous or asynchronous binding. The use of an asynchronous binding for the original request is preferred because it gives the identity provider the best chance of successfully propagating the logout to the other session participants during step 3. If the HTTP Redirect or POST binding is used, then the <LogoutRequest> message is delivered to the identity provider in this step. If the HTTP Artifact binding is used, the Artifact Resolution profile defined in Section 5 is used by the identity provider, which makes a callback to the session participant to retrieve the <LogoutRequest> message, using for example the SOAP binding. It is RECOMMENDED that the HTTP exchanges in this step be made over either SSL 3.0 [SSL3] or TLS 1.0 [RFC2246] to maintain confidentiality and message integrity. The <LogoutRequest> message MUST be signed if the HTTP POST or Redirect binding is used. The HTTP Artifact binding, if used, also provides for an alternate means of authenticating the request issuer when the artifact is dereferenced. Each of these bindings provide a RelayState mechanism that the session participant MAY use to associate the profile exchange with the original request. The session participant SHOULD reveal as little information as possible in the RelayState value unless the use of the profile does not require such privacy measures. Synchronous Bindings (Back-Channel) Alternatively, the session participant MAY use a synchronous binding, such as the SOAP binding [SAMLBind], to send the request directly to the identity provider. The identity provider SHOULD then propagate any required logout messages to additional session participants as required using a synchronous binding. The requester MUST authenticate itself to the identity provider, either by signing the <LogoutRequest> or using any other binding-supported mechanism. Profile-specific rules for the contents of the <LogoutRequest> message are included in Section 4.4.4.1.

1238 1239 1240 1241 1242 1243 1244

4.4.3.2 Identity Provider Determines Session Participants

If the logout profile is initiated by an identity provider, or upon receiving a valid <LogoutRequest> message, the identity provider processes the request as defined in [SAMLCore]. It MUST examine the identifier and <SessionIndex> elements and determine the set of sessions to be terminated. The identity provider then follows steps 3 and 4 for each entity participating in the session(s) being terminated, other than the original requesting session participant (if any), as described in Section 3.7.3.2 of [SAMLCore].

1245 1246 1247 1248 1249

4.4.3.3 <LogoutRequest> Issued by Identity Provider to Session Participant/Authority

To propagate the logout, the identity provider issues its own <LogoutRequest> to a session authority or participant in a session being terminated. The request is sent using a SAML binding consistent with the capability of the responder and the availability of the user agent at the identity provider.
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 35 of 66

1250 1251 1252 1253

In general, the binding with which the original request was received in step 1 does not dictate the binding that may be used in this step except that as noted in step 1, using a synchronous binding that bypasses the user agent constrains the identity provider to use a similar binding to propagate additional requests. Profile-specific rules for the contents of the <LogoutRequest> message are included in Section 4.4.4.1.

1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281

4.4.3.4 Session Participant/Authority Issues <LogoutResponse> to Identity Provider

The session participant/authority MUST process the <LogoutRequest> message as defined in [SAMLCore]. After processing the message or upon encountering an error, the entity MUST issue a <LogoutResponse> message containing an appropriate status code to the requesting identity provider to complete the SAML protocol exchange. Synchronous Bindings (Back-Channel) If the identity provider used a synchronous binding, such as the SOAP binding [SAMLBind], the response is returned directly to complete the synchronous communication. The responder MUST authenticate itself to the requesting identity provider, either by signing the <LogoutResponse> or using any other binding-supported mechanism. Asynchronous Bindings (Front-Channel) If the identity provider used an asynchronous binding, such as the HTTP Redirect, POST, or Artifact bindings [SAMLBind], then the <LogoutResponse> (or artifact) is returned through the user agent to the identity provider's single logout service response endpoint. Metadata (as in [SAMLMeta]) MAY be used to determine the location of this endpoint and the bindings supported by the identity provider. Any asynchronous binding supported by both entities MAY be used. If the HTTP Redirect or POST binding is used, then the <LogoutResponse> message is delivered to the identity provider in this step. If the HTTP Artifact binding is used, the Artifact Resolution profile defined in Section 5 is used by the identity provider, which makes a callback to the responding entity to retrieve the <LogoutResponse> message, using for example the SOAP binding. It is RECOMMENDED that the HTTP exchanges in this step be made over either SSL 3.0 [SSL3] or TLS 1.0 [RFC2246] to maintain confidentiality and message integrity. The <LogoutResponse> message MUST be signed if the HTTP POST or Redirect binding is used. The HTTP Artifact binding, if used, also provides for an alternate means of authenticating the response issuer when the artifact is dereferenced. Profile-specific rules for the contents of the <LogoutResponse> message are included in Section 4.4.4.2.

1282 1283 1284 1285 1286 1287 1288 1289 1290 1291

4.4.3.5 Identity Provider Issues <LogoutResponse> to Session Participant

After processing the original session participant's <LogoutRequest> as described in the previous steps the identity provider MUST respond to the original request with a <LogoutResponse> containing an appropriate status code to complete the SAML protocol exchange. The response is sent to the original session participant, using a SAML binding consistent with the binding used in the original request, the capability of the responder, and the availability of the user agent at the identity provider. Assuming an asynchronous binding was used in step 1, then any binding supported by both entities MAY be used. Profile-specific rules for the contents of the <LogoutResponse> message are included in Section 4.4.4.2.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 36 of 66

1292

4.4.4 Use of Single Logout Protocol

4.4.4.1 <LogoutRequest> Usage
The <Issuer> element MUST be present and MUST contain the unique identifier of the requesting entity; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameidformat:entity. The requester MUST authenticate itself to the responder and ensure message integrity, either by signing the message or using a binding-specific mechanism. The principal MUST be identified in the request using an identifier that strongly matches the identifier in the authentication assertion the requester issued or received regarding the session being terminated, per the matching rules defined in Section 3.3.4 of [SAMLCore]. If the requester is a session participant, it MUST include at least one <SessionIndex> element in the request. If the requester is a session authority (or acting on its behalf), then it MAY omit any such elements to indicate the termination of all of the principal's applicable sessions.

1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304

1305 1306 1307 1308 1309 1310

4.4.4.2 <LogoutResponse> Usage

The <Issuer> element MUST be present and MUST contain the unique identifier of the responding entity; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity. The responder MUST authenticate itself to the requester and ensure message integrity, either by signing the message or using a binding-specific mechanism.

1311 1312 1313 1314 1315 1316

4.4.5 Use of Metadata

[SAMLMeta] defines an endpoint element, <md:SingleLogoutService>, to describe supported bindings and location(s) to which an entity may send requests and responses using this profile. A requester, if encrypting the principal's identifier, can use the responder's <md:KeyDescriptor> element with a use attribute of encryption to determine an appropriate encryption algorithm and settings to use, along with a public key to use in delivering a bulk encryption key.

1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330

4.5 Name Identifier Management Profile

In the scenario supported by the Name Identifier Management profile, an identity provider has exchanged some form of persistent identifier for a principal with a service provider, allowing them to share a common identifier for some length of time. Subsequently, the identity provider may wish to notify the service provider of a change in the format and/or value that it will use to identify the same principal in the future. Alternatively the service provider may wish to attach its own "alias" for the principal in order to ensure that the identity provider will include it when communicating with it in the future about the principal. Finally, one of the providers may wish to inform the other that it will no longer issue or accept messages using a particular identifier. To implement these scenarios, a profile of the SAML Name Identifier Management protocol is used. The profile allows the protocol to be combined with a synchronous binding, such as the SOAP binding, or with asynchronous "front-channel" bindings, such as the HTTP Redirect, POST, or Artifact bindings. A front-channel binding may be required, for example, in cases in which direct interaction between the user agent and the responding provider is required in order to effect the change.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 37 of 66

1331 1332 1333 1334 1335

4.5.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:profiles:SSO:nameid-mgmt Contact information: [email protected] Description: Given below. Updates: None.

1336 1337

4.5.2 Profile Overview

Figure 4 illustrates the basic template for the name identifier management profile.

Requesting Provider

User Agent

Responding Provider

1. <ManageNameIDRequest> issued by requesting provider

2. <ManageNameIDResponse> returned by responding provider

Figure 4

1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353

The grayed-out user agent illustrates that the message exchange may pass through the user agent or may be a direct exchange between system entities, depending on the SAML binding used to implement the profile. The following steps are described by the profile. Within an individual step, there may be one or more actual message exchanges depending on the binding used for that step and other implementationdependent behavior. 1. <ManageNameIDRequest> issued by Requesting Identity/Service Provider In step 1, an identity or service provider initiates the profile by sending a <ManageNameIDRequest> message to another provider that it wishes to inform of a change. The request may be sent directly to the responding provider or sent indirectly through the user agent. 2. <ManageNameIDResponse> issued by Responding Identity/Service Provider In step 2, the responding provider (after processing the request) issues a <ManageNameIDResponse> message to the original requesting provider. The response may be returned directly to the requesting provider or indirectly through the user agent (if consistent with the form of the request in step 1).

1354 1355

4.5.3 Profile Description

In the descriptions below, the following is referred to:

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 38 of 66

1356 1357 1358 1359 1360

Name Identifier Management Service This is the name identifier management protocol endpoint at an identity or service provider to which the <ManageNameIDRequest> or <ManageNameIDResponse> messages (or an artifact representing them) are delivered. The same or different endpoints MAY be used for requests and responses.

1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388

4.5.3.1 <ManageNameIDRequest> Issued by Requesting Identity/Service Provider

To initiate the profile, the requesting provider issues a <ManageNameIDRequest> message to another provider's name identifier management service request endpoint. Metadata (as in [SAMLMeta]) MAY be used to determine the location of this endpoint and the bindings supported by the responding provider. Synchronous Bindings (Back-Channel) The requesting provider MAY use a synchronous binding, such as the SOAP binding [SAMLBind], to send the request directly to the other provider. The requester MUST authenticate itself to the other provider, either by signing the <ManageNameIDRequest> or using any other binding-supported mechanism. Asynchronous Bindings (Front-Channel) Alternatively, the requesting provider MAY (if the principal's user agent is present) use an asynchronous binding, such as the HTTP Redirect, POST, or Artifact bindings [SAMLBind] to send the request to the other provider through the user agent. If the HTTP Redirect or POST binding is used, then the <ManageNameIDRequest> message is delivered to the other provider in this step. If the HTTP Artifact binding is used, the Artifact Resolution profile defined in Section 5 is used by the other provider, which makes a callback to the requesting provider to retrieve the <ManageNameIDRequest> message, using for example the SOAP binding. It is RECOMMENDED that the HTTP exchanges in this step be made over either SSL 3.0 [SSL3] or TLS 1.0 [RFC2246] to maintain confidentiality and message integrity. The <ManageNameIDRequest> message MUST be signed if the HTTP POST or Redirect binding is used. The HTTP Artifact binding, if used, also provides for an alternate means of authenticating the request issuer when the artifact is dereferenced. Each of these bindings provide a RelayState mechanism that the requesting provider MAY use to associate the profile exchange with the original request. The requesting provider SHOULD reveal as little information as possible in the RelayState value unless the use of the profile does not require such privacy measures. Profile-specific rules for the contents of the <ManageNameIDRequest> message are included in Section 4.5.4.1.

1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400

4.5.3.2 <ManageNameIDResponse> issued by Responding Identity/Service Provider

The recipient MUST process the <ManageNameIDRequest> message as defined in [SAMLCore]. After processing the message or upon encountering an error, the recipient MUST issue a <ManageNameIDResponse> message containing an appropriate status code to the requesting provider to complete the SAML protocol exchange. Synchronous Bindings (Back-Channel) If the requesting provider used a synchronous binding, such as the SOAP binding [SAMLBind], the response is returned directly to complete the synchronous communication. The responder MUST authenticate itself to the requesting provider, either by signing the <ManageNameIDResponse> or using any other binding-supported mechanism. Asynchronous Bindings (Front-Channel)
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 39 of 66

1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417

If the requesting provider used an asynchronous binding, such as the HTTP Redirect, POST, or Artifact bindings [SAMLBind], then the <ManageNameIDResponse> (or artifact) is returned through the user agent to the requesting provider's name identifier management service response endpoint. Metadata (as in [SAMLMeta]) MAY be used to determine the location of this endpoint and the bindings supported by the requesting provider. Any binding supported by both entities MAY be used. If the HTTP Redirect or POST binding is used, then the <ManageNameIDResponse> message is delivered to the requesting provider in this step. If the HTTP Artifact binding is used, the Artifact Resolution profile defined in Section 5 is used by the requesting provider, which makes a callback to the responding provider to retrieve the <ManageNameIDResponse> message, using for example the SOAP binding. It is RECOMMENDED that the HTTP exchanges in this step be made over either SSL 3.0 [SSL3] or TLS 1.0 [RFC2246] to maintain confidentiality and message integrity. The <ManageNameIDResponse> message MUST be signed if the HTTP POST or Redirect binding is used. The HTTP Artifact binding, if used, also provides for an alternate means of authenticating the response issuer when the artifact is dereferenced. Profile-specific rules for the contents of the <ManageNameIDResponse> message are included in Section 4.5.4.2.

1418

4.5.4 Use of Name Identifier Management Protocol

4.5.4.1 <ManageNameIDRequest> Usage
The <Issuer> element MUST be present and MUST contain the unique identifier of the requesting entity; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameidformat:entity. The requester MUST authenticate itself to the responder and ensure message integrity, either by signing the message or using a binding-specific mechanism.

1419 1420 1421 1422 1423 1424

1425 1426 1427 1428 1429 1430

4.5.4.2 <ManageNameIDResponse> Usage

The <Issuer> element MUST be present and MUST contain the unique identifier of the responding entity; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity. The responder MUST authenticate itself to the requester and ensure message integrity, either by signing the message or using a binding-specific mechanism.

1431 1432 1433 1434 1435 1436

4.5.5 Use of Metadata

[SAMLMeta] defines an endpoint element, <md:ManageNameIDService>, to describe supported bindings and location(s) to which an entity may send requests and responses using this profile. A requester, if encrypting the principal's identifier, can use the responder's <md:KeyDescriptor> element with a use attribute of encryption to determine an appropriate encryption algorithm and settings to use, along with a public key to use in delivering a bulk encryption key.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 40 of 66

1437 1438 1439 1440 1441

5 Artifact Resolution Profile

[SAMLCore] defines an Artifact Resolution protocol for dereferencing a SAML artifact into a corresponding protocol message. The HTTP Artifact binding in [SAMLBind] leverages this mechanism to pass SAML protocol messages by reference. This profile describes the use of this protocol with a synchronous binding, such as the SOAP binding defined in [SAMLBind].

1442 1443 1444 1445 1446

5.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:profiles:artifact Contact information: [email protected] Description: Given below. Updates: None

1447 1448 1449 1450 1451 1452

5.2 Profile Overview

The message exchange and basic processing rules that govern this profile are largely defined by Section 3.5 of [SAMLCore] that defines the messages to be exchanged, in combination with the binding used to exchange the messages. Section 3.2 of [SAMLBind] defines the binding of the message exchange to SOAP V1.1. Unless specifically noted here, all requirements defined in those specifications apply. Figure 5 illustrates the basic template for the artifact resolution profile.

Requesting System Entity

1. <ArtifactResolve> issued by requesting provider

Responding System Entity

2. <ArtifactResponse> returned by responding provider

Figure 5

1453 1454 1455 1456

The following steps are described by the profile. 1. <ArtifactResolve> issued by Requesting Entity In step 1, a requester initiates the profile by sending an <ArtifactResolve> message to an artifact issuer.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 41 of 66

1457 1458 1459

2. <ArtifactResponse> issued by Responding Entity In step 2, the responder (after processing the request) issues an <ArtifactResponse> message to the requester.

1460 1461 1462 1463 1464

5.3 Profile Description

In the descriptions below, the following is referred to: Artifact Resolution Service This is the artifact resolution protocol endpoint at an artifact issuer to which <ArtifactResolve> messages are delivered.

1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475

5.3.1 <ArtifactResolve> issued by Requesting Entity

To initiate the profile, a requester, having received an artifact and determined the issuer using the SourceID, sends an <ArtifactResolve> message containing the artifact to an artifact issuer's artifact resolution service endpoint. Metadata (as in [SAMLMeta]) MAY be used to determine the location of this endpoint and the bindings supported by the artifact issuer. The requester MUST use a synchronous binding, such as the SOAP binding [SAMLBind], to send the request directly to the artifact issuer. The requester SHOULD authenticate itself to the responder, either by signing the <ArtifactResolve> message or using any other binding-supported mechanism. Specific profiles that use the HTTP Artifact binding MAY impose additional requirements such that authentication is mandatory. Profile-specific rules for the contents of the <ArtifactResolve> message are included in Section 5.4.1.

1476 1477 1478 1479 1480 1481 1482 1483 1484 1485

5.3.2 <ArtifactResponse> issued by Responding Entity

The artifact issuer MUST process the <ArtifactResolve> message as defined in [SAMLCore]. After processing the message or upon encountering an error, the artifact issuer MUST return an <ArtifactResponse> message containing an appropriate status code to the requester to complete the SAML protocol exchange. If successful, the dereferenced SAML protocol message corresponding to the artifact will also be included. The responder MUST authenticate itself to the requester, either by signing the <ArtifactResponse> or using any other binding-supported mechanism. Profile-specific rules for the contents of the <ArtifactResponse> message are included in Section 5.4.2.

1486

5.4 Use of Artifact Resolution Protocol

5.4.1 <ArtifactResolve> Usage
The <Issuer> element MUST be present and MUST contain the unique identifier of the requesting entity; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameidformat:entity. The requester SHOULD authenticate itself to the responder and ensure message integrity, either by signing the message or using a binding-specific mechanism. Specific profiles that use the HTTP Artifact binding MAY impose additional requirements such that authentication is mandatory.

1487 1488 1489 1490 1491 1492 1493

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 42 of 66

1494 1495 1496 1497 1498 1499

5.4.2 <ArtifactResponse> Usage

The <Issuer> element MUST be present and MUST contain the unique identifier of the artifact issuer; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameidformat:entity. The responder MUST authenticate itself to the requester and ensure message integrity, either by signing the message or using a binding-specific mechanism.

1500 1501 1502 1503 1504

5.5 Use of Metadata

[SAMLMeta] defines an indexed endpoint element, <md:ArtifactResolutionService>, to describe supported bindings and location(s) to which a requester may send requests using this profile. The index attribute is used to distinguish the possible endpoints that may be specified by reference in the artifact's EndpointIndex field.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 43 of 66

1505 1506 1507 1508

6 Assertion Query/Request Profile

[SAMLCore] defines a protocol for requesting existing assertions by reference or by querying on the basis of a subject and additional statement-specific criteria. This profile describes the use of this protocol with a synchronous binding, such as the SOAP binding defined in [SAMLBind].

1509 1510 1511 1512 1513

6.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:profiles:query Contact information: [email protected] Description: Given below. Updates: None.

1514 1515 1516 1517 1518 1519

6.2 Profile Overview

The message exchange and basic processing rules that govern this profile are largely defined by Section 3.3 of [SAMLCore] that defines the messages to be exchanged, in combination with the binding used to exchange the messages. Section 3.2 of [SAMLBind] defines the binding of the message exchange to SOAP V1.1. Unless specifically noted here, all requirements defined in those specifications apply. Figure 6 illustrates the basic template for the query/request profile.

SAML Requester

SAML Authority

1. Query or request message issued by SAML Requester

2. <Response> message returned by SAML Authorithy

Figure 6 The following steps are described by the profile. 1. Query/Request issued by SAML Requester In step 1, a SAML requester initiates the profile by sending an <AssertionIDRequest>, <SubjectQuery>, <AuthnQuery>, <AttributeQuery>, or <AuthzDecisionQuery> message to a SAML authority. 2. <Response> issued by SAML Authority In step 2, the responding SAML authority (after processing the query or request) issues a <Response> message to the SAML requester.

1520 1521 1522 1523 1524 1525 1526 1527

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 44 of 66

1528 1529 1530 1531 1532

6.3 Profile Description

In the descriptions below, the following are referred to: Query/Request Service This is the query/request protocol endpoint at a SAML authority to which query or <AssertionIDRequest> messages are delivered.

1533 1534 1535 1536 1537 1538 1539 1540 1541

6.3.1 Query/Request issued by SAML Requester

To initiate the profile, a SAML requester issues an <AssertionIDRequest>, <SubjectQuery>, <AuthnQuery>, <AttributeQuery>, or <AuthzDecisionQuery> message to a SAML authority's query/request service endpoint. Metadata (as in [SAMLMeta]) MAY be used to determine the location of this endpoint and the bindings supported by the SAML authority. The SAML requester MUST use a synchronous binding, such as the SOAP binding [SAMLBind], to send the request directly to the identity provider. The requester SHOULD authenticate itself to the SAML authority either by signing the message or using any other binding-supported mechanism. Profile-specific rules for the contents of the various messages are included in Section 6.4.1.

1542 1543 1544 1545 1546 1547 1548 1549 1550

6.3.2 <Response> issued by SAML Authority

The SAML authority MUST process the query or request message as defined in [SAMLCore]. After processing the message or upon encountering an error, the SAML authority MUST return a <Response> message containing an appropriate status code to the SAML requester to complete the SAML protocol exchange. If the request is successful in locating one or more matching assertions, they will also be included in the response. The responder SHOULD authenticate itself to the requester, either by signing the <Response> or using any other binding-supported mechanism. Profile-specific rules for the contents of the <Response> message are included in Section 6.4.2.

1551

6.4 Use of Query/Request Protocol

6.4.1 Query/Request Usage
The <Issuer> element MUST be present. The requester SHOULD authenticate itself to the responder and ensure message integrity, either by signing the message or using a binding-specific mechanism.

1552 1553 1554 1555

1556 1557 1558 1559 1560 1561 1562

6.4.2 <Response> Usage

The <Issuer> element MUST be present and MUST contain the unique identifier of the responding SAML authority; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity. Note that this need not necessarily match the <Issuer> element in the returned assertion(s). The responder SHOULD authenticate itself to the requester and ensure message integrity, either by signing the message or using a binding-specific mechanism.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 45 of 66

1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574

6.5 Use of Metadata

[SAMLMeta] defines several endpoint elements, <md:AssertionIDRequestService>, <md:AuthnQueryService>, <md:AttributeService>, and <md:AuthzService>, to describe supported bindings and location(s) to which a requester may send requests or queries using this profile. The SAML authority, if encrypting the resulting assertions or assertion contents for a particular entity, can use that entity's <md:KeyDescriptor> element with a use attribute of encryption to determine an appropriate encryption algorithm and settings to use, along with a public key to use in delivering a bulk encryption key. The various role descriptors MAY contain <md:NameIDFormat>, <md:AttributeProfile>, and <saml:Attribute> elements (as applicable) to indicate the general ability to support particular name identifier formats, attribute profiles, or specific attributes and values. The ability to support any such features during a given request is dependent on policy and the discretion of the authority.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 46 of 66

1575 1576 1577 1578 1579

7 Name Identifier Mapping Profile

[SAMLCore] defines a Name Identifier Mapping protocol for mapping a principal's name identifier into a different name identifier for the same principal. This profile describes the use of this protocol with a synchronous binding, such as the SOAP binding defined in [SAMLBind], and additional guidelines for protecting the privacy of the principal with encryption and limiting the use of the mapped identifier.

1580 1581 1582 1583 1584

7.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:profiles:nameidmapping Contact information: [email protected] Description: Given below. Updates: None.

1585 1586 1587 1588 1589 1590

7.2 Profile Overview

The message exchange and basic processing rules that govern this profile are largely defined by Section 3.8 of [SAMLCore] that defines the messages to be exchanged, in combination with the binding used to exchange the messages. Section 3.2 of [SAMLBind] defines the binding of the message exchange to SOAP V1.1. Unless specifically noted here, all requirements defined in those specifications apply. Figure 7 illustrates the basic template for the name identifier mapping profile.

Requesting System Entity

1. <NameIDMappingRequest> issued by requesting system entity

Identity Provider

2. <NameIDMappingResponse> returned by identity provider

Figure 7

1591 1592 1593 1594 1595

The following steps are described by the profile. 1. <NameIDMappingRequest> issued by Requesting Entity In step 1, a requester initiates the profile by sending a <NameIDMappingRequest> message to an identity provider. 2. <NameIDMappingResponse> issued by Identity Provider

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 47 of 66

1596 1597

In step 2, the responding identity provider (after processing the request) issues a <NameIDMappingResponse> message to the requester.

1598 1599 1600 1601 1602

7.3 Profile Description

In the descriptions below, the following is referred to: Name Identifier Mapping Service This is the name identifier mapping protocol endpoint at an identity provider to which <NameIDMappingRequest> messages are delivered.

1603 1604 1605 1606 1607 1608 1609 1610 1611

7.3.1 <NameIDMappingRequest> issued by Requesting Entity

To initiate the profile, a requester issues a <NameIDMappingRequest> message to an identity provider's name identifier mapping service endpoint. Metadata (as in [SAMLMeta]) MAY be used to determine the location of this endpoint and the bindings supported by the identity provider. The requester MUST use a synchronous binding, such as the SOAP binding [SAMLBind], to send the request directly to the identity provider. The requester MUST authenticate itself to the identity provider, either by signing the <NameIDMappingRequest> or using any other binding-supported mechanism. Profile-specific rules for the contents of the <NameIDMappingRequest> message are included in Section 7.4.1.

1612 1613 1614 1615 1616 1617 1618 1619 1620

7.3.2 <NameIDMappingResponse> issued by Identity Provider

The identity provider MUST process the <ManageNameIDRequest> message as defined in [SAMLCore]. After processing the message or upon encountering an error, the identity provider MUST return a <NameIDMappingResponse> message containing an appropriate status code to the requester to complete the SAML protocol exchange. The responder MUST authenticate itself to the requester, either by signing the <NameIDMappingResponse> or using any other binding-supported mechanism. Profile-specific rules for the contents of the <NameIDMappingResponse> message are included in Section 7.4.2.

1621

7.4 Use of Name Identifier Mapping Protocol

7.4.1 <NameIDMappingRequest> Usage
The <Issuer> element MUST be present. The requester MUST authenticate itself to the responder and ensure message integrity, either by signing the message or using a binding-specific mechanism.

1622 1623 1624 1625

1626 1627 1628 1629 1630 1631

7.4.2 <NameIDMappingResponse> Usage

The <Issuer> element MUST be present and MUST contain the unique identifier of the responding identity provider; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity. The responder MUST authenticate itself to the requester and ensure message integrity, either by signing the message or using a binding-specific mechanism.
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 48 of 66

1632 1633 1634 1635

Section 2.2.3 of [SAMLCore] defines the use of encryption to apply confidentiality to a name identifier. In most cases, the identity provider SHOULD encrypt the mapped name identifier it returns to the requester to protect the privacy of the principal. The requester can extract the <EncryptedID> element and place it in subsequent protocol messages or assertions.

1636 1637 1638 1639 1640 1641 1642

7.4.2.1 Limiting Use of Mapped Identifier

Additional limits on the use of the resulting identifier MAY be applied by the identity provider by returning the mapped name identifier in the form of an <Assertion> containing the identifier in its <Subject> but without any statements. The assertion is then encrypted and the result used as the <EncryptedData> element in the <EncryptedID> returned to the requester. The assertion MAY include a <Conditions> element to limit use, as defined by [SAMLCore], such as time-based constraints or use by specific relying parties, and MUST be signed for integrity protection.

1643 1644 1645 1646 1647 1648

7.5 Use of Metadata

[SAMLMeta] defines an endpoint element, <md:NameIDMappingService>, to describe supported bindings and location(s) to which a requester may send requests using this profile. The identity provider, if encrypting the resulting identifier for a particular entity, can use that entity's <md:KeyDescriptor> element with a use attribute of encryption to determine an appropriate encryption algorithm and settings to use, along with a public key to use in delivering a bulk encryption key.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 49 of 66

1649

8 SAML Attribute Profiles

8.1 Basic Attribute Profile
The Basic attribute profile specifies simplified, but non-unique, naming of SAML attributes together with attribute values based on the built-in XML Schema data types, eliminating the need for extension schemas to validate syntax.

1650 1651 1652 1653

1654 1655 1656 1657 1658

8.1.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:profiles:attribute:basic Contact information: [email protected] Description: Given below. Updates: None.

1659 1660 1661 1662

8.1.2 SAML Attribute Naming

The NameFormat XML attribute in <Attribute> elements MUST be urn:oasis:names:tc:SAML:2.0:attrname-format:basic. The Name XML attribute MUST adhere to the rules specified for that format, as defined by [SAMLCore].

1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681

8.1.2.1 Attribute Name Comparison

Two <Attribute> elements refer to the same SAML attribute if and only if the values of their Name XML attributes are equal in the sense of Section 3.3.6 of [Schema2].

8.1.3 Profile-Specific XML Attributes

No additional XML attributes are defined for use with the <Attribute> element.

8.1.4 SAML Attribute Values

The schema type of the contents of the <AttributeValue> element MUST be drawn from one of the types defined in Section 3.3 of [Schema2]. The xsi:type attribute MUST be present and be given the appropriate value.

8.1.5 Example
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="FirstName"> <saml:AttributeValue xsi:type="xs:string">By-Tor</saml:AttributeValue> </saml:Attribute>

8.2 X.500/LDAP Attribute Profile

Directories based on the ITU-T X.500 specifications [X.500] and the related IETF Lightweight Directory Access Protocol specifications [LDAP] are widely deployed. Directory schema is used to model information to be stored in these directories. In particular, in X.500, attribute type definitions are used to specify the syntax and other features of attributes, the basic information storage unit in a directory (this
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 50 of 66

1682 1683 1684 1685 1686 1687 1688 1689

document refers to these as directory attributes). Directory attribute types are defined in schema in the X.500 and LDAP specifications themselves, schema in other public documents (such as the Internet2/Educause EduPerson schema [eduPerson], or the inetOrgperson schema [RFC2798]), and schema defined for private purposes. In any of these cases, it is useful for deployers to take advantage of these directory attribute types in the context of SAML attribute statements, without having to manually create SAML-specific attribute definitions for them, and to do this in an interoperable fashion. The X.500/LDAP attribute profile defines a common convention for the naming and representation of such attributes when expressed as SAML attributes.

1690 1691 1692 1693 1694 1695

8.2.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500 (this is also the target namespace assigned in the corresponding X.500/LDAP profile schema document [SAMLX500-xsd]) Contact information: [email protected] Description: Given below. Updates: None.

1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710

8.2.2 SAML Attribute Naming

The NameFormat XML attribute in <Attribute> elements MUST be urn:oasis:names:tc:SAML:2.0:attrname-format:uri. To construct attribute names, the URN oid namespace described in IETF RFC 3061 [RFC3061] is used. In this approach the Name XML attribute is based on the OBJECT IDENTIFIER assigned to the directory attribute type. Example:
urn:oid:2.5.4.3

Since X.500 procedures require that every attribute type be identified with a unique OBJECT IDENTIFIER, this naming scheme ensures that the derived SAML attribute names are unambiguous. For purposes of human readability, there may also be a requirement for some applications to carry an optional string name together with the OID URN. The optional XML attribute FriendlyName (defined in [SAMLCore]) MAY be used for this purpose. If the definition of the directory attribute type includes one or more descriptors (short names) for the attribute type, the FriendlyName value, if present, SHOULD be one of the defined descriptors.

1711 1712 1713 1714

8.2.2.1 Attribute Name Comparison

Two <Attribute> elements refer to the same SAML attribute if and only if their Name XML attribute values are equal in the sense of [RFC3061]. The FriendlyName attribute plays no role in the comparison.

1715 1716 1717 1718 1719 1720 1721

8.2.3 Profile-Specific XML Attributes

No additional XML attributes are defined for use with the <Attribute> element.

8.2.4 SAML Attribute Values

Directory attribute type definitions for use in native X.500 directories specify the syntax of the attribute using ASN.1 [ASN.1]. For use in LDAP, directory attribute definitions additionally include an LDAP syntax which specifies how attribute or assertion values conforming to the syntax are to be represented when transferred in the LDAP protocol (known as an LDAP-specific encoding). The LDAP-specific encoding
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 51 of 66

1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766

commonly produces Unicode characters in UTF-8 form. This SAML attribute profile specifies the form of SAML attribute values only for those directory attributes which have LDAP syntaxes. Future extensions to this profile may define attribute value formats for directory attributes whose syntaxes specify other encodings. To represent the encoding rules in use for a particular attribute value, the <AttributeValue> element MUST contain an XML attribute named Encoding defined in the XML namespace urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500. For any directory attribute with a syntax whose LDAP-specific encoding exclusively produces UTF-8 character strings as values, the SAML attribute value is encoded as simply the UTF-8 string itself, as the content of the <AttributeValue> element, with no additional whitespace. In such cases, the xsi:type XML attribute MUST be set to xs:string. The profile-specific Encoding XML attribute is provided, with a value of LDAP. A list of some LDAP attribute syntaxes to which this applies is: Attribute Type Description Bit String Boolean Country String DN Directory String Facsimile Telephone Number Generalized Time IA5 String INTEGER LDAP Syntax Description Matching Rule Description Matching Rule Use Description Name And Optional UID Name Form Description Numeric String Object Class Description Octet String OID Other Mailbox Postal Address Presentation Address Printable String Substring Assertion Telephone Number UTC Time 1.3.6.1.4.1.1466.115.121.1.3 1.3.6.1.4.1.1466.115.121.1.6 1.3.6.1.4.1.1466.115.121.1.7 1.3.6.1.4.1.1466.115.121.1.11 1.3.6.1.4.1.1466.115.121.1.12 1.3.6.1.4.1.1466.115.121.1.15 1.3.6.1.4.1.1466.115.121.1.22 1.3.6.1.4.1.1466.115.121.1.24 1.3.6.1.4.1.1466.115.121.1.26 1.3.6.1.4.1.1466.115.121.1.27 1.3.6.1.4.1.1466.115.121.1.54 1.3.6.1.4.1.1466.115.121.1.30 1.3.6.1.4.1.1466.115.121.1.31 1.3.6.1.4.1.1466.115.121.1.34 1.3.6.1.4.1.1466.115.121.1.35 1.3.6.1.4.1.1466.115.121.1.36 1.3.6.1.4.1.1466.115.121.1.37 1.3.6.1.4.1.1466.115.121.1.40 1.3.6.1.4.1.1466.115.121.1.38 1.3.6.1.4.1.1466.115.121.1.39 1.3.6.1.4.1.1466.115.121.1.41 1.3.6.1.4.1.1466.115.121.1.43 1.3.6.1.4.1.1466.115.121.1.44 1.3.6.1.4.1.1466.115.121.1.58 1.3.6.1.4.1.1466.115.121.1.50 1.3.6.1.4.1.1466.115.121.1.53

For all other LDAP syntaxes, the attribute value is encoded, as the content of the <AttributeValue> element, by base64-encoding [RFC2045] the encompassing ASN.1 OCTET STRING-encoded LDAP attribute value. The xsi:type XML attribute MUST be set to xs:base64Binary. The profile-specific Encoding XML attribute is provided, with a value of LDAP. When comparing SAML attribute values for equality, the matching rules specified for the corresponding directory attribute type MUST be observed (case sensitivity, for example).

1767 1768 1769

8.2.5 Profile-Specific Schema

The following schema listing shows how the profile-specific Encoding XML attribute is defined [SAMLX500-xsd]:

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 52 of 66

1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803

<schema targetNamespace="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified" attributeFormDefault="unqualified" blockDefault="substitution" version="2.0"> <annotation> <documentation> Document identifier: saml-schema-x500-2.0 Location: http://docs.oasis-open.org/security/saml/v2.0/ Revision history: V2.0 (March, 2005): Custom schema for X.500 attribute profile, first published in SAML 2.0. </documentation> </annotation> <attribute name="Encoding" type="string"/> </schema>

8.2.6 Example
The following is an example of a mapping of the "givenName" directory attribute, representing the SAML assertion subject's first name. It's OBJECT IDENTIFIER is 2.5.4.42 and its LDAP syntax is Directory String.
<saml:Attribute xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:2.5.4.42" FriendlyName="givenName"> <saml:AttributeValue xsi:type="xs:string" x500:Encoding="LDAP">Steven</saml:AttributeValue> </saml:Attribute>

8.3 UUID Attribute Profile

The UUID attribute profile standardizes the expression of UUID values as SAML attribute names and values. It is applicable when the attribute's source system is one that identifies an attribute or its value with a UUID.

1804 1805 1806 1807 1808

8.3.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:profiles:attribute:UUID Contact information: [email protected] Description: Given below. Updates: None.

1809 1810 1811 1812 1813 1814 1815 1816 1817

8.3.2 UUID and GUID Background

UUIDs (Universally Unique Identifiers), also known as GUIDs (Globally Unique Identifiers), are used to define objects and subjects such that they are guaranteed uniqueness across space and time. UUIDs were originally used in the Network Computing System (NCS), and then used in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE). Recently GUIDs have been used in Microsoft's COM and Active Directory/Windows 2000/2003 platform. A UUID is a 128 bit number, generated such that it should never be duplicated within the domain of interest. UUIDs are used to represent a wide range of objects including, but not limited to, subjects/users, groups of users and node names. A UUID, represented as a hexadecimal string, is as follows:
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 53 of 66

1818 1819 1820

f81d4fae-7dec-11d0-a765-00a0c91e6bf6

In DCE and Microsoft Windows, the UUID is usually presented to the administrator in the form of a friendly name. For instance the above UUID could represent the user [email protected].

1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833

8.3.3 SAML Attribute Naming

The NameFormat XML attribute in <Attribute> elements MUST be urn:oasis:names:tc:SAML:2.0:attrname-format:uri. If the underlying representation of the attribute's name is a UUID, then the URN uuid namespace described in [Mealling] is used. In this approach the Name XML attribute is based on the URN form of the underlying UUID that identifies the attribute. Example:
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

If the underlying representation of the attribute's name is not a UUID, then any form of URI MAY be used in the Name XML attribute. For purposes of human readability, there may also be a requirement for some applications to carry an optional string name together with the URI. The optional XML attribute FriendlyName (defined in [SAMLCore]) MAY be used for this purpose.

1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845

8.3.3.1 Attribute Name Comparison

Two <Attribute> elements refer to the same SAML attribute if and only if their Name XML attribute values are equal in the sense of [http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-05.txt]. The FriendlyName attribute plays no role in the comparison.

8.3.4 Profile-Specific XML Attributes

No additional XML attributes are defined for use with the <Attribute> element.

8.3.5 SAML Attribute Values

In cases in which the attribute's value is also a UUID, the same URN syntax described above MUST be used to express the value within the <AttributeValue> element. The xsi:type XML attribute MUST be set to xs:anyURI. If the attribute's value is not a UUID, then there are no restrictions on the use of the <AttributeValue> element.

1846 1847 1848

8.3.6 Example
The following is an example of a DCE Extended Registry Attribute, the "pre_auth_req" setting, which has a well-known UUID of 6c9d0ec8-dd2d-11cc-abdd-080009353559 and is integer-valued.
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:uuid:6c9d0ec8-dd2d-11cc-abdd-080009353559" FriendlyName="pre_auth_req"> <saml:AttributeValue xsi:type="xs:integer">1</saml:AttributeValue> </saml:Attribute>

1849 1850 1851 1852 1853

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 54 of 66

1854 1855 1856 1857 1858

8.4 DCE PAC Attribute Profile

The DCE PAC attribute profile defines the expression of DCE PAC information as SAML attribute names and values. It is used to standardize a mapping between the primary information that makes up a DCE principal's identity and a set of SAML attributes. This profile builds on the UUID attribute profile defined in Section 8.3.

1859 1860 1861 1862 1863 1864

8.4.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE (this is also the target namespace assigned in the corresponding DCE PAC attribute profile schema document [SAMLDCE-xsd]) Contact information: [email protected] Description: Given below. Updates: None.

1865 1866 1867 1868 1869 1870 1871 1872 1873

8.4.2 PAC Description

A DCE PAC is an extensible structure that can carry arbitrary DCE registry attributes, but a core set of information is common across principals and makes up the bulk of a DCE identity:

The principal's DCE "realm" or "cell" The principal's unique identifier The principal's primary DCE local group membership The principal's set of DCE local group memberships (multi-valued) The principal's set of DCE foreign group memberships (multi-valued)

The primary value(s) of each of these attributes is a UUID.

1874 1875 1876 1877 1878 1879 1880 1881 1882

8.4.3 SAML Attribute Naming

This profile defines a mapping of specific DCE information into SAML attributes, and thus defines actual specific attribute names, rather than a naming convention. For all attributes defined by this profile, the NameFormat XML attribute in <Attribute> elements MUST have the value urn:oasis:names:tc:SAML:2.0:attrname-format:uri. For purposes of human readability, there may also be a requirement for some applications to carry an optional string name together with the URI. The optional XML attribute FriendlyName (defined in [SAMLCore]) MAY be used for this purpose. See Section 8.4.6 for the specific attribute names defined by this profile.

1883 1884 1885 1886

8.4.3.1 Attribute Name Comparison

Two <Attribute> elements refer to the same SAML attribute if and only if their Name XML attribute values are equal in the sense of [http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-05.txt]. The FriendlyName attribute plays no role in the comparison.

1887 1888

8.4.4 Profile-Specific XML Attributes

No additional XML attributes are defined for use with the <Attribute> element.
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 55 of 66

1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899

8.4.5 SAML Attribute Values

The primary value(s) of each of the attributes defined by this profile is a UUID. The URN syntax described in Section 8.3.5 of the UUID profile is used to represent such values. However, additional information associated with the UUID value is permitted by this profile, consisting of a friendly, human-readable string, and an additional UUID representing a DCE cell or realm. The additional information is carried in the <AttributeValue> element in FriendlyName and Realm XML attributes defined in the XML namespace urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE. Note that this is not the same as the FriendlyName XML attribute defined in [SAMLCore], although it has the same basic purpose. The following schema listing shows how the profile-specific XML attributes and complex type used in an xsi:type specification are defined [SAMLDCE-xsd]:
<schema targetNamespace="urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE" xmlns:dce="urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified" attributeFormDefault="unqualified" blockDefault="substitution" version="2.0"> <annotation> <documentation> Document identifier: saml-schema-dce-2.0 Location: http://docs.oasis-open.org/security/saml/v2.0/ Revision history: V2.0 (March, 2005): Custom schema for DCE attribute profile, first published in SAML 2.0. </documentation> </annotation> <complexType name="DCEValueType"> <simpleContent> <extension base="anyURI"> <attribute ref="dce:Realm" use="optional"/> <attribute ref="dce:FriendlyName" use="optional"/> </extension> </simpleContent> </complexType> <attribute name="Realm" type="anyURI"/> <attribute name="FriendlyName" type="string"/> </schema>

1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934

8.4.6 Attribute Definitions

The following are the set of SAML attributes defined by this profile. In each case, an xsi:type XML attribute MAY be included in the <AttributeValue> element, but MUST have the value dce:DCEValueType, where the dce prefix is arbitrary and MUST be bound to the XML namespace urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE. Note that such use of xsi:type will require validating attribute consumers to include the extension schema defined by this profile.

1935 1936 1937 1938

8.4.6.1 Realm
This single-valued attribute represents the SAML assertion subject's DCE realm or cell. Name: urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE:realm The single <AttributeValue> element contains a UUID in URN form identifying the SAML assertion
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 56 of 66

1939 1940

subject's DCE realm/cell, with an optional profile-specific FriendlyName XML attribute containing the realm's string name.

1941 1942 1943 1944 1945 1946 1947 1948 1949

8.4.6.2 Principal
This single-valued attribute represents the SAML assertion subject's DCE principal identity. Name: urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE:principal The single <AttributeValue> element contains a UUID in URN form identifying the SAML assertion subject's DCE principal identity, with an optional profile-specific FriendlyName XML attribute containing the principal's string name. The profile-specific Realm XML attribute MAY be included and MUST contain a UUID in URN form identifying the SAML assertion subject's DCE realm/cell (the value of the attribute defined in Section 8.4.6.1).

1950 1951 1952 1953 1954 1955 1956 1957 1958

8.4.6.3 Primary Group

This single-valued attribute represents the SAML assertion subject's primary DCE group membership. Name: urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE:primary-group The single <AttributeValue> element contains a UUID in URN form identifying the SAML assertion subject's primary DCE group, with an optional profile-specific FriendlyName XML attribute containing the group's string name. The profile-specific Realm XML attribute MAY be included and MUST contain a UUID in URN form identifying the SAML assertion subject's DCE realm/cell (the value of the attribute defined in Section 8.4.6.1).

1959 1960 1961 1962 1963 1964 1965 1966 1967

8.4.6.4 Groups
This multi-valued attribute represents the SAML assertion subject's DCE local group memberships. Name: urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE:groups Each <AttributeValue> element contains a UUID in URN form identifying a DCE group membership of the SAML assertion subject, with an optional profile-specific FriendlyName XML attribute containing the group's string name. The profile-specific Realm XML attribute MAY be included and MUST contain a UUID in URN form identifying the SAML assertion subject's DCE realm/cell (the value of the attribute defined in Section 8.4.6.1).

1968 1969 1970 1971 1972 1973 1974 1975

8.4.6.5 Foreign Groups

This multi-valued attribute represents the SAML assertion subject's DCE foreign group memberships. Name: urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE:foreign-groups Each <AttributeValue> element contains a UUID in URN form identifying a DCE foreign group membership of the SAML assertion subject, with an optional profile-specific FriendlyName XML attribute containing the group's string name. The profile-specific Realm XML attribute MUST be included and MUST contain a UUID in URN form identifying the DCE realm/cell of the foreign group.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 57 of 66

1976 1977 1978 1979

8.4.7 Example
The following is an example of the transformation of PAC data into SAML attributes belonging to a DCE principal named "jdoe" in realm "example.com", a member of the "cubicle-dwellers" and "underpaid" local groups and an "engineers" foreign group.
<saml:Assertion xmlns:dce="urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE" ...> <saml:Issuer>...</saml:Issuer> <saml:Subject>...</saml:Subject> <saml:AttributeStatement> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE:realm"> <saml:AttributeValue xsi:type="dce:DCEValueType" dce:FriendlyName="example.com"> urn:uuid:003c6cc1-9ff8-10f9-990f-004005b13a2b </saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE:principal"> <saml:AttributeValue xsi:type="dce:DCEValueType" dce:FriendlyName="jdoe"> urn:uuid:00305ed1-a1bd-10f9-a2d0-004005b13a2b </saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE:primary-group"> <saml:AttributeValue xsi:type="dce:DCEValueType" dce:FriendlyName="cubicle-dwellers"> urn:uuid:008c6181-a288-10f9-b6d6-004005b13a2b </saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE:groups"> <saml:AttributeValue xsi:type="dce:DCEValueType" dce:FriendlyName="cubicle-dwellers"> urn:uuid:008c6181-a288-10f9-b6d6-004005b13a2b </saml:AttributeValue> <saml:AttributeValue xsi:type="dce:DCEValueType" dce:FriendlyName="underpaid"> urn:uuid:006a5a91-a2b7-10f9-824d-004005b13a2b </saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE:foreigngroups"> <saml:AttributeValue xsi:type="dce:DCEValueType" dce:FriendlyName="engineers" dce:Realm="urn:uuid:00583221-a35f-10f9-8b6e-004005b13a2b"> urn:uuid:00099cf1-a355-10f9-9e95-004005b13a2b </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033

8.5 XACML Attribute Profile

SAML attribute assertions may be used as input to authorization decisions made according to the OASIS eXtensible Access Control Markup Language [XACML] standard specification. Since the SAML attribute format differs from the XACML attribute format, there is a mapping that must be performed. The XACML attribute profile facilitates this mapping by standardizing naming, value syntax, and additional attribute metadata. SAML attributes generated in conformance with this profile can be mapped automatically into XACML attributes and used as input to XACML authorization decisions.

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 58 of 66

2034 2035 2036 2037 2038 2039

8.5.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML (this is also the target namespace assigned in the corresponding XACML profile schema document [SAMLXAC-xsd]) Contact information: [email protected] Description: Given below. Updates: None.

2040 2041 2042 2043 2044 2045 2046

8.5.2 SAML Attribute Naming

The NameFormat XML attribute in <Attribute> elements MUST be urn:oasis:names:tc:SAML:2.0:attrname-format:uri. The Name XML attribute MUST adhere to the rules specified for that format, as defined by [SAMLCore]. For purposes of human readability, there may also be a requirement for some applications to carry an optional string name together with the OID URN. The optional XML attribute FriendlyName (defined in [SAMLCore]) MAY be used for this purpose, but is not translatable into an XACML attribute equivalent.

2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059

8.5.2.1 Attribute Name Comparison

Two <Attribute> elements refer to the same SAML attribute if and only if their Name XML attribute values are equal in a binary comparison. The FriendlyName attribute plays no role in the comparison.

8.5.3 Profile-Specific XML Attributes

XACML requires each attribute to carry an explicit data type. To supply this data type value, a new URIvalued XML attribute called DataType is defined in the XML namespace urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML. SAML <Attribute> elements conforming to this profile MUST include the namespace-qualified DataType attribute, or the value is presumed to be http://www.w3.org/2001/XMLSchema#string. While in principle any URI reference can be used as a data type, the standard values to be used are specified in Appendix A of the XACML 2.0 Specification [XACML]. If non-standard values are used, then each XACML PDP that will be consuming mapped SAML attributes with non-standard DataType values must be extended to support the new data types.

2060 2061 2062 2063 2064

8.5.4 SAML Attribute Values

The syntax of the <AttributeValue> element's content MUST correspond to the data type expressed in the profile-specific DataType XML attribute appearing in the parent <Attribute> element. For data types corresponding to the types defined in Section 3.3 of [Schema2], the xsi:type XML attribute SHOULD also be used on the <AttributeValue> element(s).

2065 2066 2067

8.5.5 Profile-Specific Schema

The following schema listing shows how the profile-specific DataType XML attribute is defined [SAMLXAC-xsd]:

2068 2069 2070 2071

<schema targetNamespace="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified"

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 59 of 66

2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090

attributeFormDefault="unqualified" blockDefault="substitution" version="2.0"> <annotation> <documentation> Document identifier: saml-schema-xacml-2.0 Location: http://docs.oasis-open.org/security/saml/v2.0/ Revision history: V2.0 (March, 2005): Custom schema for XACML attribute profile, first published in SAML 2.0. </documentation> </annotation> <attribute name="DataType" type="anyURI"/> </schema>

8.5.6 Example
The following is an example of a mapping of the "givenName" LDAP/X.500 attribute, representing the SAML assertion subject's first name. It also illustrates that a single SAML attribute can conform to multiple attribute profiles when they are compatible with each other.
<saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" xmlns:ldapprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:LDAP" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string" ldapprof:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:2.5.4.42" FriendlyName="givenName"> <saml:AttributeValue xsi:type="xs:string">By-Tor</saml:AttributeValue> </saml:Attribute>

2091 2092 2093 2094 2095 2096 2097 2098 2099

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 60 of 66

2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145

9 References
[AES] [Anders] [ASN.1] FIPS-197, Advanced Encryption Standard (AES). See http://www.nist.gov/. A suggestion on how to implement SAML browser bindings without using Artifacts. See http://www.x-obi.com/OBI400/andersr-browser-artifact.ppt. Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation, ITU-T Recommendation X.680, July 2002. See http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-RECX.680. eduPerson.ldif. See http://www.educause.edu/eduperson. J. Hodges et al. Lightweight Directory Access Protocol (v3): Technical Specification. IETF RFC 3377, September 2002. See http://www.ietf.org/rfc/rfc3377.txt. P Leach et al. A UUID URN Namespace. IETF Internet-Draft, December 2004. See http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-05.txt. Microsoft technical support article. See http://support.microsoft.com/support/kb/articles/Q208/4/27.ASP. Persistent Client State HTTP Cookies, Netscape documentation. See http://wp.netscape.com/newsref/std/cookie_spec.html. 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. E. Rescorla et al. Guidelines for Writing RFC Text on Security Considerations. IETF RFC 3552, July 2003. See http://www.ietf.org/internet-drafts/draft-iab-sec-cons-03.txt. T. Berners-Lee et al. Uniform Resource Locators (URL). IETF RFC 1738, December 1994. See http://www.ietf.org/rfc/rfc1738.txt. D. Eastlake et al. Randomness Recommendations for Security. IETF RFC 1750, December 1994. See http://www.ietf.org/rfc/rfc1750.txt. T. Berners-Lee et al. Hypertext Transfer Protocol HTTP/1.0. IETF RFC 1945, May 1996. See http://www.ietf.org/rfc/rfc1945.txt. N. Freed et al. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. IETF RFC 2045, November 1996. See http://www.ietf.org/rfc/rfc2045.txt. S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119, March 1997. See http://www.ietf.org/rfc/rfc2119.txt. T. Dierks. The TLS Protocol Version 1.0. IETF RFC 2246, January 1999. See http://www.ietf.org/rfc/rfc2246.txt. M. Wahl. A Summary of the X.500(96) User Schema for use with LDAPv3. IETF RFC 2256, December 1997. See http://www.ietf.org/rfc/rfc2256.txt. F. Yergeau. UTF-8, a transformation format of ISO 10646. IETF RFC 2279, January 1998. See http://www.ietf.org/rfc/rfc2279.txt. R. Fielding et al. Hypertext Transfer Protocol HTTP/1.1. IETF RFC 2616, June 1999. See http://www.ietf.org/rfc/rfc2616.txt. J. Franks et al. HTTP Authentication: Basic and Digest Access Authentication. IETF RFC 2617, Jujne 1999. See http://www.ietf.org/rfc/rfc2617.txt. M. Smith. Definition of the inetOrgPerson LDAP Object Class. IETF RFC 2798, April 2000. See http://www.ietf.org/rfc/rfc2798.txt. D. Cristol et al. HTTP State Management Mechanism. IETF RFC 2965, October 2000. See http://www.ietf.org/rfc/rfc2965.txt.
15 March 2005 Page 61 of 66

[eduPerson] [LDAP] [Mealling] [MSURL] [NSCookie] [PAOS] [Rescorla-Sec] [RFC1738] [RFC1750] [RFC1945] [RFC2045]

[RFC2119] [RFC2246] [RFC2256] [RFC2279] [RFC2616] [RFC2617] [RFC2798] [RFC2965]

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196

[RFC3061] [SAMLBind]

M. Mealling. A URN Namespace of Object Identifiers. IETF RFC 3061, February 2001. See http://www.ietf.org/rfc/rfc3061.txt. S. Cantor et al. Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, March 2005. Document ID saml-bindings-2.0-os. See http://www.oasis-open.org/committees/security/.

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

[SAMLDCE-xsd] S. Cantor et al. SAML DCE PAC attribute profile schema. OASIS SSTC, March 2005. Document ID saml-schema-dce-2.0. See http://www.oasisopen.org/committees/security/. [SAMLECP-xsd] S. Cantor et al. SAML ECP profile schema. OASIS SSTC, March 2005. Document ID saml-schema-ecp-2.0. 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/.

[SAMLX500-xsd] S. Cantor et al. SAML X.500/LDAP attribute profile schema. OASIS SSTC, March 2005. Document ID saml-schema-x500-2.0. See http://www.oasisopen.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/. Darren Platt et al. OASIS Security Services Use Cases and Requirements. OASIS SSTC, May 2001. Document ID draft-sstc-saml-reqs-01. See http://www.oasisopen.org/committees/security/. F. Hirsch et al. Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, March 2005. Document ID saml-secconsider-2.0-os. See http://www.oasis-open.org/committees/security/. OASIS Security Services Technical Committee website, http://www.oasisopen.org/committees/security.

[SAMLReqs]

[SAMLSec]

[SAMLWeb]

[SAMLXAC-xsd] S. Cantor et al. SAML XACML attribute profile schema. OASIS SSTC, March 2005. Document ID saml-schema-xacml-2.0. See http://www.oasisopen.org/committees/security/. [Schema1] H. S. Thompson et al. XML Schema Part 1: Structures. World Wide Web Consortium Recommendation, May 2001. http://www.w3.org/TR/xmlschema-1/. Note that this specification normatively references [Schema2], listed below. Paul V. Biron, Ashok Malhotra. XML Schema Part 2: Datatypes. World Wide Web Consortium Recommendation, May 2001. See http://www.w3.org/TR/xmlschema-2/. RL 'Bob' Morgan. Support of target web server sessions in Shibboleth. Shibboleth, May 2001. See http://middleware.internet2.edu/shibboleth/docs/draft-morgan-shibbolethsession-00.txt. Marlena Erdos et al. Shibboleth Architecture DRAFT v05. Shibboleth, May 2002. See http://shibboleth.internet2.edu/draft-internet2-shibboleth-arch-v05.html. D. Box et al. Simple Object Access Protocol (SOAP) 1.1. World Wide Web Consortium Note, May 2000. See http://www.w3.org/TR/SOAP. A. Frier et al. The SSL 3.0 Protocol. Netscape Communications Corp, November 1996. RL 'Bob' Morgan. Interactions between Shibboleth and local-site web sign-on services. Shibboleth, April 2001. See http://middleware.internet2.edu/shibboleth/docs/draft15 March 2005 Page 62 of 66

[Schema2] [SESSION]

[ShibMarlena] [SOAP1.1] [SSL3] [WEBSSO]

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210

morgan-shibboleth-websso-00.txt. [X.500] Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services. ITU-T Recommendation X.500, February 2001. See http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-RECX.500. D. Eastlake et al. XML Encryption Syntax and Processing. World Wide Web Consortium Recommendation, December 2002. See http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/. D. Eastlake et al. XML-Signature Syntax and Processing. World Wide Web Consortium Recommendation, February 2002. See http://www.w3.org/TR/xmldsigcore/. T. Moses, ed., OASIS eXtensible Access Control Markup Language (XACML) Versions 1.0, 1.1, and 2.0. Available on the OASIS XACML TC web page at http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=xacml.

[XMLEnc]

[XMLSig]

[XACML]

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 63 of 66

2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253

Appendix A. Acknowledgments
The editors would like to acknowledge the contributions of the OASIS Security Services Technical Committee, 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 Eve Maler, Sun Microsystems
saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved. 15 March 2005 Page 64 of 66

2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290

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 to this 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 ONeill, Vordel Tony Palmer, Vordel Finally, the editors wish to acknowledge the following people for their contributions of material used as input to the OASIS Security Assertions Markup Language specifications: Thomas Gross, IBM Birgit Pfitzmann, IBM

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 65 of 66

2291

Appendix B. Notices
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users 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, or other 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 that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an AS IS basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317

saml-profiles-2.0-os Copyright OASIS Open 2005. All Rights Reserved.

15 March 2005 Page 66 of 66