To me, the use case described is more similar to the "Username and
Password flow" but where the user credentials are NOT username &
password. Should we have two "user credential" flows? (1) Username and
Password and (2) assertion/token? I can see it being useful to have a
"user credential" flow that allows for other means of verifying the user
identity than just username and password. Otherwise, I think the
semantics of the flow should be the same.
Thoughts?
Thanks,
George
On 6/15/10 11:19 AM, Andrew Arnott wrote:
Hi Dick,
Responses inline.
On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt <dick.ha...@gmail.com
<mailto:dick.ha...@gmail.com>> wrote:
Why can the client app access the AS to get an access token but
not the corporate network to get a new assertion?
The corporate network where the AD lives is behind a firewall, whereas
the AS is on the public Internet. So when the client is on the public
Internet, the AD is not available but the AS is. Also, the resource
server is on the public Internet (probably obvious).
How does the client app get the assertion to begin with? How did
delegation from the user happen?
There are two possible scenarios here, which I will outline and inject
the steps in each scenario:
1. The client app is initially launched while on the corporate network
1. The client sends an HTTP request to /an /endpoint on a
/corpnet /AS(1) (directly -- not through a browser), which
sniffs the request for NTLM credentials (or however
Windows auth does it) and if present immediately responds
with an authorization code (a.k.a. verification code)
rather than prompting the user for permission. This is
considered reasonable in this application because the
client is already running on a trusted machine and the
privacy ramifications are minimal.
2. The client app exchanges the authorization code for a
refresh token and an access token at the AS(2) token
endpoint, which lies outside the corporate firewall, and
can thereby refresh access tokens when the client is off
corpnet.
3. All resource requests use an OAuth access token to gain
access.
2. The client app is initially launched /off/ the corporate network.
1. This just uses the standard user agent or web server
flows, including prompting the user for authorization.
Would you elaborate more on the use case so that we can understand
the full trust model?
Perhaps my description above covers this question. I'll just add that
the goal is to make the authorization process as painless (or
altogether absent from the user's point of view) as possible. We're
also considering providing customized app downloads to each user based
on the Windows auth user that downloads the .zip file, such that the
client app includes a file containing the authorization code encoded
for that particular user.
The assertion flow was intended for autonomous clients rather than
user delegation -- hence Brian's response and mine that this is a
different flow if the access token is for user delegation.
That makes sense.
Are you envisioning the client makes a call to AD to get an
assertion where the call is automagically authenticated as the
user by NTLM?
Perhaps my scenarios above clarified this. My client never explicitly
calls AD though. Whether that happens implicitly by the Windows
platform, I don't know.
What do you envision being the relationship between the AS and AD?
What authority does the AS have? How long is the refresh token
valid for?
The refresh token would be valid until the user logged into the AS (or
RS perhaps) to revoke it. The AD is altogether unaware of the AS, but
the AS trusts the AD to have authenticated the user and trusts the AD
assertion.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
