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

[Justin Richer <[e-mail]>]

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 <[e-mail] <mailto:[e-mail]>>
> Organization: AOL LLC
> Date: Wednesday, April 20, 2016 at 1:36 PM
> To: "Fregly, Andrew" <[e-mail] 
> <mailto:[e-mail]>>, John Bradley <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>
> 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 <[e-mail] <mailto:[e-mail]>>
>> Organization: AOL LLC
>> Date: Wednesday, April 20, 2016 at 8:49 AM
>> To: Andrew Fregly <[e-mail]>, John Bradley 
>> <[e-mail] <mailto:[e-mail]>>, "[e-mail]" 
>> <[e-mail] <mailto:[e-mail]>>
>> 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 <[e-mail] <mailto:[e-mail]>>
>>>     Organization: AOL LLC
>>>     Date: Tuesday, April 19, 2016 at 4:18 PM
>>>     To: Andrew Fregly <[e-mail]>, John Bradley
>>>     <[e-mail] <mailto:[e-mail]>>, "[e-mail]"
>>>     <[e-mail] <mailto:[e-mail]>>
>>>     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, SomeOrg will 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 <[e-mail]>
>>>>         Date: Tuesday, April 19, 2016 at 2:06 PM
>>>>         To: Andrew Fregly <[e-mail]>
>>>>         Cc: "[e-mail]" <[e-mail] <mailto:[e-mail]>>
>>>>         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/
>>>>
>>>>             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
>>>>>             <[e-mail]> 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
>>>>>             [e-mail] <mailto:[e-mail]>
>>>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>         _______________________________________________
>>>>         OAuth mailing list
>>>>         [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>
> -- 
> Chief Architect
> Identity Services Engineering     Work:[e-mail]
> AOL Inc.                          AIM:  gffletch
> Mobile: [phone]           Twitter:http://twitter.com/gffletch
> Office: [phone]           Photos:http://georgefletcher.photography
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth