idnits 2.17.1 draft-ietf-oauth-saml2-bearer-01.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 (January 28, 2011) is 4808 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: August 1, 2011 Salesforce.com 6 January 28, 2011 8 SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 9 draft-ietf-oauth-saml2-bearer-01 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 August 1, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 5.1. Normative References . . . . . . . . . . . . . . . . . . . 11 64 5.2. Informative References . . . . . . . . . . . . . . . . . . 12 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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 for 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. 75 The Assertion, an XML security token, is a fundamental construct of 76 SAML that is often adopted for use in other protocols and 77 specifications. An Assertion is generally issued by an identity 78 provider and consumed by a service provider who relies on its content 79 to identify the Assertion's subject for security related purposes. 81 The OAuth 2.0 Authorization Protocol [I-D.ietf.oauth-v2] provides a 82 method for making authenticated HTTP requests to a resource using an 83 access token. Access tokens are issued to third-party clients by an 84 authorization server (AS) with the (sometimes implicit) approval of 85 the resource owner. In OAuth, an authorization grant is an abstract 86 term used to describe intermediate credentials that represent the 87 resource owner authorization. An authorization grant is used by the 88 client to obtain an access token. Several authorization grant types 89 are defined to support a wide range of client types and user 90 experiences. OAuth also allows for the definition of new extension 91 grant types in companion specifications (such as this one) to support 92 additional clients or to provide a bridge between OAuth and other 93 trust frameworks. 95 This specification defines an extension grant type that profiles the 96 use of a SAML 2.0 bearer Assertion in requesting an OAuth 2.0 access 97 token. The format and processing rules for the SAML Assertion 98 defined in this specification are intentionally similar, though not 99 identical, to those in the Web Browser SSO Profile defined in 100 [OASIS.saml-profiles-2.0-os] reusing, to the extent reasonable, 101 concepts and patterns from that well-established profile. 103 1.1. Notational Conventions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 Unless otherwise noted, all the protocol parameter names and values 110 are case sensitive. 112 2. SAML Assertion Access Token Request 114 A SAML Assertion can be used to request an access token when a client 115 wishes to utilize an existing trust relationship, expressed though 116 the semantics of (and digital signature calculated over) the SAML 117 Assertion, without a direct user approval step at the authorization 118 server. 120 The process by which the client obtains the SAML Assertion, prior to 121 exchanging it with the authorization server, is out of scope. 123 +--------+ +---------------+ 124 | | | | 125 | |>--(A)-- SAML 2.0 Assertion ----->| Authorization | 126 | Client | | Server | 127 | |<--(B)---- Access Token ---------<| | 128 | | | | 129 +--------+ +---------------+ 131 Figure 1: Assertion Access Token Request 133 The request/response flow illustrated in Figure 1 includes the 134 following steps: 136 (A) The client sends an access token request to the authorization 137 server with the appropriate OAuth grant_type and includes a SAML 138 2.0 Assertion. 140 (B) The authorization server validates the Assertion per the 141 processing rules defined in this specification and issues an 142 access token. 144 2.1. Client Requests Access Token 146 The client includes the Assertion in the access token request, the 147 core details of which are defined in OAuth [I-D.ietf.oauth-v2], by 148 specifying "http://oauth.net/grant_type/assertion/saml/2.0/bearer" as 149 the absolute URI value of the "grant_type" parameter and by adding 150 the following parameter: 152 assertion 153 REQUIRED. The value of the assertion parameter MUST contain a 154 single SAML 2.0 Assertion. The SAML Assertion XML data MUST be 155 encoded using base64url, where the encoding adheres to the 156 definition in Section 5 of RFC4648 [RFC4648] and where the 157 padding bits are set to zero. To to avoid the need for 158 subsequent encoding steps (by "application/ 159 x-www-form-urlencoded" [W3C.REC-html401-19991224], for 160 example), the base64url encoded data SHOULD NOT be line wrapped 161 and pad characters ("=") SHOULD NOT be included. 163 Authorization servers SHOULD issue access tokens with a limited 164 lifetime and require clients to refresh them by requesting a new 165 access token using the same assertion, if it is still valid, or with 166 a new assertion. The authorization server SHOULD NOT issue a refresh 167 token. 169 2.2. Assertion Format and Processing Requirements 171 Prior to issuing an access token response as described in 172 [I-D.ietf.oauth-v2], the authorization server MUST validate the 173 Assertion according to the criteria below. If present, the 174 authorization server MUST also validate the client credentials. 175 Application of additional restrictions and policy are at the 176 discretion of the authorization server. 178 o The Assertion's element MUST contain a unique identifier 179 for the entity that issued the Assertion; the Format attribute 180 MUST be omitted or have a value of 181 "urn:oasis:names:tc:SAML:2.0:nameid-format:entity". 183 o The Assertion MUST contain a element. The subject MAY 184 identify the resource owner for whom the access token is being 185 requested. 187 o The element MUST contain at least one 188 element that allows the authorization server 189 to confirm it as a bearer Assertion. Conditions for bearer 190 subject confirmation are described below. 192 * The MUST have a Method attribute with a 193 value of "urn:oasis:names:tc:SAML:2.0:cm:bearer" and MUST 194 contain a element. 196 * The element MUST have a Recipient 197 attribute with a value indicating the token endpoint URL of the 198 authorization server. The authorization server MUST verify 199 that the value of the Recipient attribute matches the token 200 endpoint URL (or an acceptable alias) to which the Assertion 201 was delivered. 203 * The element MUST have a NotOnOrAfter 204 attribute that limits the window during which the Assertion can 205 be confirmed. The authorization server MUST verify that the 206 NotOnOrAfter instant has not passed, subject to allowable clock 207 skew between systems. The authorization server MAY ensure that 208 bearer Assertions are not replayed, by maintaining the set of 209 used ID values for the length of time for which the Assertion 210 would be considered valid based on the NotOnOrAfter attribute 211 in the . The authorization server MAY 212 reject assertions with a NotOnOrAfter instant that is 213 unreasonably far in the future. 215 * The element MAY also contain an 216 Address attribute limiting the client address from which the 217 Assertion can be delivered. Verification of the Address is at 218 the discretion of the authorization server. 220 o If the Assertion issuer authenticated the subject, the Assertion 221 SHOULD contain a single representing that 222 authentication event. 224 o If the Assertion was issued with the intention that the client act 225 autonomously on behalf of the subject, an SHOULD 226 NOT be included. The client SHOULD be identified in the 227 or similar element the element or by other 228 available means like [OASIS.saml-deleg-cs]. 230 o Other statements, in particular, elements MAY 231 be included in the Assertion. 233 o The Assertion MUST contain an element with 234 an element containing a URI reference that identifies 235 the authorization server, or the service provider SAML entity of 236 its controlling domain, as an intended audience. The 237 authorization server MUST verify that it is an intended audience 238 for the Assertion. 240 o The Assertion MUST be digitally signed by the issuer and the 241 authorization server MUST verify the signature. 243 o Encrypted elements MAY appear in place of their plain text 244 counterparts as defined in [OASIS.saml-core-2.0-os]. 246 o The authorization server MUST verify that the Assertion is valid 247 in all other respects per [OASIS.saml-core-2.0-os] such as (but 248 not limited to) evaluating all content within the Conditions 249 element including the NotOnOrAfter and NotBefore attributes, 250 rejecting unknown condition types, etc. 252 2.3. Error Response 254 If the Assertion is not valid, or its subject confirmation 255 requirements cannot be met, the the authorization server MUST 256 construct an error response as defined in [I-D.ietf.oauth-v2]. The 257 value of the error parameter MUST be the "invalid_grant" error code. 258 The authorization server MAY include additional information regarding 259 the reasons the Assertion was considered invalid using the 260 error_description or error_uri parameters. 262 For example: 264 HTTP/1.1 400 Bad Request 265 Content-Type: application/json 266 Cache-Control: no-store 268 { 269 "error":"invalid_grant", 270 "error_description":"Audience validation failed" 271 } 273 2.4. Example (non-normative) 275 Though non-normative, the following examples illustrate what a 276 conforming Assertion and access token request would look like. 278 Below is an example SAML 2.0 Assertion (whitespace formatting is for 279 display purposes only): 281 285 https://saml-idp.example.com 286 287 [...omitted for brevity...] 288 289 290 292 brian@example.com 293 294 296 299 300 301 302 303 https://saml-sp.example.net 304 305 306 307 308 309 urn:oasis:names:tc:SAML:2.0:ac:classes:X509 310 311 312 313 315 Figure 2: Example SAML 2.0 Assertion 317 To present the Assertion shown in the previous example as part of an 318 access token request, for example, the client might make the 319 following HTTPS request (line breaks are for display purposes only): 321 POST /token.oauth2 HTTP/1.1 322 Host: authz.example.net 323 Content-Type: application/x-www-form-urlencoded 325 grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fassertion%2F 326 saml%2F2.0%2Fbearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ 327 [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 329 Figure 3: Example Request 331 3. Security Considerations 333 No additional considerations beyond those described within the OAuth 334 2.0 Protocol Framework [I-D.ietf.oauth-v2] and in the Security and 335 Privacy Considerations for the OASIS Security Assertion Markup 336 Language (SAML) V2.0 [OASIS.saml-sec-consider-2.0-os]. 338 4. IANA Considerations 340 4.1. Parameter Registration Request 342 The following is the parameter registration request, as defined in 343 The OAuth Parameters Registry of The OAuth 2.0 Authorization Protocol 344 [I-D.ietf.oauth-v2], for the "assertion" parameter: 346 o Parameter name: assertion 348 o Parameter usage location: token request 350 o Change controller: IETF 352 o Specification document(s): draft-ietf-oauth-saml2-bearer 354 Appendix A. Contributors 356 The following people contributed wording and concepts to this 357 document: Paul Madsen, Patrick Harding, Peter Motyka, Eran Hammer- 358 Lahav, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten 359 Lodderstedt, Scott Cantor and David Waite 361 Appendix B. Document History 363 [[ to be removed by RFC editor before publication as an RFC ]] 365 draft-ietf-oauth-saml2-bearer-01 367 o Update spec name when referencing draft-ietf-oauth-v2 (The OAuth 368 2.0 Protocol Framework -> The OAuth 2.0 Authorization Protocol) 370 o Update wording in Introduction to talk about extension grant types 371 rather than the assertion grant type which is a term no longer 372 used in OAuth 2.0 374 o Updated to reference draft-ietf-oauth-v2-12 and denote as work in 375 progress 377 o Update Parameter Registration Request to use similar terms as 378 draft-ietf-oauth-v2-12 and remove Related information part 380 o Add some text giving discretion to AS on rejecting assertions with 381 unreasonably long validity window. 383 draft-ietf-oauth-saml2-bearer-00 385 o Added Parameter Registration Request for "assertion" to IANA 386 Considerations. 388 o Changed document name to draft-ietf-oauth-saml2-bearer in 389 anticipation of becoming a OAUTH WG item. 391 o Attempt to move the entire definition of the 'assertion' parameter 392 into this draft (it will no longer be defined in OAuth 2 Protocol 393 Framework). 395 draft-campbell-oauth-saml-01 397 o Updated to reference draft-ietf-oauth-v2-11 and reflect changes 398 from -10 to -11. 400 o Updated examples. 402 o Relaxed processing rules to allow for more than one 403 SubjectConfirmation element. 405 o Removed the 'MUST NOT contain a NotBefore attribute' on 406 SubjectConfirmationData. 408 o Relaxed wording that ties the subject of the Assertion to the 409 resource owner. 411 o Added some wording about identifying the client when the subject 412 hasn't directly authenticated including an informative reference 413 to SAML V2.0 Condition for Delegation Restriction. 415 o Added a few examples to the language about verifying that the 416 Assertion is valid in all other respects. 418 o Added some wording to the introduction about the similarities to 419 Web SSO in the format and processing rules 421 o Changed the grant_type (was assertion_type) URI from 422 http://oauth.net/assertion_type/saml/2.0/bearer to 423 http://oauth.net/grant_type/assertion/saml/2.0/bearer 425 o Changed title to include "Grant Type" in it. 427 o Editorial updates based on feedback from the WG and others 428 (including capitalization of Assertion when referring to SAML). 430 draft-campbell-oauth-saml-00 432 o Initial I-D 434 5. References 436 5.1. Normative References 438 [I-D.ietf.oauth-v2] 439 Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, "The 440 OAuth 2.0 Authorization Protocol", 441 ID draft-ietf-oauth-v2-12 (work in progress), Dec 2010. 443 [OASIS.saml-core-2.0-os] 444 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 445 "Assertions and Protocol for the OASIS Security Assertion 446 Markup Language (SAML) V2.0", OASIS Standard saml-core- 447 2.0-os, March 2005. 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, March 1997. 452 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 453 Encodings", RFC 4648, October 2006. 455 5.2. Informative References 457 [OASIS.saml-deleg-cs] 458 Cantor, S., Ed., "SAML V2.0 Condition for Delegation 459 Restriction", Nov 2009. 461 [OASIS.saml-profiles-2.0-os] 462 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 463 P., Philpott, R., and E. Maler, "Profiles for the OASIS 464 Security Assertion Markup Language (SAML) V2.0", OASIS 465 Standard OASIS.saml-profiles-2.0-os, March 2005. 467 [OASIS.saml-sec-consider-2.0-os] 468 Hirsch, F., Philpott, R., and E. Maler, "Security and 469 Privacy Considerations for the OASIS Security Markup 470 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 471 2.0-os, March 2005. 473 [W3C.REC-html401-19991224] 474 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 475 Specification", World Wide Web Consortium 476 Recommendation REC-html401-19991224, December 1999, 477 . 479 Authors' Addresses 481 Brian Campbell (editor) 482 Ping Identity Corp. 484 Email: brian.d.campbell@gmail.com 486 Chuck Mortimore 487 Salesforce.com 489 Email: cmortimore@salesforce.com