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

[George Fletcher <[e-mail]>]

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] 
> <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
>
>     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] <mailto:[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
>