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