draft-ietf-oauth-saml2-bearer-08.txt   draft-ietf-oauth-saml2-bearer-09.txt 
B. Campbell, Ed. B. Campbell, Ed.
Internet-Draft Ping Identity Corp. Internet-Draft Ping Identity Corp.
Intended status: Standards Track C. Mortimore Intended status: Standards Track C. Mortimore
Expires: February 2, 2012 Salesforce.com Expires: April 3, 2012 Salesforce.com
Aug 2011 Oct 2011
SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer-08 draft-ietf-oauth-saml2-bearer-09
Abstract Abstract
This specification defines the use of a SAML 2.0 Bearer Assertion as This specification defines the use of a SAML 2.0 Bearer Assertion as
means for requesting an OAuth 2.0 access token as well as for use as means for requesting an OAuth 2.0 access token as well as for use as
a means of client authentication. a means of client authentication.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 2, 2012. This Internet-Draft will expire on April 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
3.2. Client Authentication Processing . . . . . . . . . . . . . 8 3.2. Client Authentication Processing . . . . . . . . . . . . . 8
4. Authorization Grant Example (non-normative) . . . . . . . . . 8 4. Authorization Grant Example (non-normative) . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. Sub-Namespace Registration of 6.1. Sub-Namespace Registration of
urn:ietf:params:oauth:grant-type:saml2-bearer . . . . . . 10 urn:ietf:params:oauth:grant-type:saml2-bearer . . . . . . 10
6.2. Sub-Namespace Registration of 6.2. Sub-Namespace Registration of
urn:ietf:params:oauth:client-assertion-type:saml2-bearer . 10 urn:ietf:params:oauth:client-assertion-type:saml2-bearer . 10
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Security Assertion Markup Language (SAML) 2.0 The Security Assertion Markup Language (SAML) 2.0
[OASIS.saml-core-2.0-os] is an XML-based framework that allows [OASIS.saml-core-2.0-os] is an XML-based framework that allows
identity and security information to be shared across security identity and security information to be shared across security
domains. The SAML specification, while primarily targeted at domains. The SAML specification, while primarily targeted at
providing cross domain Web browser single sign-on, was also designed providing cross domain Web browser single sign-on, was also designed
to be modular and extensible to facilitate use in other contexts. to be modular and extensible to facilitate use in other contexts.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
extent reasonable, concepts and patterns from that well-established extent reasonable, concepts and patterns from that well-established
Profile. Profile.
This document defines how a SAML Assertion can be used to request an This document defines how a SAML Assertion can be used to request an
access token when a client wishes to utilize an existing trust access token when a client wishes to utilize an existing trust
relationship, expressed through the semantics of (and digital relationship, expressed through the semantics of (and digital
signature calculated over) the SAML Assertion, without a direct user signature calculated over) the SAML Assertion, without a direct user
approval step at the authorization server. It also defines how a approval step at the authorization server. It also defines how a
SAML Assertion can be used as a client authentication mechanism. The SAML Assertion can be used as a client authentication mechanism. The
use of an Assertion for client authentication is orthogonal and use of an Assertion for client authentication is orthogonal and
separable from using an Assertion as an authorization grant and can separable from using an Assertion as an authorization grant and the
be used either in combination or in isolation. two can be used either in combination or in isolation.
The process by which the client obtains the SAML Assertion, prior to The process by which the client obtains the SAML Assertion, prior to
exchanging it with the authorization server or using it for client exchanging it with the authorization server or using it for client
authentication, is out of scope. authentication, is out of scope.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 5, line 29 skipping to change at page 5, line 29
In order to issue an access token response as described in The OAuth In order to issue an access token response as described in The OAuth
2.0 Authorization Protocol [I-D.ietf.oauth-v2] or to rely on an 2.0 Authorization Protocol [I-D.ietf.oauth-v2] or to rely on an
assertion for client authentication, the authorization server MUST assertion for client authentication, the authorization server MUST
validate the Assertion according to the criteria below. Application validate the Assertion according to the criteria below. Application
of additional restrictions and policy are at the discretion of the of additional restrictions and policy are at the discretion of the
authorization server. authorization server.
o The Assertion's <Issuer> element MUST contain a unique identifier o The Assertion's <Issuer> element MUST contain a unique identifier
for the entity that issued the Assertion. for the entity that issued the Assertion.
o The Assertion MUST contain an <AudienceRestriction> element with o The Assertion MUST contain <Conditions> element with an
an <Audience> element containing a URI reference that identifies <AudienceRestriction> element with an <Audience> element
the authorization server, or the service provider SAML entity of containing a URI reference that identifies the authorization
its controlling domain, as an intended audience. The token server, or the service provider SAML entity of its controlling
endpoint URL of the authorization server MAY be used as an domain, as an intended audience. The token endpoint URL of the
acceptable value for an <Audience> element. The authorization authorization server MAY be used as an acceptable value for an
server MUST verify that it is an intended audience for the <Audience> element. The authorization server MUST verify that it
Assertion. is an intended audience for the Assertion.
o The Assertion MUST contain a <Subject> element. The subject MAY o The Assertion MUST contain a <Subject> element. The subject MAY
identify the resource owner for whom the access token is being identify the resource owner for whom the access token is being
requested. For client authentication, the Subject MUST be the requested. For client authentication, the Subject MUST be the
client_id of the OAuth client. When using assertions as an client_id of the OAuth client. When using assertions as an
authorization grant, the Subject SHOULD identify an authorized authorization grant, the Subject SHOULD identify an authorized
accessor for whom the access token is being requested (typically accessor for whom the access token is being requested (typically
the resource owner, or an authorized delegate). Additional the resource owner, or an authorized delegate). Additional
information identifying the subject/principal of the transaction information identifying the subject/principal of the transaction
MAY be included in an <AttributeStatement>. MAY be included in an <AttributeStatement>.
o The Assertion MUST have an expiry that limits the time window o The Assertion MUST have an expiry that limits the time window
during which the it can be used. The expiry can be expressed during which it can be used. The expiry can be expressed either
either as the NotOnOrAfter attribute of the <Conditions> element as the NotOnOrAfter attribute of the <Conditions> element or as
or as the NotOnOrAfter attribute of a suitable the NotOnOrAfter attribute of a suitable <SubjectConfirmationData>
<SubjectConfirmationData> element. element.
If the Assertion has a NotOnOrAfter attribute on the <Conditions>
element, the authorization server MUST verify that the
NotOnOrAfter instant has not passed, subject to allowable clock
skew between systems. The authorization server SHOULD reject
assertions with an expiry instant that is unreasonably far in the
future.
If the Assertion does not have a NotOnOrAfter attribute on the
<Conditions> element, then the Assertion's <Subject> element MUST
contain at least one <SubjectConfirmation> element that allows the
authorization server to confirm it as a Bearer Assertion.
Conditions for bearer subject confirmation are described below.
* The <SubjectConfirmation< MUST have a Method attribute with a
value of "urn:oasis:names:tc:SAML:2.0:cm:bearer" and MUST
contain a <SubjectConfirmationData> element.
* The <SubjectConfirmationData> element MUST have a Recipient
attribute with a value indicating the token endpoint URL of the
authorization server. The authorization server MUST verify
that the value of the Recipient attribute matches the token
endpoint URL (or an acceptable alias) to which the Assertion
was delivered.
* The <SubjectConfirmationData> element MUST have a NotOnOrAfter o The <Subject> element MUST contain at least one
attribute that limits the window during which the Assertion can <SubjectConfirmation> element that allows the authorization server
be confirmed. The authorization server MUST verify that the to confirm it as a Bearer Assertion. Such a <SubjectConfirmation>
NotOnOrAfter instant has not passed, subject to allowable clock element MUST have a Method attribute with a value of
skew between systems. The authorization server MAY ensure that "urn:oasis:names:tc:SAML:2.0:cm:bearer". The
Bearer Assertions are not replayed, by maintaining the set of <SubjectConfirmation> element MUST contain a
used ID values for the length of time for which the Assertion <SubjectConfirmationData> element, unless the Assertion has a
would be considered valid based on the NotOnOrAfter attribute suitable NotOnOrAfter attribute on the <Conditions> element, in
in the <SubjectConfirmationData>. The authorization server MAY which case the <SubjectConfirmationData> element MAY be omitted.
reject assertions with a NotOnOrAfter instant that is When present, the <SubjectConfirmationData> element MUST have a
unreasonably far in the future. Recipient attribute with a value indicating the token endpoint URL
of the authorization server. The authorization server MUST verify
that the value of the Recipient attribute matches the token
endpoint URL (or an acceptable alias) to which the Assertion was
delivered. The <SubjectConfirmationData> element MUST have a
NotOnOrAfter attribute that limits the window during which the
Assertion can be confirmed. The <SubjectConfirmationData> element
MAY also contain an Address attribute limiting the client address
from which the Assertion can be delivered. Verification of the
Address is at the discretion of the authorization server.
* The <SubjectConfirmationData> element MAY also contain an o The authorization server MUST verify that occurances of the
Address attribute limiting the client address from which the NotOnOrAfter instant has not passed, subject to allowable clock
Assertion can be delivered. Verification of the Address is at skew between systems. An invalid NotOnOrAfter instant on the
the discretion of the authorization server. <Conditions> element invalidates the entire assertion. An invalid
NotOnOrAfter instant on a <SubjectConfirmationData> element only
invalidates the individual <SubjectConfirmation>. The
authorization server MAY reject assertions with a NotOnOrAfter
instant that is unreasonably far in the future. The authorization
server MAY ensure that Bearer Assertions are not replayed, by
maintaining the set of used ID values for the length of time for
which the Assertion would be considered valid based on the
applicable NotOnOrAfter instant.
o If the Assertion issuer authenticated the subject, the Assertion o If the Assertion issuer authenticated the subject, the Assertion
SHOULD contain a single <AuthnStatement> representing that SHOULD contain a single <AuthnStatement> representing that
authentication event. authentication event.
o If the Assertion was issued with the intention that the presenter o If the Assertion was issued with the intention that the presenter
act autonomously on behalf of the subject, an <AuthnStatement> act autonomously on behalf of the subject, an <AuthnStatement>
SHOULD NOT be included. The presenter SHOULD be identified in the SHOULD NOT be included. The presenter SHOULD be identified in the
<NameID> or similar element, the <SubjectConfirmation> element, or <NameID> or similar element, the <SubjectConfirmation> element, or
by other available means like [OASIS.saml-deleg-cs]. by other available means like [OASIS.saml-deleg-cs].
skipping to change at page 11, line 25 skipping to change at page 11, line 25
The following people contributed wording and concepts to this The following people contributed wording and concepts to this
document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran
Hammer-Lahav, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten Hammer-Lahav, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten
Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Michael Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Michael
Jones, Hannes Tschofenig, David Waite and Mukesh Bhatnagar. Jones, Hannes Tschofenig, David Waite and Mukesh Bhatnagar.
Appendix B. Document History Appendix B. Document History
[[ to be removed by RFC editor before publication as an RFC ]] [[ to be removed by RFC editor before publication as an RFC ]]
draft-ietf-oauth-saml2-bearer-09
o Attempt to address an ambiguity around validation requirements
when the Conditions element contain a NotOnOrAfter and
SubjectConfirmation/SubjectConfirmationData does too. Basically
it needs to have at least one bearer SubjectConfirmation element
but that element can omit SubjectConfirmationData, if Conditions
has an expiry on it. Otherwise, a valid SubjectConfirmation must
have a SubjectConfirmationData with Recipient and NotOnOrAfter.
And any SubjectConfirmationData that has those elements needs to
have them checked.
o clarified that AudienceRestriction is under Conditions (even
though it's implied by schema)
o fix a typo
draft-ietf-oauth-saml2-bearer-08 draft-ietf-oauth-saml2-bearer-08
o fix some typos o fix some typos
draft-ietf-oauth-saml2-bearer-07 draft-ietf-oauth-saml2-bearer-07
o update reference from draft-campbell-oauth-urn-sub-ns to o update reference from draft-campbell-oauth-urn-sub-ns to
draft-ietf-oauth-urn-sub-ns draft-ietf-oauth-urn-sub-ns
o Updated to reference draft-ietf-oauth-v2-20 o Updated to reference draft-ietf-oauth-v2-20
skipping to change at page 15, line 34 skipping to change at page 16, line 6
Security Assertion Markup Language (SAML) V2.0", OASIS Security Assertion Markup Language (SAML) V2.0", OASIS
Standard OASIS.saml-profiles-2.0-os, March 2005. Standard OASIS.saml-profiles-2.0-os, March 2005.
[OASIS.saml-sec-consider-2.0-os] [OASIS.saml-sec-consider-2.0-os]
Hirsch, F., Philpott, R., and E. Maler, "Security and Hirsch, F., Philpott, R., and E. Maler, "Security and
Privacy Considerations for the OASIS Security Markup Privacy Considerations for the OASIS Security Markup
Language (SAML) V2.0", OASIS Standard saml-sec-consider- Language (SAML) V2.0", OASIS Standard saml-sec-consider-
2.0-os, March 2005. 2.0-os, March 2005.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 Raggett, D., Jacobs, I., and A. Hors, "HTML 4.01
Specification", World Wide Web Consortium Specification", World Wide Web Consortium
Recommendation REC-html401-19991224, December 1999, Recommendation REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
Authors' Addresses Authors' Addresses
Brian Campbell (editor) Brian Campbell (editor)
Ping Identity Corp. Ping Identity Corp.
Email: brian.d.campbell@gmail.com Email: brian.d.campbell@gmail.com
 End of changes. 12 change blocks. 
61 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/