1 Shibboleth Architecture 2 Technical Overview 3 Working Draft 02, 8 June 2005 4 5 Document identifier: 6 7 Location: draft-mace-shibboleth-tech-overview-02 http://shibboleth.internet2.edu/shibboleth-documents.html 8 9 10 Editors: 11 12 Contributors: 13 14 15 16 17 Abstract: Tom Scavo (trscavo@ncsa.uiuc.edu), NCSA Scott Cantor (cantor.2@osu.edu), The Ohio State University Nathan Dors (dors@cac.washington.edu), University of Washington This non-normative document gives a technical overview of Shibboleth. 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-tech-overview-02 8 June 2005 Page 1 of 31 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 Table of Contents 1 2 3 4 5 6 7 Introduction................................................................................................................... 3 1.1 Background .......................................................................................................... 3 1.2 Notation ................................................................................................................ 3 1.3 Outline .................................................................................................................. 4 Shibboleth Components.............................................................................................. 5 2.1 Identity Provider................................................................................................... 5 2.1.1 Authentication Authority .................................................................................. 5 2.1.2 Single Sign-On Service ................................................................................... 5 2.1.3 Inter-Site Transfer Service.............................................................................. 5 2.1.4 Artifact Resolution Service.............................................................................. 5 2.1.5 Attribute Authority ............................................................................................ 6 2.2 Service Provider .................................................................................................. 6 2.2.1 Assertion Consumer Service .......................................................................... 6 2.2.2 Attribute Requester.......................................................................................... 6 2.3 WAYF Service...................................................................................................... 6 SAML Assertions ......................................................................................................... 7 3.1 Authentication Assertions ................................................................................... 7 3.2 Attribute Assertions ............................................................................................. 9 3.3 Multiple Assertions .............................................................................................. 9 3.4 Signed Assertions...............................................................................................11 Shibboleth SSO Profiles.............................................................................................13 4.1 Authentication Request Profile..........................................................................13 4.2 Browser/POST Profile ........................................................................................13 4.2.1 Browser/POST Profile with WAYF Service ..................................................15 4.3 Browser/Artifact Profile ......................................................................................17 4.3.1 Browser/Artifact Profile with WAYF Service.................................................20 Attributes......................................................................................................................21 5.1 Browser/POST Profile with Attribute Exchange ..............................................21 5.2 Browser/Artifact Profile with Attribute Exchange .............................................23 5.3 Directory Schema ...............................................................................................24 Metadata......................................................................................................................26 6.1 Identity Provider Metadata.................................................................................26 6.1.1 SSO Service Metadata...................................................................................27 6.1.2 Attribute Authority Metadata ..........................................................................28 6.2 Service Provider Metadata ................................................................................29 6.2.1 Assertion Consumer Service Metadata........................................................29 References ..................................................................................................................31 7.1 Normative References .......................................................................................31 7.2 Non-Normative References ...............................................................................31 draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 2 of 31 59 60 61 62 63 1 Introduction 64 65 66 67 68 69 70 71 72 1.1 Background 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 1.2 Notation The Shibboleth Architecture [ShibProt] extends the SAML 1.1 single sign-on and attribute exchange mechanisms by specifying service-provider-first SSO profiles and enhanced features for user privacy. This document provides a technical overview of Shibboleth and as such is an extension of [SAMLTech]. The Shibboleth Architecture is built upon the following standards: • Hypertext Transfer Protocol (HTTP) • Extensible Markup Language (XML) • XML Schema • XML Signature • SOAP1 • Security Assertion Markup Language (SAML) Definitive references for each of these standards are found in section 7 of this Overview. Conventional XML namespace prefixes are used throughout the listings in this Overview, whether or not a namespace declaration is present in the listing: • 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 • The prefix xsi: stands for the W3C XML Schema namespace for schema-related markup that appears in XML instances: http://www.w3.org/2001/XMLSchema-instance The following typographical conventions for displayed text are used: HTTP requests appear like this. HTTP responses appear like this. HTML code listings appear like this. JavaScript code listings appear like this. XML code listings appear like this. SAML code listings appear like this. 1 Originally, SOAP was an acronym for "Simple Object Access Protocol", but this turned out to be a misnomer since SOAP has nothing to do with "object access" in the object-oriented programming sense of the phrase. So today we no longer think of "SOAP" as an acronym although the capitalization persists. draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 3 of 31 96 97 98 99 100 101 URNs appear like this. URLs appear like this. 102 103 104 105 106 107 108 109 110 1.3 Outline Likewise the following typographical conventions for in-line text are used: , , XMLattribute, HTMLattribute, LDAPattribute, HTTPparameter, OtherCode. Finally, variable placeholders in code fragments (both displayed and in-line) are italicized (e.g., artifact). Immediately following this introduction, in section 2 we describe the components comprising the Shibboleth System. Section 3 is a general introduction to Security Assertion Markup Language (SAML) with special emphasis on those SAML constructs used by Shibboleth. In section 4, the Shibboleth browser profiles are described in detail, while the Shibboleth attribute profiles are outlined in section 5. Also in section 5, we emphasize the importance of directory schema using eduPerson as the canonical example of a directory in higher education. An introduction to SAML metadata is given in section 6, and finally in section 7 we provide a list of definitive references for further study. draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 4 of 31 111 112 113 114 2 Shibboleth Components 115 116 117 118 119 2.1 Identity Provider The functional components of a conforming Shibboleth implementation include an identity provider, a service provider, an optional “Where are you from?” (WAYF) service, and various interacting subcomponents. An identity provider (formerly called an origin) maintains user credentials and attributes. Upon request the identity provider (IdP) will assert authentication statements or attribute statements to relying parties, specifically service providers. IdP subcomponents are depicted in Figure 1 and discussed in the following subsections. Identity Provider 120 121 Authentication Authority Attribute Authority SSO Service Artifact Resolution Service Figure 1: Shibboleth Identity Provider 122 123 124 125 2.1.1 Authentication Authority 126 127 128 129 130 131 2.1.2 Single Sign-On Service 132 133 134 135 136 137 138 2.1.3 Inter-Site Transfer Service 139 140 141 2.1.4 Artifact Resolution Service The authentication authority issues authentication statements to other components. The authentication authority is integrated with the IdP's authentication service (the details of which are out of scope). A single sign-on (SSO) service is the first point of contact at the IdP. The SSO service initiates the authentication process at the IdP and ultimately redirects the client to the intersite transfer service (unless the function of the SSO service and inter-site transfer service are combined, which is encouraged). Note: The SSO service is not defined by SAML 1.1, which specifies only identity-provider-first SSO profiles. The inter-site transfer service issues HTTP responses conforming to the Browser/POST and Browser/Artifact profiles. The inter-site transfer service interacts with the authentication authority behind the scenes to produce the required authentication assertion. Note: The concept of an inter-site transfer service has been removed in SAML 2.0, so we assume that the functions of the SSO service and the inter-site transfer service are combined, and therefore ignore the latter in all that follows. If the Browser/Artifact profile is used, the IdP sends an artifact to the SP instead of the actual assertion. (An artifact is a reference to an authentication assertion.) The SP then sends the draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 5 of 31 142 143 artifact to the artifact resolution service at the IdP via a back-channel exchange. In return, the IdP sends the required authentication assertion to the SP. 144 145 146 2.1.5 Attribute Authority 147 148 149 150 151 2.2 Service Provider The attribute authority processes attribute requests; that is, it issues attribute assertions. The attribute authority authenticates and authorizes any requests it receives. A service provider (formerly called a target) manages secured resources. User access to resources is based on assertions received by the service provider (SP) from an identity provider. SP subcomponents are shown in Figure 2. Note that the service provider has access control in place that prevents access by clients without a security context. Service Provider Access Control Assertion Consumer Service 152 153 Attribute Requester Target Resource Figure 2: Shibboleth Service Provider 154 155 156 157 158 159 2.2.1 Assertion Consumer Service 160 161 162 163 2.2.2 Attribute Requester 164 165 166 167 168 2.3 WAYF Service The assertion consumer service (formerly called a SHIRE) is the service provider endpoint of the SSO exchange. It processes the authentication assertion returned by the SSO service (or artifact resolution service, depending on the profile used), initiates an optional attribute request (see section 5), establishes a security context at the SP, and redirects the client to the desired target resource. An attribute requester (formerly called a SHAR) at the SP and the attribute authority at the IdP may conduct a back-channel attribute exchange once a security context has been established at the SP. That is, the SP and IdP interact directly, bypassing the browser. An optional WAYF service is operated independent of the SP and IdP. The WAYF can be used by the SP to determine the user's preferred IdP, with or without user interaction. The WAYF is essentially a proxy for the authentication request passed from the SP to the SSO service at the IdP. draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 6 of 31 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 3 SAML Assertions 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 3.1 Authentication Assertions This section provides some background material on SAML assertions that sets the stage for the profiles to follow. In Shibboleth, SAML assertions are transferred from identity providers to service providers. Assertions contain statements that service providers can use to make access control decisions. Three types of statements are specified by SAML: 1. Authentication statements 2. Attribute statements 3. Authorization decision statements Authentication statements assert to the service provider that the principal did indeed authenticate with the identity provider at a particular time using a particular method of authentication. The examples in section 3.1, for instance, are assertions containing authentication statements typically used in the Browser/POST and Browser/Artifact profiles (section 4), respectively. Attribute statements provide additional information about a principal so that service providers can make access control decisions. For example, the attribute assertion given in section 3.2 is the result of the attribute exchange described in section 5.1. Authentication statements and attribute statements may be combined in a single assertion. Alternatively, multiple assertions may be issued by the IdP, each containing its own statement. A variation of the Browser/Artifact profile (section 5.2), for instance, relies on a pair of assertions, both obtained as the result of a single message exchange. The example in section 3.3 illustrates the corresponding pair of assertions. In some situations, it may be preferable for the application to delegate an access control decision to another component or service. In this case, the service provider indicates to the service the resource being accessed where after the service asserts an authorization decision statement that dictates whether or not the principal is allowed access to the resource. In Shibboleth, such statements are out of scope, but the interested reader is referred to [GSIsecurity] for a relevant example. Finally, SAML assertions may be digitally signed. An XML element such as that given in section 3.4 is inserted into those assertions where additional message integrity is required. The following authentication assertion (sometimes called an SSO assertion) contains a element (but no attributes): http://sp.example.org/shibboleth 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 urn:oasis:names:tc:SAML:1.0:cm:bearer The value of the element in the preceding example is called a Shibboleth handle: an opaque, transient identifier associated with the authenticated user. Further messages regarding this user (such as the one in the next section) explicitly refer to this handle instead of the actual identity of the user. Note that the above assertion (called a bearer assertion) assigns the following value to the element: urn:oasis:names:tc:SAML:1.0:cm:bearer Whereas the preceding assertion is used in the Browser/POST profile (section 4.2), the following assertion is used in the Browser/Artifact profile (section 4.3): http://sp.example.org/shibboleth user@idp.example.org urn:oasis:names:tc:SAML:1.0:cm:artifact draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 8 of 31 270 271 272 273 274 275 276 277 In this case, the value of the element is 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 3.2 Attribute Assertions 313 314 315 316 317 318 3.3 Multiple Assertions urn:oasis:names:tc:SAML:1.0:cm:artifact which indicates the Browser/Artifact profile was used to retrieve the assertion. Some use cases require more than an opaque identifier, so for the sake of illustration the value of the element in the preceding example is an email address. Presumably this uniquely identifies the authenticated user to the SP. Note that an authentication assertion may include additional information about the subject, such as attributes. The following attribute assertion contains a element only: http://sp.example.org/shibboleth 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 userid Note that the value of the element is the same as that in the first example in section 3.1, which implies that the attribute statement is obtained subsequent to and as a consequence of the previous authentication statement. The following pair of assertions contain and elements, respectively: http://sp.example.org/shibboleth 082dd87d-f380-4fd6-8726-694ef2bb71e9 urn:oasis:names:tc:SAML:1.0:cm:artifact http://sp.example.org/shibboleth 082dd87d-f380-4fd6-8726-694ef2bb71e9 member draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 10 of 31 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 faculty urn:mace:oclc.org:100277910 https://sp.example.org/entitlements/123456789 urn:mace:incommon:entitlement:common:1 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 3.4 Signed Assertions Many SAML assertions, especially assertions that pass through a browser, are digitally signed (see section 5 of [SAMLCore]). Here we give an example of a element (with visual formatting, which invalidates the signature) used to sign the authentication assertion obtained via the Browser/POST profile in section 4.2: TCDVSuG6grhyHbzhQFWFzGrxIPE= x/GyPbzmFEe85pGD3c1aXG4Vspb9V9jGCjwcRCKrtwPS6vdVNCcY5rHaFPYWkf+5 EIYcPzx+pX1h43SmwviCqXRjRtMANWbHLhWAptaK1ywS7gFgsD01qjyen3CP+m3D w6vKhaqledl0BYyrIzb4KkHO4ahNyBVXbJwqv5pUaE4= draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 11 of 31 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT MRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoT F1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJ bmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBLSSBTZXJ2ZXIgQ0Eg LS0gMjAwMjA3MDFBMB4XDTAyMDcyNjA3Mjc1MVoXDTA2MDkwNDA3Mjc1MVowgYsx CzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaWNoaWdhbjESMBAGA1UEBxMJQW5uIEFy Ym9yMQ4wDAYDVQQKEwVVQ0FJRDEcMBoGA1UEAxMTc2hpYjEuaW50ZXJuZXQyLmVk dTEnMCUGCSqGSIb3DQEJARYYcm9vdEBzaGliMS5pbnRlcm5ldDIuZWR1MIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZSAb2sxvhAXnXVIVTx8vuRay+x50z7GJj IHRYQgIv6IqaGG04eTcyVMhoekE0b45QgvBIaOAPSZBl13R6+KYiE7x4XAWIrCP+ c2MZVeXeTgV3Yz+USLg2Y1on+Jh4HxwkPFmZBctyXiUr6DxF8rvoP9W7O27rhRjE pmqOIfGTWQIDAQABox0wGzAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIFoDANBgkq hkiG9w0BAQQFAAOBgQBfDqEW+OI3jqBQHIBzhujN/PizdN7s/z4D5d3pptWDJf2n qgi7lFV6MDkhmTvTqBtjmNk3No7v/dnP6Hr7wHxvCCRwubnmIfZ6QZAv2FU78pLX 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdiowMNTrEG8cCx3w/w== SAML metadata elements are also signed. The examples in section 6, for instance, implicitly include a element similar to the one above. draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 12 of 31 451 452 453 454 455 456 457 4 Shibboleth SSO Profiles 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 4.1 Authentication Request Profile 487 488 489 490 491 492 4.2 Browser/POST Profile Shibboleth specifies two browser-based single sign-on (SSO) profiles: 1. Browser/POST Profile 2. Browser/Artifact Profile These profiles extend the SAML 1.1 profiles of the same name [SAMLBind]. While the SAML 1.1 profiles begin with a request to the IdP, the Shibboleth profiles are serviceprovider-first and therefore more complex. To accommodate SP-first profiles, Shibboleth introduces the notion of an authentication request. A Shibboleth authentication request is a URL-encoded message sent to an SSO service endpoint at the IdP. The following parameters are included in the query string: • providerId The providerId parameter is the unique identifier (usually a URI) of the SP. The IdP may use the providerId to perform special handling or processing of the authentication request. • shire The shire parameter (so named for historical reasons) is the location of the assertion consumer service endpoint at the SP. When using the Browser/POST profile, this URL becomes the value of the
element's action attribute. For the Browser/Artifact profile, the value of the shire parameter is a prefix of the redirect URL used by the SSO service. • target The target parameter is a state maintenance parameter, possibly the location of the target resource. Regardless of the profile used, the target parameter must be preserved by the IdP and included in the response to the SP. • time The (optional) time parameter is the current time in seconds past the epoch. It is used to assist the IdP in detecting stale requests from the client. It is important that the time parameter not be used as any kind of security measure. Here is an example of a Shibboleth authentication request (without URL encoding for clarity): https://idp.example.org/shibboleth/SSO? target=https://sp.example.org/myresource& shire=https://sp.example.org/shibboleth/SSO& providerId=https://sp.example.org/shibboleth& time=1102260120 Detailed handling of this request is outlined in the subsections below. The Shibboleth Browser/POST profile is a combination of two profiles, the Shibboleth Authentication Request profile [ShibProt] and the SAML 1.1 Browser/POST profile [SAMLBind]. The message flow associated with the Shibboleth Browser/POST profile is depicted in Figure 3. As with both Shibboleth SSO profiles, the message flow begins with a request for a secured resource at the SP. draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 13 of 31 Identity Provider Authentication Authority (4) 200 SSO Service Client (3) GET (6) 302 Assertion Consumer Service (5) POST (7) GET (2) 302 (1) GET 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 Access Control (8) 200 Target Resource Service Provider Figure 3: Shibboleth Browser/POST Profile (1) The client requests a target resource at the SP: https://sp.example.org/myresource The SP performs a security check on behalf of the target resource. If a valid security context at the SP already exists, skip steps 2–7. (2) The SP redirects the client to the single sign-on (SSO) service at the IdP. Three parameters are appended to the redirect URL (the optional time parameter is omitted in this example). (3) The client requests the SSO service at the IdP: https://idp.example.org/shibboleth/SSO? target=https://sp.example.org/myresource& shire=https://sp.example.org/shibboleth/SSO/POST& providerId=https://sp.example.org/shibboleth The SSO service processes the authentication request and performs a security check. If the user does not have a valid security context, the IdP identifies the principal (details omitted). Once the principal has been identified, the SSO service obtains an authentication statement from the authentication authority. (4) The SSO service responds with a document containing an HTML form: draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 14 of 31 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 ...
543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 4.2.1 Browser/POST Profile with WAYF Service The value of the TARGET parameter has been preserved from step 3. The value of the SAMLResponse parameter is the base64 encoding of a digitally signed element such as the one below: (5) The client issues a POST request to the assertion consumer service at the SP. To automate the submission of the form, the following line of JavaScript (or its equivalent) may appear in the HTML document containing the form in step 4: window.onload = function() { document.forms[0].submit(); } This assumes that the page contains a single HTML
element. (6) The assertion consumer service processes the authentication response, creates a security context at the SP and redirects the client to the target resource. (7) The client requests the target resource at the SP (again): https://sp.example.org/myresource (8) Since a security context exists, the SP returns the resource to the client. In general, the SP does not know the user's preferred IdP at step 2 of the Browser/POST profile. The process whereby the SP determines the appropriate IdP is called identity provider discovery (generally, a very difficult problem). Shibboleth specifies an (optional) WAYF service to aid the SP in IdP discovery. A WAYF ("Where are you from?") service is an intermediary between the SP and the IdP. The SP sends its authentication request to the WAYF, which somehow determines the user's preferred IdP (through unspecified means) and then subsequently redirects the client to the desired IdP. In the process, the WAYF preserves the values of all parameters except the time parameter, which is updated. In practice, the first time the client accesses an SP, the WAYF might present the user with a form containing a list of all available IdPs. The user selects an IdP from the list and submits the form, after which the WAYF redirects the client to the selected IdP. At the same time, the client stores a reference to the IdP in a client-side cookie such that subsequent visits to the same SP are redirected straight through to the corresponding IdP by the WAYF. As a hypothetical example, suppose that a WAYF service resides at domain example.org and that the SP redirects the client to this WAYF as follows: https://wayf.example.org/? target=https://sp.example.org/myresource& shire=https://sp.example.org/shibboleth/SSO/POST& providerId=https://sp.example.org/shibboleth In response, the WAYF returns a form to the client with the following elements: draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 15 of 31 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 ...
Presumably the form contains additional controls that allow the user to select an IdP, after which the form is submitted to the WAYF. The WAYF processes the form, sets the cookie and redirects the client to the selected IdP. The message flow of the Shibboleth Browser/POST profile with WAYF service is outlined in Figure 4. (The flow of the corresponding Browser/Artifact profile is similar.) In step 4 of that flow, the WAYF returns an HTML form to the user who chooses an IdP from a list. After the form is submitted at step 5, the client is redirected to the SSO service of the chosen IdP where after the flow is identical to the ordinary Browser/POST profile. Identity Provider Authentication Authority (8) 200 SSO Service (7) GET (6) 302 Client (5) GET (4) 200 WAYF (3) GET (10) 302 Assertion Consumer Service (9) POST (11) GET (2) 302 (1) GET Access Control (12) 200 Target Resource Service Provider 583 draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 16 of 31 584 Figure 4: Shibboleth Browser/POST Profile with WAYF Service 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 (1) The client requests a target resource at the SP: 625 626 627 628 4.3 Browser/Artifact Profile https://sp.example.org/myresource The SP performs a security check on behalf of the target resource. If a valid security context at the SP already exists, skip steps 2–11. (2) The SP redirects the client to the WAYF. Three parameters are appended to the redirect URL (the optional time parameter is omitted in this example). (3) The client requests the WAYF service: https://wayf.example.org/? target=https://sp.example.org/myresource& shire=https://sp.example.org/shibboleth/SSO/POST& providerId=https://sp.example.org/shibboleth The WAYF service processes the authentication request and performs a cookie check. If the user has the required cookie, skip steps 4 and 5. Otherwise an HTML form is returned to the client. (4) The WAYF returns an HTML form to the client. The parameters of the authentication request (shown in the previous step) are encoded as hidden fields in the form as illustrated above. (5) The user selects an IdP from the list and submits the form, which causes the browser to issue a GET request to the WAYF. (Depending on the particular WAYF implementation, multiple HTTP transactions may occur at this step.) (6) The WAYF updates the cookie with the user’s preferred IdP and redirects the client to the SSO service. Three parameters are appended to the redirect URL. (7) The client requests the SSO service at the IdP: https://idp.example.org/shibboleth/SSO? target=https://sp.example.org/myresource& shire=https://sp.example.org/shibboleth/SSO/POST& providerId=https://sp.example.org/shibboleth The SSO service processes the authentication request and performs a security check. If the user does not have a valid security context, the IdP identifies the principal (details omitted). Once the principal has been identified, the SSO service obtains an authentication statement from the authentication authority. (8) The SSO service responds with an HTML form as in step 4 of the ordinary Browser/POST profile. (9) The client issues a POST request to the assertion consumer service at the service provider as in step 5 of the ordinary Browser/POST profile. (10) The assertion consumer service processes the authentication response, creates a security context at the SP and redirects the client to the target resource. (11) The client requests the target resource at the SP (again): https://sp.example.org/myresource (12) Since a security context exists, the SP returns the resource to the client. The Shibboleth Browser/Artifact profile is a combination of the Shibboleth Authentication Request [ShibProt] profile and the SAML 1.1 Browser/Artifact profile [SAMLBind]. The message flow associated with the Shibboleth Browser/Artifact profile is shown in Figure 5. draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 17 of 31 629 630 Note the back-channel exchange of the SAML artifact in steps 6 and 7. This is the distinguishing characteristic between the Browser/Artifact and Browser/POST profiles. Identity Provider Authentication Authority Attribute Authority SSO Service Artifact Resolution Service (7) 200 (6) POST (4) 302 Client (3) GET (8) 302 Assertion Consumer Service (5) GET (9) GET (2) 302 (1) GET 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 Access Control (10) 200 Target Resource Service Provider Figure 5: Shibboleth Browser/Artifact Profile (1) The client requests a target resource at the SP: https://sp.example.org/myresource The SP performs a security check on behalf of the target resource. If a valid security context at the SP already exists, skip steps 2–9. (2) The SP redirects the client to the single sign-on (SSO) service at the IdP. Three parameters are appended to the redirect URL (the optional time parameter is omitted in this example). (3) The client requests the SSO service at the IdP: https://idp.example.org/shibboleth/SSO? target=https://sp.example.org/myresource& shire=https://sp.example.org/shibboleth/SSO/Artifact& providerId=https://sp.example.org/shibboleth The SSO service processes the authentication request and performs a security check. If the user does not have a valid security context, the IdP identifies the principal (details omitted). Once the principal has been identified, the SSO service obtains an authentication statement from the authentication authority. (4) The SSO service redirects the client to the assertion consumer service at the SP. A TARGET parameter and a SAMLart parameter are appended to the redirect URL prefix given by the shire parameter in step 3. draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 18 of 31 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 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 (5) The client requests the assertion consumer service at the SP: https://sp.example.org/shibboleth/SSO/Artifact? TARGET=https://sp.example.org/myresource& SAMLart=AAEwGDwd3Z7Fr1GPbM82Fk2CZbpNB1dxD%2Bt2Prp%2BTDtqxVA78iMf3F23 where the value of the TARGET parameter is preserved from step 3 and the value of the SAMLart parameter is a SAML artifact of type 0x0001 defined in [SAMLBind]. (6) The assertion consumer service validates the request and dereferences the artifact by sending a SAML Request to the artifact resolution service at the IdP: POST /shibboleth/Artifact HTTP/1.1 Host: idp.example.org Content-Type: text/xml Content-Length: nnn SOAPAction: http://www.oasis-open.org/committees/security AAEwGDwd3Z7Fr1GPbM82Fk2CZbpNB1dxD+t2Prp+TDtqxVA78iMf3F23 where the value of the element is the SAML artifact at step 5. (7) The artifact resolution service at the IdP returns a element (containing an authentication statement) to the assertion consumer service at the SP: HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 19 of 31 705 706 707 708 709 710 711 712 713 714 715 716 717 4.3.1 Browser/Artifact Profile with WAYF Service (8) The assertion consumer service processes the authentication response, creates a security context at the SP and redirects the client to the target resource. (9) The client requests the target resource at the SP (again): https://sp.example.org/myresource (10) Since a security context exists, the SP returns the resource to the client. Like the Browser/POST profile, an SP that supports the Browser/Artifact profile may also utilize the services of a WAYF. The resulting Browser/Artifact profile with WAYF service is analogous to the Browser/POST case (section 4.2.1). draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 20 of 31 718 719 720 721 722 723 724 725 5 Attributes 726 727 728 729 730 5.1 Browser/POST Profile with Attribute Exchange Shibboleth specifies the use of a standard SAML attribute request protocol to facilitate attribute sharing among IdPs and SPs. In this section we augment the SSO profiles of sections 4.2 and 4.3 with an attribute exchange that permits the SP to make an informed access control decision. Such an attribute exchange is optional since the SP may choose to provide a security context based solely on an authentication assertion. In practice, however, the SP may need to know more about the authenticated user before access to a resource may be granted. Although attributes may be embedded in the authentication assertion transferred from IdP to SP, Shibboleth specifies an optional back-channel exchange using a SAML protocol binding such as the SOAP 1.1 binding. The attribute exchange is a simple two-step process initiated towards the end of the ordinary Browser/POST profile (see Figure 6). Identity Provider Authentication Authority Attribute Authority (4) 200 SSO Service Client (3) GET (7) 200 (8) 302 Assertion Consumer Service (5) POST (6) POST Attribute Requester (9) GET (2) 302 (1) GET 731 732 733 734 735 736 737 Access Control (10) 200 Target Resource Service Provider Figure 6: Shibboleth Browser/POST Profile with Attribute Exchange The first five steps of the ordinary Browser/POST profile proceed as before. Before access to the resource is granted, however, an attribute exchange is required. (1–5) Same as the ordinary Browser/POST profile. (6) The assertion consumer service parses the POST request, validates the signature on the element, creates a security context at the SP and passes control to the draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 21 of 31 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 attribute requester to initiate the attribute exchange. The attribute requester POSTs a SAML SOAP message to the attribute authority (AA) at the IdP: POST /shibboleth/AA/SOAP HTTP/1.1 Host: idp.example.org Content-Type: text/xml Content-Length: nnn SOAPAction: http://www.oasis-open.org/committees/security 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 (7) The AA at the IdP processes the request and returns the required attributes to the attribute requester: HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 22 of 31 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 5.2 Browser/Artifact Profile with Attribute Exchange (8) The assertion consumer service filters the attributes, updates the security context and redirects the client to the target resource. (9) The client requests the target resource at the SP (again): https://sp.example.org/myresource (10) Since a security context exists, the SP returns the resource to the client. Recall that the Browser/Artifact profile of section 4.3 incorporates its own back-channel exchange to dereference the artifact. To obtain attributes, an additional back-channel exchange might be used (as in section 5.1). Alternatively, attributes could be retrieved at the same time the artifact is dereferenced, which we illustrate in this section. The resulting flow is identical to the previous flow associated with the Browser/Artifact profile (see Figure 5). As observed in section 3, an attribute statement may be combined with an authentication statement in one of two ways: both statements may be wrapped in a single assertion or separate assertions may contain individual statements. The latter approach is illustrated here. Two assertions require two artifacts, which is the primary difference between this example and the example of section 4.3. Steps 4–7 of the latter example are modified for two artifacts as follows: (1–3) Same as the ordinary Browser/Artifact profile. (4) The SSO service redirects the client to the assertion consumer service at the SP. A TARGET parameter and two SAMLart parameters are appended to the redirect URL. (5) The client requests the assertion consumer service at the SP: https://sp.example.org/shibboleth/SSO/Artifact? TARGET=https://sp.example.org/myresource& SAMLart=AAEwGDwd3Z7Fr1GPbM82Fk2CZbpNB7YuJ8gk%2BvmCjh9Y4Wsq6H5%2BKU4C& SAMLart=AAEwGDwd3Z7Fr1GPbM82Fk2CZbpNB8tb%2By6YOO40XGfl4QfLKq9xZ8UW where one of the artifacts references an authentication assertion while the other artifact corresponds to an attribute assertion (order does not matter). (6) The assertion consumer service validates the request and dereferences both artifacts by sending a single SAML Request to the artifact resolution service at the IdP: POST /shibboleth/Artifact HTTP/1.1 Host: idp.example.org Content-Type: text/xml Content-Length: nnn SOAPAction: http://www.oasis-open.org/committees/security draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 23 of 31 843 844 845 846 847 848 849 850 851 852 853 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 AAEwGDwd3Z7Fr1GPbM82Fk2CZbpNB7YuJ8gk+vmCjh9Y4Wsq6H5+KU4C AAEwGDwd3Z7Fr1GPbM82Fk2CZbpNB8tb+y6YOO40XGfl4QfLKq9xZ8UW 880 881 882 883 884 885 886 887 888 889 890 891 892 5.3 Directory Schema where the values of the elements are the SAML artifacts at step 5. (7) The artifact resolution service at the IdP returns a element (containing two assertions) to the assertion consumer service at the SP: HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn (8–10) Same as the ordinary Browser/Artifact profile. Shibboleth, by virtue of SAML, has a well-defined attribute exchange mechanism, but neither specification defines any attributes per se. Instead it is left to individual implementations to define their own attributes. In a cross-domain federated environment, in particular, a standard approach to user attributes is crucial. In the absence of such standards, federation on a large scale will be difficult if not impossible. To address this issue within the higher education community, Internet2 and EDUCAUSE have jointly developed a set of attributes and associated bindings called eduPerson [eduPerson]. The LDAP binding of eduPerson is derived from the standard LDAP object class called inetOrgPerson [RFC 2798] which itself is based on other standard LDAP classes (see e.g., [RFC 2256]). Of all the attributes defined by this hierarchy of object classes, approximately 40 attributes have been defined by InCommon as common identity attributes [InCommonAttribs]: draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 24 of 31 Common Attributes Highly recommended 6 Suggested 10 Optional 25 41 893 894 895 896 For example, here are InCommon's six "highly recommended" attributes: Attribute Name Attribute Value givenName Mary sn (surname) Smith cn (common name) Mary Smith eduPersonScopedAffiliation student@idp.example.org eduPersonPrincipalName mary.smith@idp.example.org eduPersonTargetedID — The attribute eduPersonTargetedID does not have a precise value syntax. See the EduPerson Specification [eduPersonSpec] for more information about eduPersonTargetedID. draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 25 of 31 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 6 Metadata 931 932 933 934 935 936 937 938 939 940 941 942 943 6.1 Identity Provider Metadata Both IdPs and SPs publish information about themselves in special XML files called metadata files. Since metadata precisely identify the provider and the services it offers, metadata files are digitally signed for integrity protection. A SAML metadata specification was first published as part of SAML 2.0 [SAML2Meta]. Since that time, the OASIS Security Services Technical Committee has considered adopting a minimal subset of SAML 2.0 metadata for use with SAML 1.x as specified in [SAMLMeta]. Shibboleth further constrains this profile in [ShibProt]. Only four metadata descriptors are defined for use within Shibboleth: 1. 2. 3. 4. These metadata elements correspond to the SSO service (IdP), the assertion consumer service (SP), the authentication authority (IdP), and the attribute authority (IdP), respectively. We will omit the element in what follows since the authentication authority operates behind the scenes in a typical Shibboleth deployment, in which case it need not publish metadata about itself. Multiple elements may be grouped together in a single element: Note that an element may be signed (see section 3.4). Alternatively, the individual elements may be signed (see the examples in the following subsections). An identity provider publishes data about itself in an element: Shibboleth Identity Provider draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 26 of 31 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 Shibboleth Identity Provider @ Some Location http://www.idp.example.org/ Shibboleth IdP Support shib-support@idp.example.org 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 6.1.1 SSO Service Metadata The entityID attribute is the unique providerId of the IdP. Note that the details of the digital signature (in the element) have been omitted from this example. See section 3.4 for relevant discussion. The IdP manages an SSO service and an attribute authority, each having its own descriptor. These are detailed in the following subsections. The SSO service at the IdP is encapsulated in an element: IdP SSO Key urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress urn:mace:shibboleth:1.0:nameIdentifier The previous metadata element describes the SSO service at the IdP of section 4. Note the following details about this element: • Since Shibboleth supports an SSO service (whereas SAML1 does not), protocol support includes the URI urn:mace:shibboleth:1.0 • • which is a unique identifier specified by [ShibProt]. Key information has been omitted for brevity. The Binding attribute of the element indicates that the SAML SOAP binding should be used (see [SAMLBind]). draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 27 of 31 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 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 • • • The Location attribute of the element is used in step 6 of the Browser/Artifact profile of section 4.3. The index attribute of the element is ignored. The elements indicate what SAML NameIdentifier formats [SAMLCore] the SSO service supports. One of these is a standard Shibboleth handle indicated by URI urn:mace:shibboleth:1.0:nameIdentifier • • The Binding attribute of the element is a unique identifier specified by [ShibProt]. The Location attribute of the element is used by SPs and WAYFs to redirect the client to the SSO service at the IdP. 6.1.2 Attribute Authority Metadata The attribute authority at the IdP is given by an element: IdP AA Key member student faculty employee staff urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress urn:mace:shibboleth:1.0:nameIdentifier This element is not needed for the SSO profiles of section 4, but it is required for the attribute exchanges outlined in sections 5.1 and 5.2. draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 28 of 31 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 6.2 Service Provider Metadata 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 6.2.1 Assertion Consumer Service Metadata A service provider also publishes data about itself in an element: Shibboleth Service Provider Shibboleth Service Provider @ Some Location http://www.sp.example.org/ Shibboleth SP Support shib-support@sp.example.org The primary component managed by the SP is the assertion consumer service, which is discussed below. The assertion consumer service is represented by an element: SP SSO Key urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress urn:mace:shibboleth:1.0:nameIdentifier draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 29 of 31 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 Service Provider Portal https://sp.example.org/entitlements/123456789 Note the following details about the metadata element: • • • Key information has been omitted for brevity. The Binding attributes of the elements are standard URIs specified by [SAMLMeta]. The Location attribute of the first element (index=”0”) is used in step 3 of the Browser/POST profile in section 4.2. • The Location attribute of the second element (index=”1”) is used in step 3 of the Browser/Artifact profile in section 4.3. • The element is used by the IdP to formulate an attribute assertion that is pushed to the SP in step 7 of the Browser/Artifact profile outlined in section 5.2. The index attributes of the and elements are ignored. • As noted above, the values of the Location attribute are the same as the values of the shire parameter in the corresponding profile. Upon receiving the authentication request, the IdP checks the value of the shire parameter against the locations in SP metadata, which minimizes the possibility of a rogue SP orchestrating a man-in-the-middle attack. draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 30 of 31 1128 7 References 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 7.1 Normative References 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 7.2 Non-Normative References [eduPersonSpec] EduPerson Specification (200312), http://www.nmiedit.org/eduPerson/internet2-mace-dir-eduperson-200312.html [RFC 2256] M. Wahl, A Summary of the X.500(96) User Schema for use with LDAPv3, December 1997. http://www.ietf.org/rfc/rfc2256.txt [RFC 2798] M. Smith, Definition of the inetOrgPerson LDAP Object Class, April 2000. http://www.ietf.org/rfc/rfc2798.txt [SAML2Meta] S. Cantor et al., Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, 15 March 2005. Document ID saml-metadata-2.0-os http://www.oasis-open.org/committees/security/ [SAMLBind] E. Maler et al., Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML). OASIS, September 2003. Document ID oasis-sstc-saml-bindings-profiles1.1 http://www.oasis-open.org/committees/security/ [SAMLCore] E. Maler et al., Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML). OASIS, September 2003. Document ID oasis-sstc-saml-core-1.1 http://www.oasis-open.org/committees/security/ [SAMLMeta] G. Whitehead and S. Cantor, SAML 1.x Metadata Profile. OASIS SSTC, February 2005. Document ID draft-saml1x-metadata-04 http://www.oasisopen.org/committees/security/ [ShibProt] S. Cantor et al., Shibboleth Architecture: Protocols and Profiles. Internet2-MACE, February 2005. Document ID draft-mace-shibboleth-arch-protocols-09 http://shibboleth.internet2.edu/ [SOAP] D. Box et al., Simple Object Access Protocol (SOAP) 1.1. W3C Note 08 May 2000. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ [eduPerson] eduPerson Object Class. http://www.educause.edu/eduperson/ [HTTP] HTTP - Hypertext Transfer Protocol. World Wide Web Consortium (W3C). http://www.w3.org/Protocols/ [InCommonAttribs] InCommon Federation: Common Identity Attributes. http://www.incommonfederation.org/docs/policies/federatedattributes.html [GSIsecurity] K. Bhatia et al., Engineering an End-to-End GSI-based Security Infrastructure. http://users.sdsc.edu/~chandras/Papers/ccgrid-submission.pdf [SAMLTech] J. Hughes et al. Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1. OASIS, May 2004. Document ID sstc-saml-tech-overview-1.1-cd http://www.oasis-open.org/committees/security/ [XML] XML Core Working Group Public Page. World Wide Web Consortium (W3C). http://www.w3.org/XML/Core/ [XMLSchema] XML Schema. World Wide Web Consortium (W3C). http://www.w3.org/XML/Schema [XMLSig] XML Signature WG. World Wide Web Consortium (W3C). http://www.w3.org/Signature/ draft-mace-shibboleth-tech-overview-02 8 June 2005 Page 31 of 31