Re: [OAUTH-WG] Clarification enhancement for saml2 bearer spec
Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-07-03, at 2:12 PM, Brian Campbell wrote: > Thanks for the feedback Phil. > > In the case of §2.1, "Using SAML Assertions as Authorization Grants" > the intent was to allow for such a SAML grant to be used with or > without client authentication. Whether or not client authentication is > required (and what type of authentication) would be a > deployment/policy decision of the AS. But both are possible from the > spec. > Yes. This makes sense. However in light of the recent discussion about bearer codes and tokens I'm a little more nervous of convolving the grant and client authentication together. It's really the token server that should properly authenticate the client and obscuring that act by combining in a single grant may serve to confuse. There is also the issue of offering too many choices. Just an opinion, but I can live with your suggestion that grant can be used alone. > In the case of §2.2, "Using SAML Assertions for Client > Authentication", yes it's just providing an alternative method of > client authentication beyond what's specified in §2.3 of core. It > doesn't really do anything on its own and must be used in conjunction > with the grant_type parameter. > > I'll take a stab at some clarifying text and/or examples for those > points of confusion. Suggestions are, of course, welcome too. Works for me. > > On Tue, Jul 3, 2012 at 1:15 PM, Phil Hunt wrote: >> I have had a couple developers get confused by sections 2.1 and 2.2 of the >> spec. What seems to be happening is they read them as distinct complete >> flows rather then considering the core spec still applies. >> >> In the case of 2.1, "Using SAML Assertions as Authorization Grants" they >> forget that a client credential is also needed and only specify the SAML >> authorization assuming it includes both (which may or may not be intended). >> >> In the case of 2.2, "Using SAML Assertions for Client Authentication", they >> are not making the link that the client authentication may be used in >> connection with any of the OAuth flows. They are instead treating this as a >> new flow. IOW they forget to add the grant_type parameter. >> >> It might be helpful to include complete examples for each of 2.1 and 2.2 to >> clarify. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.com >> >> >> >> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3
That seems clear enough. Perhaps also saying something along the lines of your last sentence (saying that including the client_id only protects the client from substitution of the authorization code) would help address the concern Justin raised? On Mon, Jul 2, 2012 at 4:15 PM, John Bradley wrote: > Would this be clearer: > >ensure the authorization code was issued to the authenticated > >confidential client, or to the public client identified by the > > 'client_id' in the request, > > > The intent is always that the code must be presented by the client to which > it was issued. That is acceded by authenticating the client in the > confidential case and by inspecting the client_id in the public case. > > > Yes a client can always fake a client_id in the public case, so it is not > intended to protect the protected resource, only the client from token > substitution. > > > John B. > > > > > On 2012-07-02, at 6:02 PM, Anthony Nadalin wrote: > > I read 4.1.3 as the client_id just has to have been issued to a (or any) > public client > > From: John Bradley [mailto:ve7...@ve7jtb.com] > Sent: Monday, July 02, 2012 2:54 PM > To: Anthony Nadalin > Cc: Justin Richer; oauth@ietf.org > Subject: Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3 > > The change to 4.1.3 requires the endpoint to process it. At least as much > as the the text for the Confidential client is requiring it. > > John B. > On 2012-07-02, at 5:45 PM, Anthony Nadalin wrote: > > > While the client may be forced to provide the client_id there are no > requirements for the endpoint to process the client_id (or how that is done) > so not sure what good the change actually does > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Justin Richer > Sent: Monday, July 02, 2012 8:32 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3 > > I'm generally OK with the change, though it does change One problem I have > with this is that it can give a false sense of security about the > information being sent to the token endpoint and how trustworthy it is. A > client_id is public knowledge, and so someone impersonating a client on the > Authentication Endpoint could also impersonate it on the Token Endpoint just > as easily. This is not the attack that's being addressed here, and the > possible phishing vector in the one I'm describing is both well known and, I > believe, well covered by the existing documents. However, I think the new > text might confuse people into conflating these two. > > Basically, I think it needs to be made very clear, especially with this > change of text, that a client_id on its own should never be taken as > sufficient for authentication of the client. The context of the user's > decision, among other things, is as important as a client secret. > > -- Justin > > On 07/02/2012 11:17 AM, Mike Jones wrote: > > I believe we should adopt this revised text. > > -- Mike > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > John Bradley > Sent: Sunday, July 01, 2012 2:22 PM > To: oauth@ietf.org WG > Subject: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3 > > Sec 4.1.2 states: > > > The authorization code is bound to the client identifier and redirection > URI. > > > The security concern Sec 10.5 states > > >If the client can be authenticated, the authorization servers MUST > >authenticate the client and ensure that the authorization code was > >issued to the same client. > > > > Sec 3.2.1 > > A public client that was not issued a client password MAY use the > >"client_id" request parameter to identify itself when sending > >requests to the token endpoint (e.g. for the purpose of providing > >end-user context, client usage statistics). > > > > Nothing in the current spec requires that a Public client send it's > client_id or redirect_uri to the token endpoint. > > The client _id is only sent if it is a confidential client capable of > authenticating itself. > > The redirect_uri is only sent if the 'redirect_uri' parameter was included > in the authorization request. > > If the client has one registered redirect_uri it would not be sent to the > authorization or token endpoint. > > > > This leaves us with public clients using code flow that cannot determine if > a token was granted to them or some other public client. > > > > > > I propose changing Sec 3.2.1 to read: > > > > A public client that was not issued a client password MUST use the > >"client_id" request parameter to identify itself when sending > >requests to the token endpoint. This allows the authorization server > >to ensure that the code was issued to the same client. > >Sending "client_id" prevents the client from > >inadvertently accepting a code intended for a client with a different > >"client_id". > > > Also change Sec 4.1.3 from: > > o authenticate the client if client authenticat
Re: [OAUTH-WG] Clarification enhancement for saml2 bearer spec
Thanks for the feedback Phil. In the case of §2.1, "Using SAML Assertions as Authorization Grants" the intent was to allow for such a SAML grant to be used with or without client authentication. Whether or not client authentication is required (and what type of authentication) would be a deployment/policy decision of the AS. But both are possible from the spec. In the case of §2.2, "Using SAML Assertions for Client Authentication", yes it's just providing an alternative method of client authentication beyond what's specified in §2.3 of core. It doesn't really do anything on its own and must be used in conjunction with the grant_type parameter. I'll take a stab at some clarifying text and/or examples for those points of confusion. Suggestions are, of course, welcome too. On Tue, Jul 3, 2012 at 1:15 PM, Phil Hunt wrote: > I have had a couple developers get confused by sections 2.1 and 2.2 of the > spec. What seems to be happening is they read them as distinct complete flows > rather then considering the core spec still applies. > > In the case of 2.1, "Using SAML Assertions as Authorization Grants" they > forget that a client credential is also needed and only specify the SAML > authorization assuming it includes both (which may or may not be intended). > > In the case of 2.2, "Using SAML Assertions for Client Authentication", they > are not making the link that the client authentication may be used in > connection with any of the OAuth flows. They are instead treating this as a > new flow. IOW they forget to add the grant_type parameter. > > It might be helpful to include complete examples for each of 2.1 and 2.2 to > clarify. > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Clarification enhancement for saml2 bearer spec
I have had a couple developers get confused by sections 2.1 and 2.2 of the spec. What seems to be happening is they read them as distinct complete flows rather then considering the core spec still applies. In the case of 2.1, "Using SAML Assertions as Authorization Grants" they forget that a client credential is also needed and only specify the SAML authorization assuming it includes both (which may or may not be intended). In the case of 2.2, "Using SAML Assertions for Client Authentication", they are not making the link that the client authentication may be used in connection with any of the OAuth flows. They are instead treating this as a new flow. IOW they forget to add the grant_type parameter. It might be helpful to include complete examples for each of 2.1 and 2.2 to clarify. Phil @independentid www.independentid.com phil.h...@oracle.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-saml2-bearer-13.txt
Draft -13 of the SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 document has been published. This draft includes only the minor changes listed below. draft-ietf-oauth-saml2-bearer-13 o Update references: oauth-assertions-04, oauth-urn-sub-ns-05, oauth -28 o Changed "Description" to "Specification Document" in both registration requests in IANA Considerations per changes to the template in ietf-oauth-urn-sub-ns(-03) o Added "(or an acceptable alias)" so that it's in both sentences about Recipient and the token endpoint URL so there's no ambiguity o Update area and workgroup (now Security and OAuth was Internet and nothing) Thanks, Brian -- Forwarded message -- From: Date: Tue, Jul 3, 2012 at 7:12 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-13.txt To: i-d-annou...@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Brian Campbell Chuck Mortimore Filename: draft-ietf-oauth-saml2-bearer-13.txt Pages : 17 Date: 2012-07-03 Abstract: This specification defines the use of a SAML 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-13 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-saml2-bearer-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-13.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Brian Campbell Chuck Mortimore Filename: draft-ietf-oauth-saml2-bearer-13.txt Pages : 17 Date: 2012-07-03 Abstract: This specification defines the use of a SAML 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-13 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-saml2-bearer-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
