1 Shibboleth Architecture 2 Protocols and Profiles 3 Working Draft 09, 28 February 2005 4 5 Document identifier: draft-mace-shibboleth-arch-protocols-09 6 7 Location: http://shibboleth.internet2.edu/shibboleth-documents.html 8 9 Editors: Scott Cantor (cantor.2@osu.edu), The Ohio State University 10 11 12 13 14 15 16 17 Contributors: Steven Carmody, Brown University Marlena Erdos, Tivoli Systems, Inc. Keith Hazelton, University of Wisconsin Walter Hoehn, University of Memphis RL "Bob" Morgan, University of Washington Tom Scavo, NCSA David Wasley, University of California 18 19 20 21 22 Abstract: This specification defines the general architecture, protocols, and message formats that make up the Shibboleth web single sign-on and attribute exchange mechanism, which is built on the OASIS SAML 1.1 specification (http://www.oasis-open.org/committees/security). Readers should be familiar with that specification before reading this document. 23 24 1 2 This is a working draft and the text may change before completion. Please submit comments to the shibboleth-dev mailing list (see http://shibboleth.internet2.edu/ for subscription details). draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 1 of 19 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 Table of Contents 1 Introduction..................................................................................................................................................3 1.1 Notation................................................................................................................................................3 2 Architectural Overview.................................................................................................................................4 2.1 Single Sign-On Overview.....................................................................................................................4 2.2 Identity Provider...................................................................................................................................5 2.2.1 Authentication Authority................................................................................................................6 2.2.2 Attribute Authority.........................................................................................................................6 2.2.3 Single Sign-On Service.................................................................................................................6 2.2.4 Inter-Site Transfer Service............................................................................................................7 2.2.5 Artifact Resolution Service...........................................................................................................7 2.3 Service Provider...................................................................................................................................7 2.3.1 Assertion Consumer Service........................................................................................................7 2.3.2 Attribute Requester.......................................................................................................................8 2.4 WAYF...................................................................................................................................................8 3 Protocols and Profiles.................................................................................................................................9 3.1 Authentication Request and Response Profiles..................................................................................9 3.1.1 Authentication Request Profile.....................................................................................................9 3.1.1.1 Required Information.............................................................................................................9 3.1.1.2 Message Format and Transmission......................................................................................9 3.1.1.3 Processing Rules................................................................................................................10 3.1.1.4 Example..............................................................................................................................10 3.1.2 Browser/POST Authentication Response Profile.......................................................................11 3.1.2.1 Example..............................................................................................................................11 3.1.3 Browser/Artifact Authentication Response Profile......................................................................12 3.1.3.1 Example..............................................................................................................................13 3.2 Attribute Exchange Profile.................................................................................................................13 3.2.1 Required Information..................................................................................................................13 3.2.2 Attribute Requests......................................................................................................................13 3.2.2.1 Example..............................................................................................................................14 3.2.3 Attribute Responses...................................................................................................................14 3.2.3.1 Example..............................................................................................................................14 3.2.4 Attribute Naming and Syntax......................................................................................................15 3.3 Transient NameIdentifier Format.......................................................................................................15 71 3.4 Metadata Profile.................................................................................................................................16 3.4.1 Element ...............................................................................................16 3.4.2 Element ..................................................................................................16 3.4.3 Element .............................................................................................16 3.4.4 Element ...................................................................................17 3.4.5 Element ...............................................................................17 3.4.6 Element ..............................................................................................17 4 Security and Privacy Considerations.........................................................................................................18 4.1 Additional Browser Profile Considerations.........................................................................................18 4.1.1 Information Leakage and Impersonation....................................................................................18 4.1.2 Time Synchronization.................................................................................................................18 5 References................................................................................................................................................19 5.1 Normative References.......................................................................................................................19 72 5.2 Non-Normative References...............................................................................................................19 59 60 61 62 63 64 65 66 67 68 69 70 73 3 4 draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 2 of 19 74 1 Introduction 75 76 77 78 This specification defines a set of related profiles of SAML 1.1 and additional messages and protocols that make up the Shibboleth architecture. It is functionally a superset of the SAML 1.1 web browser single sign-on and attribute exchange mechanisms that incorporates additional profiles for user privacy and service-provider-first access. 79 80 81 Unless specifically noted, nothing in this document should be taken to conflict with the SAML 1.1 specification, or any bindings and profiles referenced within it. Readers are advised to familiarize themselves with that specification first. 82 1.1 Notation 83 This specification uses normative text to describe the use of SAML 1.1 and additional SAML profiles. 84 85 86 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC 2119]: 87 88 …they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)… 89 90 91 These keywords are thus capitalized when used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense. 92 Listings of XML schemas appear like this. 93 94 Example code listings appear like this. 95 96 97 Conventional XML namespace prefixes are used throughout the listings in this specification to stand for their respective namespaces as follows, whether or not a namespace declaration is present in the example: 98 99 100 101 102 103 104 105 106 107 108 109 110 5 6 • The prefix saml: stands for the SAML 1.1 assertion namespace, urn:oasis:names:tc:SAML:1.0:assertion • The prefix samlp: stands for the SAML 1.1 request-response protocol namespace, urn:oasis:names:tc:SAML:1.0:protocol • The prefix md: stands for the SAML 2.0 metadata namespace, urn:oasis:names:tc:SAML:2.0:metadata • The prefix ds: stands for the W3C XML Signature namespace, http://www.w3.org/2000/09/xmldsig# • The prefix xsd: stands for the W3C XML Schema namespace, http://www.w3.org/2001/XMLSchema in example listings. In schema listings, this is the default namespace and no prefix is shown. This specification uses the following typographical conventions in text: , , Attribute, Datatype, OtherCode. draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 3 of 19 111 2 Architectural Overview 112 113 Broadly speaking, the Shibboleth architecture defines a set of interactions between an identity provider and a service provider to facilitate web browser single sign-on and attribute exchange. 114 115 116 117 Previous versions of this specification and the SAML 1.1 specification variously refer to these roles of identity provider and service provider as "source site" or "origin" and "destination site" or "target". This specification adopts terminology used within the Liberty ID-FF specification [LibertyProt] and the draft SAML 2.0 specification [SAML2Gloss]. 118 119 120 An additional, optional component called a WAYF service acts independently as a possible means of identity provider discovery. The role of the WAYF can be, and often is, taken on by a service provider itself. 121 2.1 Single Sign-On Overview 122 123 124 125 The following sequence diagram illustrates the set of required and optional interactions when using the Browser/POST profile. The Browser/Artifact profile replaces step 5 below with an artifact issued to the service provider followed by a SAML request/response exchange between the service provider and identity provider. See [SAMLBind] for detailed descriptions of both profiles. 126 Dashed lines and boxes represent optional behavior. User Agent Service Provider WAYF Service Identity Provider User Agent attempts to access some resource at the Service Provider Shibboleth Authentication Request issued by Service Provider to WAYF Service or Identity Provider If WAYF used, then User Agent selects Identity Provider, to which Authentication Request is redirected Identity Provider identifies Principal (methods vary, details not shown) message issued by Identity Provider to Service Provider, and MAY contain SAML attributes Service Provider sends to Identity Provider Identity Provider returns to Service Provider Based on the Identity Provider's assertion(s) identifying the Principal, the Service Provider either returns the resource or an (HTTP) error 7 8 draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 4 of 19 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 156 157 158 159 160 161 162 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. Authentication Request issued by Service Provider to WAYF or Identity Provider In step 2, the service provider issues an authentication request and redirects the user agent to either a WAYF or directly to an identity provider. A WAYF is typically used if the service provider wants to delegate the job of identity provider discovery and is working with a sufficiently constrained set of identity providers. 3. WAYF redirects Authentication Request to selected Identity Provider If a WAYF is used in step 2, then it interacts via unspecified means with the user agent to select an identity provider to which to redirect the user agent with the service provider's authentication request. 4. Identity Provider identifies Principal In step 4, the principal is identified by the identity provider by some means outside the scope of this specification. This may require a new act of authentication, or it may reuse an existing authenticated session. 5. Identity Provider issues or SAML Artifact(s) to Service Provider In step 5, the identity provider issues a SAML response message or one or more SAML artifacts to be delivered by the user agent to the service provider. Either the SAML 1.1 Browser/POST profile or Browser/Artifact profile may be used. If the Browser/POST profile is used, then either one or more assertions (or an error response) is passed directly through the user agent to the service provider. If the Browser/Artifact profile is used, then one or more SAML artifacts are passed through the user agent to the service provider, at which point the service provider communicates directly with the identity provider to resolve the artifact(s) into assertions. 6. Service Provider sends Attribute Query to Identity Provider In step 6, the service provider optionally uses the subject of the authentication assertion it received in step 5 to send a (inside a SAML request message) to an attribute authority associated with the identity provider. 7. Identity Provider returns SAML Assertion to Service Provider In step 7, the attribute authority associated with the identity provider processes the and returns a SAML response message, possibly containing one or more assertions containing attributes that apply to the principal. 8. Service Provider grants or denies access to Principal In step 8, the service provider responds to the principal's user agent with an error, or establishes its own security context for the principal and returns the requested resource. 163 164 Note that an identity provider can initiate this sequence at step 5 and issue an unsolicited SAML response message or SAML artifact(s) to a service provider without the preceding steps. 165 2.2 Identity Provider 166 167 168 An identity provider is an entity that authenticates principals and produces assertions of authentication and attribute information in accordance with [SAMLCore] and the SAML Browser/POST or Browser/Artifact profiles in [SAMLBind]. It consists of functional components drawn from the SAML domain model, an 9 10 draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 5 of 19 169 170 171 authentication authority and an attribute authority, along with an inter-site transfer service, defined by the Browser profiles, and a single sign-on service, defined by this specification. Note that physically, the single sign-on service and inter-site transfer service MAY be the same location. 172 173 174 Each identity provider MUST be assigned a unique identifier, or providerId. The identifier MUST be a URI [RFC 2396] of no more than 1024 characters. Use of an "https" URL for this purpose may be advantageous for metadata publication (see section 3.4). 175 2.2.1 Authentication Authority 176 177 178 179 The authentication authority is a SAML-defined service that issues authentication assertions about principals to relying parties (service providers, in the case of Shibboleth). Shibboleth does not specify how authentication of principals should be performed; the authority works with the principal's authentication service so that assertions about the authentication event are issued. 180 181 182 183 184 185 The only specifically defined use of an authentication assertion in Shibboleth is in accordance with the Browser/POST and Browser/Artifact profiles. As a result, the authentication authority is NOT REQUIRED to process SAML messages containing or elements, but MAY choose to do so. Also note that the Browser/POST and Browser/Artifact profiles do not specifically require the authentication authority to remember the assertions that it issues over an extended period of time, though this is also permitted. 186 2.2.2 Attribute Authority 187 188 189 190 191 The attribute authority is a SAML-defined service that supports a SAML protocol binding and the processing of SAML messages containing the element. This service issues attribute assertions to service providers in a mutually authenticated fashion. Implementations typically rely on SSL/TLS [RFC 2246] or SAML message signatures to mutually authenticate the exchange. 192 193 194 195 196 Shibboleth additionally requires that control of attribute release to service providers be available to both administrators and principals. Therefore, a Shibboleth attribute authority MUST have the ability to authenticate requests and MUST implement some form of access control governing the release of specific attributes and values belonging to specific principals to specific requesting service providers. Subject to that constraint, any access control mechanism may be supported. 197 198 199 200 A Shibboleth attribute authority MAY implement support for when processing queries, but is NOT REQUIRED to do so. That is, it MAY return errors when presented with queries containing unsupported confirmation methods or when asked to produce assertions containing them. 201 202 Finally, a Shibboleth attribute authority MUST support the attribute exchange profile described in section 3.2. 203 2.2.3 Single Sign-On Service 204 205 206 A single sign-on (SSO) service is an HTTP resource controlled by the identity provider that receives and processes authentication requests sent through the browser from service providers. The SSO service initiates the authentication process, eventually redirecting the browser to the inter-site transfer service. 207 208 The SSO service is a Shibboleth-specific service that is not defined by SAML 1.1. It supports a normative protocol to initiate SSO by a service provider, which SAML 1.1 does not define. 209 210 An identity provider may expose any number of SSO service endpoints. Each endpoint SHOULD be protected by SSL/TLS [RFC 2246]. 11 12 draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 6 of 19 211 2.2.4 Inter-Site Transfer Service 212 213 214 An inter-site transfer service is an HTTP resource controlled by the identity provider that interacts with the authentication authority to issue HTTP responses to the principal's browser adhering to the SAML Browser/POST or Browser/Artifact profiles. 215 216 217 In the case of the Browser/POST profile, the HTTP response contains the form controls necessary to transmit an authentication assertion inside a digitally signed message to a service provider's assertion consumer service. 218 219 220 In the case of the Browser/Artifact profile, the HTTP response contains a Location header redirecting the browser to a service provider's assertion consumer service. The redirection URL contains one or more URL-encoded SAML artifacts. 221 The inter-site transfer service and the SSO service MAY be located at the same HTTP endpoint. 222 2.2.5 Artifact Resolution Service 223 224 225 An artifact resolution service is a SAML protocol binding endpoint controlled by the identity provider that receives requests from a service provider to resolve a SAML artifact into the corresponding assertion in accordance with the Browser/Artifact profile. 226 227 228 The service supports the processing of SAML messages containing elements. Implementations of this service MUST provide for mutual authentication, typically relying on SSL/TLS [RFC 2246] or SAML message signatures. 229 2.3 Service Provider 230 231 232 233 A service provider is an entity that provides a web-based service, application, or resource subject to authorization or customization on the basis of a security context established by means of the SAML Browser/POST or Browser/Artifact profiles. It consists of one or more assertion consumer services, defined by the browser profiles, and may include an attribute requester. 234 235 Note: Previous versions of this specification referred to these components as the "SHIRE" and "SHAR", respectively. 236 237 238 Each service provider MUST be assigned a unique identifier, or providerId. The identifier MUST be a URI [RFC 2396] of no more than 1024 characters. Use of an "https" URL for this purpose may be advantageous for metadata publication (see section 3.4). 239 2.3.1 Assertion Consumer Service 240 241 242 243 An assertion consumer service is an HTTP resource controlled by the service provider that processes form submissions adhering to the SAML Browser/POST profile or HTTP GET requests adhering to the SAML Browser/Artifact profile to establish a new security context for a principal. Assuming this is successful, it eventually redirects the user agent to a resource hosted by the service provider. 244 245 246 247 248 13 14 Note: [SAMLBind] refers to an assertion consumer service that supports the Browser/Artifact profile as an artifact receiver service, but they are treated as equivalent in this specification. A service provider may expose any number of assertion consumer service endpoints. Each endpoint SHOULD be protected by SSL/TLS [RFC 2246]. draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 7 of 19 249 2.3.2 Attribute Requester 250 251 252 253 254 Shibboleth supplements the SAML browser profiles with an out-of-band attribute exchange. A service provider MAY utilize a SAML protocol binding to send SAML messages containing the element to attribute authorities and process the resulting attribute assertions. Implementations MUST provide for mutual authentication of the exchange, typically rely on SSL/TLS [RFC 2246] or SAML message signatures. 255 256 257 258 259 Note that in some environments where privacy is not required, a well-known principal identifier might be communicated in the authentication assertion. This may be done to make the exchange of attributes optional, or to support a non-SAML mechanism such as LDAP to obtain additional information. Also, the authentication assertion MAY itself include elements (or be accompanied by additional assertions that do). 260 261 262 A Shibboleth attribute requester MAY implement support for when submitting queries and processing assertions, but is NOT REQUIRED to do so. That is, it MAY reject assertions containing unsupported confirmation methods. 263 2.4 WAYF 264 265 266 267 268 A WAYF, or "Where are you from?", service is an optional, centralized mechanism for interactively determining a principal's identity provider. A service provider in general has no means to determine this without asking the principal or deriving the information through some user agent interaction. The WAYF is a means for service providers to collectively delegate this step to a separate entity. Service providers are NOT REQUIRED to utilize a WAYF. 269 270 271 272 A WAYF service MUST support the Shibboleth Authentication Request profile defined in section 3.1.1. This is the same profile supported by an identity provider's SSO service. The WAYF acts as a proxy for a service provider and relays the authentication request from the service provider to the SSO service of the selected identity provider. 273 274 275 276 277 278 A WAYF service is free to interact with the principal's user agent in whatever manner it deems appropriate to determine the identity provider to which to relay the authentication request. This includes, but is not limited to, presenting lists, a search interface, heuristics based on client characteristics, etc. A WAYF service SHOULD provide some means for the user agent to cache the user's selection, perhaps using HTTP cookies, but SHOULD also provide reasonable means for the user to change the selection in the future. 15 16 draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 8 of 19 279 3 Protocols and Profiles 280 281 This section defines the message exchanges required of Shibboleth implementations (primarily defined by SAML 1.1), and additional profiles governing the behavior of Shibboleth components. 282 3.1 Authentication Request and Response Profiles 283 284 285 286 287 To establish a security context at a service provider, Shibboleth combines an Authentication Request profile defined in this specification with the SAML 1.1 Browser/POST or Browser/Artifact profiles [SAMLBind]. An identity provider MAY initiate this process without an authentication request by directing the principal's user agent through unspecified means to its inter-site transfer service with sufficient information to create the proper HTTP response. 288 3.1.1 Authentication Request Profile 289 290 291 292 293 A Shibboleth authentication request is a URL-encoded message sent from a service provider (or another entity on its behalf, such as a WAYF service) to an identity provider's single sign-on service endpoint using the principal's user agent. Any means of causing the user agent to access the SSO service endpoint can be used; typically an HTTP redirect is used subsequent to the user agent accessing a secured resource without a valid security context. 294 3.1.1.1 Required Information 295 Identification: urn:mace:shibboleth:1.0:profiles:AuthnRequest 296 Contact Information: shibboleth-dev@internet2.edu 297 Description: Given below. 298 Updates: All earlier technical definitions of the Shibboleth authentication request format 299 3.1.1.2 Message Format and Transmission 300 301 The HTTP request to the identity provider's SSO service endpoint MUST use the GET method and MUST contain the following URL-encoded query string parameters: 302 providerId The unique identifier of the requesting service provider 303 304 shire The assertion consumer service endpoint at the service provider to which to deliver the authentication response 305 306 307 target Returned by the identity provider in the TARGET form control or query string of the authentication response, it MAY be the URL of a resource accessed at the service provider 308 309 310 311 312 313 314 17 18 The query string MAY contain the following optional parameter: time The current time, in seconds elapsed since midnight, January 1st, 1970, as a string of up to 10 base10 digits draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 9 of 19 315 316 317 A WAYF service MUST relay the parameters that it receives from a service provider unchanged to the identity provider that is ultimately selected, except that it MUST replace the time parameter (if present) with a value generated at the time the user agent is redirected to the identity provider's SSO service. 318 3.1.1.3 Processing Rules 319 320 321 The SSO service endpoint MUST process the supplied request and either return an error response to the user agent or attempt to fulfill the request by eventually redirecting the user agent to the inter-site transfer service (assuming such a redirect is necessary). 322 323 324 325 326 327 If an error occurs, the identity provider MAY return a in accordance with the Browser/POST profile that contains a element with a Value other than samlp:Success. If the service provider only supports the use of the Browser/Artifact profile, then it is not possible to return an error indication as the Browser/Artifact profile assumes that any artifact supplied references an actual assertion. (The base SAML profiles presume successful authentication because they are identity-provider-first profiles.) 328 329 330 331 332 When using the Browser/POST profile, the shire parameter is used as the value of the ACTION attribute in the HTML form in the HTTP response returned by the inter-site transfer service, and is also the value placed in the Recipient attribute of the element encoded into the SAMLResponse form control. The target parameter MUST be used as the value of the TARGET form control whether or not an error has occurred. 333 334 335 When using the Browser/Artifact profile, the shire parameter is used as the URL prefix in the Location header in the HTTP redirect response returned by the inter-site transfer service. The target parameter MUST be used as the value of the TARGET query string parameter whether or not an error has occurred. 336 337 338 339 340 The providerId parameter MAY be used by the identity provider to customize the processing of the request based on its knowledge of or relationship with the service provider. Such customization might include, but is not limited to, the format of the principal's identifier to be returned in the assertion(s), the credential to use while signing the message, and the set of attributes to include with the authentication assertion, if any. 341 342 343 344 345 346 Note that if the service provider's identity is used as input to processing the request (which is almost always the case), then the identity provider MUST have some means to establish that the assertion consumer service endpoint in the shire parameter is in fact associated with the requesting service provider. Any mechanism to establish this relationship MAY be used, but some mechanism MUST be used unless the data in the authentication response is invariant with respect to the requesting service provider. The metadata profile described in section 3.4 is RECOMMENDED for this purpose. 347 348 349 350 351 352 Metadata MAY be used to determine the profile to use in returning the authentication response to the service provider. If an element in metadata with a Location attribute corresponding to the shire parameter indicates support for only one of the response profiles (via the Binding attribute), then the identity provider MUST use this profile when returning the authentication response. If it cannot or will not use this profile, then the identity provider MUST return an error message to the user agent. 353 354 355 Finally, the time parameter MAY be used as an indicator of the freshness of the request so that replayed requests, such as might be triggered by navigation of a user agent's history list, can be detected. The parameter MUST NOT be used as part of any security measures. 356 3.1.1.4 Example 357 358 359 https://idp.example.org/SSO?shire=https%3A%2F%2Fsp.example.com%2FShibboleth.shire& target=https%3A%2F%2Fsp.example.com%2Fcgi-bin%2Fcoolstuff.cgi&time=1050540300& providerId=https%3A%2F%2Fsp.example.com%2Fshibboleth%2F 19 20 draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 10 of 19 360 3.1.2 Browser/POST Authentication Response Profile 361 362 363 364 When the Browser/POST profile is used to respond to the service provider, a signed SAML response containing an authentication assertion is delivered directly to the service provider in a form POST operation. The format of the SAML response and the associated processing rules are defined primarily by the SAML Browser/POST profile in [SAMLBind]. 365 366 367 368 An identity provider MAY send a response without having received an authentication request; in such a case, the TARGET form control MUST contain a value expected to be understood by the service provider. In most cases, this SHOULD be the URL of a resource to be accessed at the service provider, but MAY contain other values by prior agreement. 369 370 371 Note that the identity provider MAY supply attributes within the message, at its discretion (this is implicitly permitted by the Browser/POST profile). However, see section 4.1.1 for additional considerations in doing so. The Browser/Artifact profile may be more suitable in such cases. 372 373 As an additional constraint, the Issuer attribute of any assertions included MUST be set to the unique identifier of the identity provider issuing the assertion. 374 375 Finally, any assertions included SHOULD contain a with at least one element containing the unique identifier of the service provider. 376 3.1.2.1 Example 377 The example below shows XML that might be base64-encoded into the SAMLResponse form control. 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 TCDVSuG6grhyHbzhQFWFzGrxIPE= x/GyPbzmFEe85pGD3c1aXG4Vspb9V9jGCjwcRCKrtwPS6vdVNCcY5rHaFPYWkf+5 EIYcPzx+pX1h43SmwviCqXRjRtMANWbHLhWAptaK1ywS7gFgsD01qjyen3CP+m3D w6vKhaqledl0BYyrIzb4KkHO4ahNyBVXbJwqv5pUaE4= MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT MRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoT F1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJ bmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBLSSBTZXJ2ZXIgQ0Eg 21 22 draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 11 of 19 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 LS0gMjAwMjA3MDFBMB4XDTAyMDcyNjA3Mjc1MVoXDTA2MDkwNDA3Mjc1MVowgYsx CzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaWNoaWdhbjESMBAGA1UEBxMJQW5uIEFy Ym9yMQ4wDAYDVQQKEwVVQ0FJRDEcMBoGA1UEAxMTc2hpYjEuaW50ZXJuZXQyLmVk dTEnMCUGCSqGSIb3DQEJARYYcm9vdEBzaGliMS5pbnRlcm5ldDIuZWR1MIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZSAb2sxvhAXnXVIVTx8vuRay+x50z7GJj IHRYQgIv6IqaGG04eTcyVMhoekE0b45QgvBIaOAPSZBl13R6+KYiE7x4XAWIrCP+ c2MZVeXeTgV3Yz+USLg2Y1on+Jh4HxwkPFmZBctyXiUr6DxF8rvoP9W7O27rhRjE pmqOIfGTWQIDAQABox0wGzAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIFoDANBgkq hkiG9w0BAQQFAAOBgQBfDqEW+OI3jqBQHIBzhujN/PizdN7s/z4D5d3pptWDJf2n qgi7lFV6MDkhmTvTqBtjmNk3No7v/dnP6Hr7wHxvCCRwubnmIfZ6QZAv2FU78pLX 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdiowMNTrEG8cCx3w/w== http://sp.example.com/shibboleth 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 urn:oasis:names:tc:SAML:1.0:cm:bearer 462 3.1.3 Browser/Artifact Authentication Response Profile 463 464 465 466 467 When the Browser/Artifact profile is used to respond to the service provider, one or more SAML artifacts are issued to the service provider and transmitted in the query string of an HTTP redirect response. The format of the HTTP response and the associated processing rules are defined primarily by the SAML Browser/Artifact profile in [SAMLBind]. Note that the SAML artifact values returned in the SAMLart query string parameter MUST be URL-encoded. 468 469 The Browser/Artifact profile permits a variety of artifact formats to be used. Two different formats are defined by [SAMLBind], either of which MAY be used in Shibboleth. 470 471 472 473 An identity provider MAY send a response without having received an authentication request; in such a case, the TARGET parameter MUST contain a value expected to be understood by the service provider. In most cases, this SHOULD be the URL of a resource to be accessed at the service provider, but MAY contain other values by prior agreement. 23 24 draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 12 of 19 474 475 Upon receiving the artifact(s), the service provider uses a SAML request/response protocol binding to resolve the artifact(s) into the corresponding SAML assertion(s), in accordance with [SAMLBind]. 476 477 478 479 480 481 482 483 It is RECOMMENDED that service providers enforce a single-use semantic on the artifact values they receive, to prevent an attacker from interfering with the resolution of an artifact by a user agent and then resubmitting it to the service provider. If an attempt to resolve an artifact does not complete successfully, the artifact SHOULD be placed into a blocked artifact list for a period of time that exceeds a reasonable acceptance period during which the identity provider would successfully resolve the artifact. This recommendation is in addition to the existing SAML 1.1 requirement that the identity provider enforce a single-use semantic on artifact values, and matches a recommendation added to SAML 2.0 when using artifacts. 484 485 486 Note that the identity provider MAY supply attributes within the SAML assertions it returns in response to an artifact lookup, at its discretion (this is implicitly permitted by the Browser/Artifact profile). In fact, this is typical when using this profile within Shibboleth. 487 488 As an additional constraint, the Issuer attribute of any assertions returned MUST be set to the unique identifier of the identity provider issuing the assertion. 489 490 Finally, any assertions returned SHOULD contain a with at least one element containing the unique identifier of the service provider. 491 3.1.3.1 Example 492 493 494 The example below shows a redirection URL containing a type 0x0001 SAML artifact that might be returned when using this profile. For examples of the subsequent SOAP-based exchange to obtain the assertion, refer to [SAMLBind]. 495 496 497 https://sp.example.com/Shibboleth.shire?SAMLart=AAH7iBsAkCvNPMBcQlDBx% 2FAlFu8FW8FM5ZapUHYA8Nzz4nr19fBabdCU&TARGET=https%3A%2F%2Fsp.example.com%2Fcgi-bin% 2Fcoolstuff.cgi 498 3.2 Attribute Exchange Profile 499 500 501 502 To support out-of-band attribute exchange from an identity provider to a service provider, Shibboleth specifies the use of the SAML request/response protocol using the element, as defined in [SAMLCore], along with the additional constraints and guidelines defined in this section. 503 3.2.1 Required Information 504 Identification: urn:mace:shibboleth:1.0:profiles:attribute 505 Contact Information: shibboleth-dev@internet2.edu 506 Description: Given below. 507 Updates: All earlier technical definitions of the Shibboleth attribute syntax and exchange conventions 508 3.2.2 Attribute Requests 509 510 An attribute request message is a element containing a element. 511 512 513 Additionally, the Resource attribute in the query MUST contain the requesting service provider's unique identifier. This is used to make up for the lack of an explicit element or attribute in SAML 1.1 to indicate the issuing service provider. 25 26 draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 13 of 19 514 3.2.2.1 Example 515 516 The example shown does not include any surrounding context from the binding, such as a SOAP envelope. 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 533 3.2.3 Attribute Responses 534 535 536 537 538 539 An attribute response is a element containing a element and zero or more elements. The assertion(s), if any, SHOULD contain only attribute statements. The Issuer attribute of any assertions returned MUST be set to the unique identifier of the identity provider whose attribute authority is issuing the assertion. Any assertions returned SHOULD contain a with at least one element containing the unique identifier of the requesting service provider. 540 541 542 As noted in section 2.2.2, Shibboleth attribute authorities MUST implement some form of access control over attribute release. They MAY support unauthenticated queries, but SHOULD limit the release of information in such a case, subject to administrative policy. 543 3.2.3.1 Example 544 545 The example shown does not include any surrounding context from the binding, such as a SOAP envelope. 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 http://sp.example.com/shibboleth 27 28 draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 14 of 19 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 urn:mace:oclc.org:100277910 urn:mace:example.edu:exampleEntitlement urn:mace:incommon:entitlement:common:1 594 3.2.4 Attribute Naming and Syntax 595 596 597 598 599 SAML does not constrain the naming of attributes or the syntax of values. It is RECOMMENDED that Shibboleth attributes be identified with a URI. In such cases, the AttributeName XML attribute MUST contain the URI that identifies the attriibute, and the AttributeNamespace XML attribute SHOULD contain the value urn:mace:shibboleth:1.0:attributeNamespace:uri. It MAY contain a different value by prior agreement. 600 601 602 603 It is also RECOMMENDED that attribute values be expressed, when possible, as a single XML text node within the element, using an XML Schema built-in datatype ([Schema2]). In such cases, the xsi:type XML attribute SHOULD be used to indicate the built-in datatype that describes the allowable syntax of the value. 604 605 606 607 If the value is not from a built-in datatype, the xsi:type attribute MAY be used to indicate the extension type in use, but implementers are cautioned that this may require a relying party to be aware of the extension in order to process the assertion. Omitting the xsi:type attribute is RECOMMENDED in such cases. 608 See the example in section 3.2.3.1. 609 3.3 Transient NameIdentifier Format 610 611 612 SAML identifies principals in assertions using the element, which contains a pair of descriptive XML attributes, Format and NameQualifier. See the examples in the previous sections. 613 614 615 Shibboleth permits any legal SAML name identifier to be used, but also defines a special kind of identifier with the Format value of urn:mace:shibboleth:1.0:nameIdentifier. Identifiers of this format MUST satisfy the following criteria: 616 617 29 30 The identifier has transient semantics and SHOULD be treated as an opaque and temporary value by the relying party. draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 15 of 19 618 619 The identifier MUST be constructed in accordance with the rules for SAML identifiers (see section 1.2.3 of [SAMLCore]) and SHOULD NOT exceed a length of 256 characters. 620 621 622 If present, the NameQualifier attribute MUST be set to the unique identifier of the identity provider that originally created the transient identifier. In a element, the NameQualifier and Issuer attributes MUST be identical. 623 3.4 Metadata Profile 624 625 626 627 628 Editor's Note: This profile has been jointly submitted with Trustgenix, Inc. to the OASIS Security Services Technical Committee for consideration. This section has been adapted to reference and build on the draft submission by specifying only Shibboleth-specific constraints. Accordingly, this section may undergo changes until that submission has reached committee draft status. 629 630 631 SAML profiles (and by extension Shibboleth profiles) require agreements between system entities regarding identifiers, binding/profile support and endpoints, certificates and keys, and so forth. A metadata specification is useful for describing this information in a standardized way. 632 633 634 635 636 637 Although SAML 1.1 did not include such a specification, SAML 2.0 includes a metadata specification in [SAML2Meta]. Subsequently, a profile of this specification was developed for use by SAML 1.1 deployments (see [SAML1Meta]). Shibboleth identity and service providers SHOULD describe their characteristics using this profile. When doing so, specific use of these elements MUST adhere to the profile defined in [SAML1Meta]. Additional guidelines and processing rules pertaining to Shibboleth are specified below. 638 3.4.1 Element 639 640 Multiple Shibboleth entities can be collected into groups using the element. The Name XML attribute, if present, SHOULD be a URI. 641 3.4.2 Element 642 643 644 A Shibboleth identity or service provider SHOULD be represented by an element. If used, there MUST be exactly one element for each provider and the unique identifier of the provider MUST be placed in the entityID XML attribute. 645 646 647 Role elements defined by this profile applicable to Shibboleth include , , , and . 648 649 650 If a URL is used as the unique identifier of an entity, it is RECOMMENDED that resolving this URL produce a SAML metadata document containing a single representing that entity. 651 652 653 Note that metadata can vary based on the relying party in question. Resolving an identifier into metadata MAY require authentication of the requester so as to produce the metadata response appropriate for that relying party. 654 3.4.3 Element 655 656 A Shibboleth identity provider MUST include the element in its metadata. The protocolSupportEnumeration XML attribute MUST include at least the values: 31 32 draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 16 of 19 657 658 659 660 661 urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0 At least one element MUST be present. At least one of the elements' Binding XML attribute MUST contain the value: urn:mace:shibboleth:1.0:profiles:AuthnRequest 662 663 The location specified in its Location XML attribute MUST support the Authentication Request profile defined in section 3.1.1. 664 3.4.4 Element 665 666 667 668 A Shibboleth identity provider that supports an authentication authority service as described in section 2.2.1 MUST include the element in its metadata if it supports lookup of assertions by SAML query or identifier. The protocolSupportEnumeration XML attribute MUST include at least the value: 669 urn:oasis:names:tc:SAML:1.1:protocol 670 3.4.5 Element 671 672 673 A Shibboleth identity provider that supports an attribute authority service as described in section 2.2.2 MUST include the element in its metadata. The protocolSupportEnumeration XML attribute MUST include at least the value: 674 urn:oasis:names:tc:SAML:1.1:protocol 675 3.4.6 Element 676 677 A Shibboleth service provider MUST include the element in its metadata. The protocolSupportEnumeration XML attribute MUST include at least the value: 678 33 34 urn:oasis:names:tc:SAML:1.1:protocol draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 17 of 19 679 4 Security and Privacy Considerations 680 681 As Shibboleth is principally a set of SAML profiles, the general security and privacy considerations that apply to SAML apply to Shibboleth (see [SAMLSecure]). 682 4.1 Additional Browser Profile Considerations 683 4.1.1 Information Leakage and Impersonation 684 685 686 The SAML browser profiles contain a presumption that they are initiated by an identity provider. Assertion information (or an artifact) is therefore sent through the browser to service providers using locations known to be appropriate and secure. 687 688 689 690 691 692 693 The use of the Authentication Request profile defined in section 3.1.1 introduces the possibility of a malicious entity impersonating another service provider by identifying itself as one provider while indicating that the authentication response be delivered to the attacker instead. In the case of the POST profile, this can result in unintended leakage of personally identifying information contained within the assertion(s). In the case of the Artifact profile, the attacker could potentially impersonate the principal by immediately submitting the artifact(s) to the real service provider, who can subsequently authenticate to the identity provider to obtain the assertion. 694 695 696 697 To mitigate both attacks, it is critical for the identity provider to securely associate the assertion consumer service location to be used with the service provider to whom the assertion(s) or artifact(s) are issued. A digital signature over the authentication request would be an alternate countermeasure, but this is not supported by the Authentication Request profile. 698 699 700 701 702 Another source of information leakage is the target parameter sent with the Authentication Request URL and returned in both Browser profiles. This parameter is informally associated with the resource URL being requested from the service provider, but it is in fact potentially opaque to the identity provider. Exposing the resource URL releases unnecessary information about the principal's activities to the identity provider and possibly various log files. 703 704 705 706 It is therefore RECOMMENDED that service providers utilize some kind of obfuscation, mapping, encryption, or other mechanism to prevent the exposure of resource URLs in plaintext in this parameter. Alternately, service providers MAY use a fixed value in that parameter, and maintain the state associated with the request (such as the eventual resource URL) locally by using HTTP cookies. 707 708 709 710 711 712 713 714 Finally, when user privacy in service provider interactions is a consideration or requirement, Shibboleth provides an explicit mechanism for effective anonymity through the use of a transient identifier (see section 3.3), provided that the SAML attributes supplied in conjunction with or subsequent to it are sufficiently generic so as not to inadvertently narrow down or identify the principal. It is important to avoid facilitating coordination by one or more service providers in correlating the principal's activity by insuring that a different transient identifier is used across time and space. Therefore, it is RECOMMENDED that a given transient identifier not be used more than once in assertions issued by an identity provider for a principal in different executions of the Browser/POST or Browser/Artifact profiles. 715 4.1.2 Time Synchronization 716 717 718 719 720 The Browser/POST profile relies on tight synchronization of clocks between the identity and service providers to limit the usefulness of the bearer assertion. Additionally, assertions may be issued with expiration conditions that cannot be effectively honored if clock skew is excessive. Therefore, it is RECOMMENDED that secure time sources be used to maintain clock synchronization within the bounds usually associated with protocols like Kerberos (i.e., on the order of 5 minutes or less). 35 36 draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 18 of 19 721 5 References 722 The following works are referenced directly or indirectly in the body of this specification. 723 5.1 Normative References 724 725 [RFC 2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt. 726 727 [RFC 2246] T. Dierks, C. Allen. The TLS Protocol Version 1.0. IETF RFC 2246, January 1999. http://www.ietf.org/rfc/rfc2246.txt. 728 729 [RFC 2396] T. Berners-Lee et al. Uniform Resource Identifiers (URI): Generic Syntax. IETF RFC 2396, August, 1998. http://www.ietf.org/rfc/rfc2396.txt. 730 731 732 [SAMLCore] E. Maler et al. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML). OASIS, September 2003. Document ID oasis-sstc-saml-core1.1. http://www.oasis-open.org/committees/security/. 733 734 735 [SAMLBind] E. Maler et al. Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML). OASIS, September 2003. Document ID oasis-sstc-samlbindings-profiles-1.1. http://www.oasis-open.org/committees/security/. 736 737 738 [SAML-XSD] E. Maler et al. SAML assertion schema. OASIS, September 2003. Document ID oasis-sstc-saml-schema-assertion-1.1. http://www.oasisopen.org/committees/security/. 739 740 741 [SAMLP-XSD] E. Maler et al. SAML protocol schema. OASIS, September 2003. Document ID oasis-sstc-saml-schema-protocol-1.1. http://www.oasisopen.org/committees/security/. 742 743 744 745 [SAMLSecure] E. Maler et al. Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML). OASIS, September 2003. Document ID oasis-sstc-saml-sec-consider-1.1. http://www.oasisopen.org/committees/security/. 746 747 748 [SAML2Meta] S. Cantor et al., Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, March 2005. Document ID sstc-saml-metadata-2.0. See http://www.oasis-open.org/committees/security/. 749 750 751 [SAMLMeta-xsd] S. Cantor et al., SAML metadata schema. OASIS SSTC, March 2005. Document ID sstc-saml-schema-metadata-2.0. See http://www.oasisopen.org/committees/security/. 752 753 754 [SAML1Meta] G. Whitehead and S. Cantor, SAML 1.x Metadata Profile. OASIS SSTC, February 2005. Document ID draft-saml1x-metadata-04. See http://www.oasisopen.org/committees/security/. 755 756 [Schema2] P. V. Biron et al. XML Schema Part 2: Datatypes. World Wide Web Consortium Recommendation, May 2001. http://www.w3.org/TR/xmlschema-2/. 757 5.2 Non-Normative References 758 759 760 [SAML2Gloss] J. Hodges et al., Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, March 2005. Document ID sstc-saml-glossary-2.0. See http://www.oasis-open.org/committees/security/. 761 762 763 [LibertyProt] J. Kemp et al., Liberty Protocols and Schema Specification Version 1.2, Liberty Alliance Project, August 2004, http://www.projectliberty.org/specs/v1_2/libertyarchitecture-protocols-schema-v1.2.pdf. 37 38 draft-mace-shibboleth-arch-protocols-09 28 February 2005 Page 19 of 19