> On May 2, 2016, at 22:39, [email protected] wrote: > > Send OAuth mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: Building on the protocol in the draft ?OAuth 2.0 Token > Exchange: An STS for the REST of Us? to include Authentication > Tokens (Fregly, Andrew) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 2 May 2016 14:39:44 +0000 > From: "Fregly, Andrew" <[email protected]> > To: Justin Richer <[email protected]>, George Fletcher > <[email protected]>, "John Bradley" <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: [OAUTH-WG] Building on the protocol in the draft ?OAuth > 2.0 Token Exchange: An STS for the REST of Us? to include > Authentication Tokens > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > Thank you for that link Justin. The approach you mentioned would work well if > we were dealing with an all OpenID Connect world. I don?t think it will work > for our requirements. We need to support authentication with the legacy > Identity Providers found within organizations from client types that might be > native apps as well as Web clients. We can?t put in any requirements that > require changes to the Identity Providers, such as requiring them to handle > redirects in accordance with OAuth or OpenID Connect standards. The advice > and direction I have received from this group has been very useful in > pointing me to the various approaches that needed to be considered. After > considering all that I have learned, I think our use case is out of the > design constraints that have been driving the development of OAuth and OpenID > Connect. Despite that, I can get very close with the existing OAuth RFCs. > This may result in me writing a draft/profile that describes what was needed > on top of those > RFCs an > d a discussion of the security implications of the additions. If anybody > would like to follow up with me, please email me directly as I don?t know if > it is worth beating on this topic any more with the full group. > > From: Justin Richer <[email protected]<mailto:[email protected]>> > Date: Saturday, April 23, 2016 at 9:55 AM > To: "Fregly, Andrew" <[email protected]<mailto:[email protected]>>, > George Fletcher <[email protected]<mailto:[email protected]>>, John Bradley > <[email protected]<mailto:[email protected]>>, > "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>> > Subject: Re: [OAUTH-WG] Building on the protocol in the draft ?OAuth 2.0 > Token Exchange: An STS for the REST of Us? to include Authentication Tokens > > OpenID Connect defines a third-party login endpoint for RP's, which is what > the AS is acting as in this case: > > http://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin > > -- Justin > > On 4/22/2016 10:50 AM, Fregly, Andrew wrote: > Hi George, > > You have the flow right for how I have been approaching the problem. Note > that the client doesn?t have to be a mobile app, but that represents well > what we are trying to solve. Per your recommendation, what I am missing in my > knowledge is a standard for how the AS could be directed to use an external > IdP for authentication. Not knowing this, I have been assuming the flow you > described as my ?original thinking" would be required. I will do some more > research on the topic and check back in. > > Thanks, > Andy > > > From: George Fletcher <[email protected]<mailto:[email protected]>> > Organization: AOL LLC > Date: Wednesday, April 20, 2016 at 1:36 PM > To: "Fregly, Andrew" <[email protected]<mailto:[email protected]>>, > John Bradley <[email protected]<mailto:[email protected]>>, > "<mailto:[email protected]>[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>> > Subject: Re: [OAUTH-WG] Building on the protocol in the draft ?OAuth 2.0 > Token Exchange: An STS for the REST of Us? to include Authentication Tokens > > Hi Andy, > > Glad I guessed correctly:) If there are network or other limitations in how > the client gets and uses tokens, that would be helpful in a diagram sense. As > John points out in his response, not having an audience has possible security > implications. > > If I'm following your original thinking... it goes something like this... > > 1. Mobile app asks users to authenticate at "their" IdP > 2. Mobile app gets back "authentication token" (likely some sort of SAML > assertion) > 3. Mobile app presents "authentication token" to Authorization Service > 4. Authorization Service validate "authentication token" and returns an > access_token > 5. Mobile app invokes data provider passing the access_token > 6. Data provider validates access_token (either locally or via an > introspection endpoint on the AS) > > In this flow there are really two tokens: the "authentication token" and the > access_token. There should be an audience for both tokens. The audience of > the "authentication token" should be the AS, and the audience of the > access_token should be the data provider the client is going to use. > > So, if there are no network firewall type limitations, it seems much simpler > to just have the AS use the external IdPs as it's authentication mechanisms > and the rest is just default OpenID Connect. Meaning that the Mobile app > starts an OpenID Connect flow with the AS, the AS get the user authenticated > via the user's IdP, the AS provides access and id tokens bask to the Mobile > app (following the code or other flow). > > Am I missing something? > > Thanks, > George > > On 4/20/16 10:31 AM, Fregly, Andrew wrote: > Hi George, > > You fully captured one of the options we have been contemplating. I didn?t > propose this flow because I was looking for a way to solve our our use case > based on the existing RFCs and OpenID Connect specifications with minimal new > specification required. That led me to the path described in the email > response I sent out a little while ago to Nat Sakimura?s response. Please > take a look at that email and see what you think. > > Given how well stated your summary of our needs was, do you still want me to > provide a diagram? > > Thanks, > Andy > > From: George Fletcher <[email protected]<mailto:[email protected]>> > Organization: AOL LLC > Date: Wednesday, April 20, 2016 at 8:49 AM > To: Andrew Fregly <[email protected]<mailto:[email protected]>>, John > Bradley <[email protected]<mailto:[email protected]>>, > "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>> > Subject: Re: [OAUTH-WG] Building on the protocol in the draft ?OAuth 2.0 > Token Exchange: An STS for the REST of Us? to include Authentication Tokens > > I should probably just wait for the diagram... but not wanting to wait... :) > > If I understand correctly, the user is going to use a client and the client > will authenticate the user via some IdP using an existing method (SAML, LDAP > (?), OpenID Connect, etc). The desire is to take that response and in some > way present it to an "Authorization Server" which will validate the > "authentication response" and return an access token for use at the data > provider(s). > > What if the Authorization Server also took on the role of the OpenID Connect > provider. This could work by having the client start an OpenID Connect flow > with Authorization Server (hints could be provided as to which IdP the user > wants to authenticate at). The AS would look at the "idp hint" and either > start and SP SAML flow, or present UI for collecting LDAP credentials (I > don't recommend this) or chain to any other proprietary IdP flow. Once the > user successfully authenticates with the correct IdP, the AS will finish the > OpenID Connect flow allowing the client to obtain an access token, refresh > token and id_token. The AS could add to the id_token a claim specifying which > IdP the user used during the authentication processed. > > The IdP the user used for authentication could also be encoded in the > access_token (or returned as part of an introspection call). > > This way whether the data providers are validating the access_tokens locally > or using introspection they can obtain the IdP the user used and apply their > own authorization rules. > > The user is only required to do one authorization flow for the client that is > managed by the Authorization Server. > > Thanks, > George > > On 4/19/16 5:06 PM, Fregly, Andrew wrote: > Thank you for your response George. It points me to some more research to do, > such as looking at OpenID Connect support for both distributed and aggregated > claims. > > Below are replies to your questions/assertions based on my current > understanding of the various protocols. Further research and advice will > likely enrich this significantly. > > Yes, what is required is a verifiable claim that the user is still a member > of SomeOrg Inc. I have been operating under the assumption that the only way > this can be done would be to have the user authenticated by the Identity > Provider for SomeOrg. Perhaps the research into OpenID Connect support for > distributed and aggregated claims will reveal an alternative. I foresee a > challenge in dealing with Identity Provider?s for organizations using SAML > assertions on top of Active Directory and LDAP, and which are not going to do > any updating to support our needs. > > We do not expect the user to first go to the data provider. We anticipate > that the client application would provide a Authentication Token to an > Authorization Service service that then issues to the client an access token > that the data provider will trust. One of our reasons for doing it this way > is that we are trying to eliminate redirects to ease implementation of a > native client. We are therefore requiring the client to handle authentication > with the Identity Provider as a separate step from authorization. > > It might help if I clarified that Verisign?s role in the scenario I described > is to be just one of many data providers. > > From: George Fletcher <[email protected]<mailto:[email protected]>> > Organization: AOL LLC > Date: Tuesday, April 19, 2016 at 4:18 PM > To: Andrew Fregly <[email protected]<mailto:[email protected]>>, John > Bradley <[email protected]<mailto:[email protected]>>, > "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>> > Subject: Re: [OAUTH-WG] Building on the protocol in the draft ?OAuth 2.0 > Token Exchange: An STS for the REST of Us? to include Authentication Tokens > > So if I understand this correctly, what is really required is a verifiable > claim that the user is still a member of SomeOrg Inc. OpenID Connect supports > both distributed and aggregated claims that can be signed by the appropriate > Identity Provider. The point being that I'm not sure an "authentication > token" is required for this use case to succeed, it's just one kind of token > that can be used. > > Also, is the expected flow that the user will first go to the data provider > and then be directed else where from there? If that is the case, the data > provider can just be an OpenID Connect relying party and give the user an > option of the list of supported IdPs to choose from. The user will then be > redirected to SomeOrg Inc. IdP, authenticate and the data provider will have > the authorization and recent authentication they can validate. > > Is the user/data flow more complicated than this? > > Thanks, > George > > On 4/19/16 4:05 PM, Fregly, Andrew wrote: > Thanks for your response John. I also got a good response from Brian Campbell > and appreciate that. I will respond separately to Brian?s response as I think > it would keep things clearer to do that. > > The problem we have for using OpenID Connect is that it combines the role of > Authentication Service with the role of Authorization Service. Perhaps the > following description of what we want to do will clarify why this won?t work > for us: > > The basic problem statement is that we need to have a client application > authorized by a Service Provider based on proof that a user is currently a > member of some organization. This assumes the organization has previously > established some level of authorized access with the Service Provider. > > Here is an example: Suppose I am a member of SomeOrg Inc. Suppose SomeOrg > Inc. is doing research that requires it to gather data over the Internet from > a number of data providers. The data providers require authentication and > proof of organizational membership in order to authorize various levels of > access to their data. The data providers do not consider having an account > with them or a Public Identity Provider to be suitable for proving that I am > still a member of SomeOrg at time of authentication. They would have no way > of knowing whether or not my relationship with SomeOrg still exists at that > time. The data providers would therefore like the Client software to > authenticate me against SomeOrgs Identity Provider. This would be good proof > that I am still a member of SomeOrg at the time I authenticate. This > authentication would enable the data providers Authorization Server to grant > me access appropriate to a member of SomeOrg. Note that as a prerequisite to > all of this, So > meOrg wi > ll have used an out-of-band process to set up a trust relationship for > SomeOrg's Identity Provider with the data provider?s Authorization Service, > and will have negotiated authorization claims to be granted to SomeOrgs > members. > > What I am having difficulty with is in knitting together an approach based on > the he OpenID Connect specifications, SAML specifications, and OAuth RFCs and > drafts in a way that supports the above use case end-to-end. The OAuth RFCs > and drafts almost get me there. What seems to be missing is a way of telling > an Identity Provider the URL for the Authorization Service (the required > Audience claim in an authentication assertion as defined in RFCs 7251, 7252 > and 7253), and then a requirement that the Identity Providers put the > supplied Audience Identifier into Authentication Tokens. Perhaps a little > further back-and-forth with Brian will resolve this. > > I can go into deeper detail if needed. If this is off-topic for the OAuth > working group, let me know. > > Thanks, > Andrew Fregly > Verisign Inc. > > > From: John Bradley > <<mailto:[email protected]>[email protected]<mailto:[email protected]>> > Date: Tuesday, April 19, 2016 at 2:06 PM > To: Andrew Fregly > <<mailto:[email protected]>[email protected]<mailto:[email protected]>> > Cc: "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>> > Subject: Re: [OAUTH-WG] Building on the protocol in the draft ?OAuth 2.0 > Token Exchange: An STS for the REST of Us? to include Authentication Tokens > > Looking at OpenID Connect and it?s trust model for producing id_tokens that > assert identity may help you. > <http://openid.net/wg/connect/>http://openid.net/wg/connect/ > > Unfortunately I can?t quite make out what you are trying to do. > > It sort of sounds like you want an id_token from a idP and then have the > client exchange that assertion for another token? > > John B. > On Apr 19, 2016, at 1:18 PM, Fregly, Andrew > <<mailto:[email protected]>[email protected]<mailto:[email protected]>> > wrote: > > I have a use case where a client application needs to authenticate with a > dynamically determined Identity Provider that is separate from the > Authorization Service that will be used issue an access token to the client. > The use case also requires that as part of authorization, the client provides > to the Authorization Service an authentication token signed by an Identity > Provider that the Authorization Service has a trust relationship with. The > trust relationship is verifiable based on the Authorization Service having > recorded the public keys or certificates of trusted Identity Providers in a > trust store, this allowing the Authorization Service to verify an Identity > Provider?s signature on an authentication token. > > In looking at the various OAuth RFCs, particularly RFCs 7521, 7522, and 7523, > I see that they get me close in terms of supporting the use case. What is > missing is a means for solving the following problem. These RFCs require that > the Identity Provider put an Audience claim in the authentication token. The > problem with this is that I do not see in the RFCs how the Identity Provider > can be told who the Audience is to put into the authentication token. This > leads me to the title of this message. The draft ?OAuth 2.0 Token Exchange: > An STS for the REST of Us? defines a mechanism for identifying the Audience > for an STS to put into a token it generates. That would solve my problem > except that the draft limits the type of STS to being Authorization Servers. > What is needed is this same capability for interacting with an Identity > Provider. This would enable RFCs 7521, 7522 and 7523 to be useful in > situation where the Identity Provider needs to be told the identity of the > Authorization > Service > . > > I am new to interacting with the IETF. I also am not an expert on the RFCs or > prior history of the OAuth group relative to this topic, so please point me > to any existing solution if this is a solved problem. Otherwise, I would like > to get feedback on my suggestion. > > Thanks You, > > Andrew Fregly > Verisign Inc. > _______________________________________________ > OAuth mailing list > <mailto:[email protected]>[email protected]<mailto:[email protected]> > <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > [email protected]<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Chief Architect > Identity Services Engineering Work: > [email protected]<mailto:[email protected]> > AOL Inc. AIM: gffletch > Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch > Office: +1-703-265-2544 Photos: http://georgefletcher.photography > > > > _______________________________________________ > OAuth mailing list > [email protected]<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/oauth > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20160502/29b089af/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 91, Issue 3 > ************************************
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
