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 <gffle...@aol.com <mailto:gffle...@aol.com>>
Organization: AOL LLC
Date: Wednesday, April 20, 2016 at 8:49 AM
To: Andrew Fregly <afre...@verisign.com
<mailto:afre...@verisign.com>>, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>>, "oauth@ietf.org <mailto:oauth@ietf.org>"
<oauth@ietf.org <mailto:oauth@ietf.org>>
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 <gffle...@aol.com <mailto:gffle...@aol.com>>
Organization: AOL LLC
Date: Tuesday, April 19, 2016 at 4:18 PM
To: Andrew Fregly <afre...@verisign.com>, John Bradley
<ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>>, "oauth@ietf.org"
<oauth@ietf.org <mailto:oauth@ietf.org>>
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 <ve7...@ve7jtb.com>
Date: Tuesday, April 19, 2016 at 2:06 PM
To: Andrew Fregly <afre...@verisign.com>
Cc: "oauth@ietf.org" <oauth@ietf.org <mailto:oauth@ietf.org>>
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
<afre...@verisign.com> 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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
--
Chief Architect
Identity Services Engineering Work: george.fletc...@teamaol.com
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
