Wouldn't it be an alternative solution, if the AS first tries to
authenticate the user using SPNEGO within the Web Server flow? This
should work in the inhouse scenario. If it fails, it can fall back to
username/password auth..
Thoughts?
regards,
Torsten.
Am 15.06.2010 um 17:19 schrieb Andrew Arnott <andrewarn...@gmail.com>:
Hi Dick,
Responses inline.
On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt <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:
The client app is initially launched while on the corporate network
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.
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.
All resource requests use an OAuth access token to gain access.
The client app is initially launched off the corporate network.
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
