idnits 2.17.1 draft-ietf-oauth-saml2-bearer-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 23, 2011) is 4712 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 B. Campbell, Ed. 3 Internet-Draft Ping Identity Corp. 4 Intended status: Standards Track C. Mortimore 5 Expires: November 24, 2011 Salesforce.com 6 May 23, 2011 8 SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 9 draft-ietf-oauth-saml2-bearer-04 11 Abstract 13 This specification defines the use of a SAML 2.0 Bearer Assertion as 14 means for requesting an OAuth 2.0 access token. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on November 24, 2011. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 52 2. SAML Assertion Access Token Request . . . . . . . . . . . . . 4 53 2.1. Client Requests Access Token . . . . . . . . . . . . . . . 4 54 2.2. Assertion Format and Processing Requirements . . . . . . . 5 55 2.3. Error Response . . . . . . . . . . . . . . . . . . . . . . 7 56 2.4. Example (non-normative) . . . . . . . . . . . . . . . . . 7 57 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 59 4.1. Parameter Registration Request . . . . . . . . . . . . . . 9 60 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 9 61 Appendix B. Document History . . . . . . . . . . . . . . . . . . 10 62 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 5.1. Normative References . . . . . . . . . . . . . . . . . . . 12 64 5.2. Informative References . . . . . . . . . . . . . . . . . . 12 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 67 1. Introduction 69 The Security Assertion Markup Language (SAML) 2.0 70 [OASIS.saml-core-2.0-os] is an XML-based framework that allows 71 identity and security information to be shared across security 72 domains. The SAML specification, while primarily targeted at 73 providing cross domain Web browser single sign-on, was also designed 74 to be modular and extensible to facilitate use in other contexts. 76 The Assertion, an XML security token, is a fundamental construct of 77 SAML that is often adopted for use in other protocols and 78 specifications. An Assertion is generally issued by an identity 79 provider and consumed by a service provider who relies on its content 80 to identify the Assertion's subject for security related purposes. 82 The OAuth 2.0 Authorization Protocol [I-D.ietf.oauth-v2] provides a 83 method for making authenticated HTTP requests to a resource using an 84 access token. Access tokens are issued to third-party clients by an 85 authorization server (AS) with the (sometimes implicit) approval of 86 the resource owner. In OAuth, an authorization grant is an abstract 87 term used to describe intermediate credentials that represent the 88 resource owner authorization. An authorization grant is used by the 89 client to obtain an access token. 91 Several authorization grant types are defined to support a wide range 92 of client types and user experiences. OAuth also allows for the 93 definition of new extension grant types to support additional clients 94 or to provide a bridge between OAuth and other trust frameworks. 96 This specification defines an extension grant type that profiles the 97 use of a SAML 2.0 Bearer Assertion in requesting an OAuth 2.0 access 98 token. The format and processing rules for the SAML Assertion 99 defined in this specification are intentionally similar, though not 100 identical, to those in the Web Browser SSO Profile defined in SAML 101 Profiles [OASIS.saml-profiles-2.0-os]. This specification is 102 reusing, to the extent reasonable, concepts and patterns from that 103 well-established Profile. 105 1.1. Notational Conventions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 Unless otherwise noted, all the protocol parameter names and values 112 are case sensitive. 114 2. SAML Assertion Access Token Request 116 A SAML Assertion can be used to request an access token when a client 117 wishes to utilize an existing trust relationship, expressed through 118 the semantics of (and digital signature calculated over) the SAML 119 Assertion, without a direct user approval step at the authorization 120 server. 122 The process by which the client obtains the SAML Assertion, prior to 123 exchanging it with the authorization server, is out of scope. 125 +--------+ +---------------+ 126 | | | | 127 | |>--(A)-- SAML 2.0 Assertion ----->| Authorization | 128 | Client | | Server | 129 | |<--(B)---- Access Token ---------<| | 130 | | | | 131 +--------+ +---------------+ 133 Figure 1: Assertion Access Token Request 135 The request/response flow illustrated in Figure 1 includes the 136 following steps: 138 (A) The client sends an access token request to the authorization 139 server that includes a SAML 2.0 Assertion and a grant_type of 140 "http://oauth.net/grant_type/saml/2.0/bearer". 142 (B) The authorization server validates the Assertion per the 143 processing rules defined in this specification and issues an 144 access token. 146 2.1. Client Requests Access Token 148 The client includes the Assertion in the access token request, the 149 core details of which are defined in OAuth [I-D.ietf.oauth-v2], by 150 specifying "http://oauth.net/grant_type/saml/2.0/bearer" as the 151 absolute URI value of the "grant_type" parameter and by adding the 152 following parameter: 154 assertion 155 REQUIRED. The value of the assertion parameter MUST contain a 156 single SAML 2.0 Assertion. When used with the 157 "http://oauth.net/grant_type/saml/2.0/bearer" grant type, the 158 assertion MUST be a SAML 2.0 Assertion. The SAML Assertion XML 159 data MUST be encoded using base64url, where the encoding 160 adheres to the definition in Section 5 of RFC4648 [RFC4648] and 161 where the padding bits are set to zero. To to avoid the need 162 for subsequent encoding steps (by "application/ 163 x-www-form-urlencoded" [W3C.REC-html401-19991224], for 164 example), the base64url encoded data SHOULD NOT be line wrapped 165 and pad characters ("=") SHOULD NOT be included. 167 scope 168 OPTIONAL. The scope of the access request expressed as a list 169 of space-delimited, case sensitive strings. The value is 170 defined by the authorization server. If the value contains 171 multiple space-delimited strings, their order does not matter, 172 and each string adds an additional access range to the 173 requested scope. 175 Authorization servers SHOULD issue access tokens with a limited 176 lifetime and require clients to refresh them by requesting a new 177 access token using the same assertion, if it is still valid, or with 178 a new assertion. The authorization server SHOULD NOT issue a refresh 179 token. 181 2.2. Assertion Format and Processing Requirements 183 Prior to issuing an access token response as described in 184 [I-D.ietf.oauth-v2], the authorization server MUST validate the 185 Assertion according to the criteria below. If present, the 186 authorization server MUST also validate the client credentials. 187 Application of additional restrictions and policy are at the 188 discretion of the authorization server. 190 o The Assertion's element MUST contain a unique identifier 191 for the entity that issued the Assertion. The Format attribute 192 MUST be omitted or have a value of 193 "urn:oasis:names:tc:SAML:2.0:nameid-format:entity". 195 o The Assertion MUST contain a element. The subject MAY 196 identify the resource owner for whom the access token is being 197 requested. 199 o The element MUST contain at least one 200 element that allows the authorization server 201 to confirm it as a Bearer Assertion. Conditions for bearer 202 subject confirmation are described below. 204 * The MUST have a Method attribute with a 205 value of "urn:oasis:names:tc:SAML:2.0:cm:bearer" and MUST 206 contain a element. 208 * The element MUST have a Recipient 209 attribute with a value indicating the token endpoint URL of the 210 authorization server. The authorization server MUST verify 211 that the value of the Recipient attribute matches the token 212 endpoint URL (or an acceptable alias) to which the Assertion 213 was delivered. 215 * The element MUST have a NotOnOrAfter 216 attribute that limits the window during which the Assertion can 217 be confirmed. The authorization server MUST verify that the 218 NotOnOrAfter instant has not passed, subject to allowable clock 219 skew between systems. The authorization server MAY ensure that 220 Bearer Assertions are not replayed, by maintaining the set of 221 used ID values for the length of time for which the Assertion 222 would be considered valid based on the NotOnOrAfter attribute 223 in the . The authorization server MAY 224 reject assertions with a NotOnOrAfter instant that is 225 unreasonably far in the future. 227 * The element MAY also contain an 228 Address attribute limiting the client address from which the 229 Assertion can be delivered. Verification of the Address is at 230 the discretion of the authorization server. 232 o If the Assertion issuer authenticated the subject, the Assertion 233 SHOULD contain a single representing that 234 authentication event. 236 o If the Assertion was issued with the intention that the client act 237 autonomously on behalf of the subject, an SHOULD 238 NOT be included. The client SHOULD be identified in the 239 or similar element, the element, or by other 240 available means like [OASIS.saml-deleg-cs]. 242 o Other statements, in particular elements, MAY 243 be included in the Assertion. 245 o The Assertion MUST contain an element with 246 an element containing a URI reference that identifies 247 the authorization server, or the service provider SAML entity of 248 its controlling domain, as an intended audience. The 249 authorization server MUST verify that it is an intended audience 250 for the Assertion. 252 o The Assertion MUST be digitally signed by the issuer and the 253 authorization server MUST verify the signature. 255 o Encrypted elements MAY appear in place of their plain text 256 counterparts as defined in [OASIS.saml-core-2.0-os]. 258 o The authorization server MUST verify that the Assertion is valid 259 in all other respects per [OASIS.saml-core-2.0-os], such as (but 260 not limited to) evaluating all content within the Conditions 261 element including the NotOnOrAfter and NotBefore attributes, 262 rejecting unknown condition types, etc. 264 2.3. Error Response 266 If the Assertion is not valid, or its subject confirmation 267 requirements cannot be met, the authorization server MUST construct 268 an error response as defined in [I-D.ietf.oauth-v2]. The value of 269 the error parameter MUST be the "invalid_grant" error code. The 270 authorization server MAY include additional information regarding the 271 reasons the Assertion was considered invalid using the 272 error_description or error_uri parameters. 274 For example: 276 HTTP/1.1 400 Bad Request 277 Content-Type: application/json 278 Cache-Control: no-store 280 { 281 "error":"invalid_grant", 282 "error_description":"Audience validation failed" 283 } 285 2.4. Example (non-normative) 287 Though non-normative, the following examples illustrate what a 288 conforming Assertion and access token request would look like. 290 Below is an example SAML 2.0 Assertion (whitespace formatting is for 291 display purposes only): 293 297 https://saml-idp.example.com 298 299 [...omitted for brevity...] 300 301 302 304 brian@example.com 305 306 308 311 312 313 314 315 https://saml-sp.example.net 316 317 318 319 320 321 urn:oasis:names:tc:SAML:2.0:ac:classes:X509 322 323 324 325 327 Figure 2: Example SAML 2.0 Assertion 329 To present the Assertion shown in the previous example as part of an 330 access token request, for example, the client might make the 331 following HTTPS request (line breaks are for display purposes only): 333 POST /token.oauth2 HTTP/1.1 334 Host: authz.example.net 335 Content-Type: application/x-www-form-urlencoded 337 grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F 338 bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM 339 [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 341 Figure 3: Example Request 343 3. Security Considerations 345 No additional considerations beyond those described within the OAuth 346 2.0 Protocol Framework [I-D.ietf.oauth-v2] and in the Security and 347 Privacy Considerations for the OASIS Security Assertion Markup 348 Language (SAML) V2.0 [OASIS.saml-sec-consider-2.0-os]. 350 4. IANA Considerations 352 4.1. Parameter Registration Request 354 The following is the parameter registration request, as defined in 355 The OAuth Parameters Registry of The OAuth 2.0 Authorization Protocol 356 [I-D.ietf.oauth-v2], for the "assertion" parameter: 358 o Parameter name: assertion 360 o Parameter usage location: token request 362 o Change controller: IETF 364 o Specification document(s): draft-ietf-oauth-saml2-bearer 366 Appendix A. Contributors 368 The following people contributed wording and concepts to this 369 document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran 370 Hammer-Lahav, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten 371 Lodderstedt, Susan Harper, Scott Cantor, and David Waite 373 Appendix B. Document History 375 [[ to be removed by RFC editor before publication as an RFC ]] 377 draft-ietf-oauth-saml2-bearer-04 379 o Changed the grant_type URI from 380 "http://oauth.net/grant_type/assertion/saml/2.0/bearer" to 381 "http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word 382 assertion from the path. Recent versions of draft-ietf-oauth-v2 383 no longer refer to extension grants using the word assertion so 384 this URI is more reflective of that. It also more closely aligns 385 with the grant type URI in draft-jones-oauth-jwt-bearer-00 which 386 is "http://oauth.net/grant_type/jwt/1.0/bearer". 388 o Added "case sensitive" to scope definition to align with 389 draft-ietf-oauth-v2-15/16. 391 o Updated to reference draft-ietf-oauth-v2-16 393 draft-ietf-oauth-saml2-bearer-03 395 o Cleanup of some editorial issues. 397 draft-ietf-oauth-saml2-bearer-02 399 o Added scope parameter with text copied from draft-ietf-oauth-v2-12 400 (the reorg of draft-ietf-oauth-v2-12 made it so scope wasn't 401 really inherited by this spec anymore) 403 o Change definition of the assertion parameter to be more generally 404 applicable per the suggestion near the end of 405 http://www.ietf.org/mail-archive/web/oauth/current/msg05253.html 407 o Editorial changes based on feedback 409 draft-ietf-oauth-saml2-bearer-01 411 o Update spec name when referencing draft-ietf-oauth-v2 (The OAuth 412 2.0 Protocol Framework -> The OAuth 2.0 Authorization Protocol) 414 o Update wording in Introduction to talk about extension grant types 415 rather than the assertion grant type which is a term no longer 416 used in OAuth 2.0 418 o Updated to reference draft-ietf-oauth-v2-12 and denote as work in 419 progress 421 o Update Parameter Registration Request to use similar terms as 422 draft-ietf-oauth-v2-12 and remove Related information part 424 o Add some text giving discretion to AS on rejecting assertions with 425 unreasonably long validity window. 427 draft-ietf-oauth-saml2-bearer-00 429 o Added Parameter Registration Request for "assertion" to IANA 430 Considerations. 432 o Changed document name to draft-ietf-oauth-saml2-bearer in 433 anticipation of becoming a OAUTH WG item. 435 o Attempt to move the entire definition of the 'assertion' parameter 436 into this draft (it will no longer be defined in OAuth 2 Protocol 437 Framework). 439 draft-campbell-oauth-saml-01 441 o Updated to reference draft-ietf-oauth-v2-11 and reflect changes 442 from -10 to -11. 444 o Updated examples. 446 o Relaxed processing rules to allow for more than one 447 SubjectConfirmation element. 449 o Removed the 'MUST NOT contain a NotBefore attribute' on 450 SubjectConfirmationData. 452 o Relaxed wording that ties the subject of the Assertion to the 453 resource owner. 455 o Added some wording about identifying the client when the subject 456 hasn't directly authenticated including an informative reference 457 to SAML V2.0 Condition for Delegation Restriction. 459 o Added a few examples to the language about verifying that the 460 Assertion is valid in all other respects. 462 o Added some wording to the introduction about the similarities to 463 Web SSO in the format and processing rules 465 o Changed the grant_type (was assertion_type) URI from 466 http://oauth.net/assertion_type/saml/2.0/bearer to 467 http://oauth.net/grant_type/assertion/saml/2.0/bearer 469 o Changed title to include "Grant Type" in it. 471 o Editorial updates based on feedback from the WG and others 472 (including capitalization of Assertion when referring to SAML). 474 draft-campbell-oauth-saml-00 476 o Initial I-D 478 5. References 480 5.1. Normative References 482 [I-D.ietf.oauth-v2] 483 Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, "The 484 OAuth 2.0 Authorization Protocol", 485 ID draft-ietf-oauth-v2-16 (work in progress), May 2011. 487 [OASIS.saml-core-2.0-os] 488 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 489 "Assertions and Protocol for the OASIS Security Assertion 490 Markup Language (SAML) V2.0", OASIS Standard saml-core- 491 2.0-os, March 2005. 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 497 Encodings", RFC 4648, October 2006. 499 5.2. Informative References 501 [OASIS.saml-deleg-cs] 502 Cantor, S., Ed., "SAML V2.0 Condition for Delegation 503 Restriction", Nov 2009. 505 [OASIS.saml-profiles-2.0-os] 506 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 507 P., Philpott, R., and E. Maler, "Profiles for the OASIS 508 Security Assertion Markup Language (SAML) V2.0", OASIS 509 Standard OASIS.saml-profiles-2.0-os, March 2005. 511 [OASIS.saml-sec-consider-2.0-os] 512 Hirsch, F., Philpott, R., and E. Maler, "Security and 513 Privacy Considerations for the OASIS Security Markup 514 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 515 2.0-os, March 2005. 517 [W3C.REC-html401-19991224] 518 Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01 519 Specification", World Wide Web Consortium 520 Recommendation REC-html401-19991224, December 1999, 521 . 523 Authors' Addresses 525 Brian Campbell (editor) 526 Ping Identity Corp. 528 Email: brian.d.campbell@gmail.com 530 Chuck Mortimore 531 Salesforce.com 533 Email: cmortimore@salesforce.com