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:
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
