Fwd: [WRAP] Re: Assertion Profile/ refresh token

[Brian Eaton]

Forwarded conversation
Subject: [WRAP] Assertion Profile/ refresh token
------------------------

From: Dirk Balfanz <dirk.b...@gmail.com>
Date: Thu, Nov 5, 2009 at 11:16 AM
To: WRA...@googlegroups.com


Hi guys, 

someone brought this up in the discussion today, and I think they are right: The assertion profile should return a refresh token (in section 5.2.4). 

Here's why: chances are the assertion is a SAML or OpenID assertion that can only be re-obtained by having the user talk to their IdP. In other profiles, we have the refresh token precisely so the user doesn't have to be involved every time the access token expires. To support the same goal (the user should not be involved whenever the access token expires), we should also have a refresh token in the assertion profile. 

Thoughts?

Dirk.

----------
From: George Fletcher <gffl...@aol.com>
Date: Thu, Nov 5, 2009 at 1:16 PM
To: wra...@googlegroups.com


+1 :)

----------
From: Dick Hardt <dick....@gmail.com>
Date: Thu, Nov 5, 2009 at 11:04 PM
To: Web Resource Authorization Protocol <WRA...@googlegroups.com>


There is no user in 5.2. If the assertion used expires, then the
Client will need to obtain a new one. (how the Client obtains
assertions is out of scope)

In 5.2, the Authorization Server is acting as an STS, translating from
some assertion to an Access Token the Protected Resource understands.

We have refresh tokens in profiles where there is a User (5.3, 5.4,
5.5)

Note that if a User may authN to a Web App with a SAML token in 5.4,
how the user authN is out of scope of WRAP

George had mentioned that a profile where a Rich App could acquire an
Access Token from the Authorization Server by presenting a SAML token
on behalf of the User. If someone wants to write that up, that would
be fabulous (assuming I understood what George intended)

(please move the rest of this conversation over to OAuth WRAP WG!)

[Brian Eaton]

> (please move the rest of this conversation over to OAuth WRAP WG!)

(CC'ing both groups until George joins oauth-wrap-wg)

> In other profiles, we have the refresh token precisely so the user doesn't have to be involved every time the access token expires.

I don't expect the SAML profile to be used very often when a human
being is involved. If we've got SAML and a user in the picture, we're
almost certainly using the web SSO profile of SAML. Note that in that
case the client *never sees* the SAML assertion. All they know is
that they popped open a web browser to get user approval.

I do expect the SAML profile to be used in cases where no human being
is present, e.g. a cron job. For example:

- cron job wakes up, needs access to data
- local authentication context (e.g. kerberos, unix session, role
account password, IP address, ssh keys, or other magic security dust)
is used to talk to a SAML IdP
- SAML IdP returns a SAML authentication message
- SAML authentication message is swapped for an access token.

So no refresh token is needed; the ability to get long-lived access to
user data is provided by the local authentication context.

Cheers,
Brian

[Dirk Balfanz]

On Fri, Nov 6, 2009 at 9:46 AM, Brian Eaton <bea...@google.com> wrote:

> (please move the rest of this conversation over to OAuth WRAP WG!)

(CC'ing both groups until George joins oauth-wrap-wg)

> In other profiles, we have the refresh token precisely so the user doesn't have to be involved every time the access token expires.

I don't expect the SAML profile to be used very often when a human
being is involved.  If we've got SAML and a user in the picture, we're
almost certainly using the web SSO profile of SAML.  Note that in that
case the client *never sees* the SAML assertion.  All they know is
that they popped open a web browser to get user approval.

I do expect the SAML profile to be used in cases where no human being
is present, e.g. a cron job.  For example:

Makes sense. 

Thanks.

Dirk.

[George Fletcher]

Sorry for joining late...

My thinking is that whether the response of an authorization request
receives an AT and RT should be orthogonal to how the client
authenticates it's request to the Authorization Server. If we don't
force behavior into a specific profile, then it should be possible for
the client to obtain a "token" (of any kind) and present it to the
Authorization Server as the authentication token.

I think Dick's proposal to write it up as a different profile probably
makes the most sense. What might be nice is a protocol way to
determine whether the client wants a user delegation profile or an
autonomous client profile. Currently this seems to be determined by
the input parameters to the Authorization Server. Maybe a simple
parameter identifying the desired "profile" rather than inferring from
input parameters would be all that is needed to support more use cases
in the future.

Thanks,
George

[Dick Hardt]

On 2009-11-09, at 10:57 AM, George Fletcher wrote:

>
> Sorry for joining late...
>
> My thinking is that whether the response of an authorization request
> receives an AT and RT should be orthogonal to how the client
> authenticates it's request to the Authorization Server. If we don't
> force behavior into a specific profile, then it should be possible for
> the client to obtain a "token" (of any kind) and present it to the
> Authorization Server as the authentication token.

To clarify your point, you are commenting on how some profiles return
both an AT and an RT and some only an AT?

>
> I think Dick's proposal to write it up as a different profile probably
> makes the most sense. What might be nice is a protocol way to
> determine whether the client wants a user delegation profile or an
> autonomous client profile. Currently this seems to be determined by
> the input parameters to the Authorization Server. Maybe a simple
> parameter identifying the desired "profile" rather than inferring from
> input parameters would be all that is needed to support more use cases
> in the future.

I'd prefer to not add another parameter. Another option would be to
have different entry points depending on what gets returned, or
different entry points for each profile.

-- Dick

[George Fletcher]

Dick Hardt wrote:
> On 2009-11-09, at 10:57 AM, George Fletcher wrote:
>
>
>> Sorry for joining late...
>>
>> My thinking is that whether the response of an authorization request
>> receives an AT and RT should be orthogonal to how the client
>> authenticates it's request to the Authorization Server. If we don't
>> force behavior into a specific profile, then it should be possible for
>> the client to obtain a "token" (of any kind) and present it to the
>> Authorization Server as the authentication token.
>>
>
> To clarify your point, you are commenting on how some profiles return
> both an AT and an RT and some only an AT?
>

Yes. It seems to me that in the delegation case, how the "Client"
authenticates the user to the Authorization Server should not matter. So
whether that's loginid/password, or a web delegation redirect-flow, or a
simple web token from a different Authorization Server, or a SAML
assertion, etc shouldn't matter. The point is that the inbound message
allows the Authorization Server to "authenticate" the user and issue the
AT and RT for access by the client on the user's behalf.

The example I used in the IIW session is that the "client" is a webapp
and the user authenticates to the webapp using the SAML HTTP re-direct
binding. The webapp then uses the received SAML assertion as the token
with the Authorization Server in order to get delegated access to other
protected resources. This makes more sense in the context where the SAML
assertion is provided by a different IdP than that associated with the
Authorization Service (i.e. performing identity federation via the SAML
Assertion).

>
>> I think Dick's proposal to write it up as a different profile probably
>> makes the most sense. What might be nice is a protocol way to
>> determine whether the client wants a user delegation profile or an
>> autonomous client profile. Currently this seems to be determined by
>> the input parameters to the Authorization Server. Maybe a simple
>> parameter identifying the desired "profile" rather than inferring from
>> input parameters would be all that is needed to support more use cases
>> in the future.
>>
>
> I'd prefer to not add another parameter. Another option would be to
> have different entry points depending on what gets returned, or
> different entry points for each profile.
>

This is fine... Maybe we could use unique rel values (in XRD) to
represent the two classes of profiles. This makes it easy from a
deployment perspective to use different endpoints. That way whether the
Authorization Server uses multiple endpoints or not is a deployment
decision and still "transparent" to the client.
> -- Dick
>
>
> >
>
>

--
Chief Architect AIM: gffletch
Identity Services Work: george....@corp.aol.com
AOL LLC Home: gffl...@aol.com
Mobile: +1-703-462-3494
Office: +1-703-265-2544 Blog: http://practicalid.blogspot.com

[Dick Hardt]

How the user authenticates to the AS in the Web App profile is out of
scope in WRAP, so you can do your scenario with the existing spec
unless I am misunderstaning something.

>>
>>> I think Dick's proposal to write it up as a different profile
>>> probably
>>> makes the most sense. What might be nice is a protocol way to
>>> determine whether the client wants a user delegation profile or an
>>> autonomous client profile. Currently this seems to be determined by
>>> the input parameters to the Authorization Server. Maybe a simple
>>> parameter identifying the desired "profile" rather than inferring
>>> from
>>> input parameters would be all that is needed to support more use
>>> cases
>>> in the future.
>>>
>>
>> I'd prefer to not add another parameter. Another option would be to
>> have different entry points depending on what gets returned, or
>> different entry points for each profile.
>>
> This is fine... Maybe we could use unique rel values (in XRD) to
> represent the two classes of profiles. This makes it easy from a
> deployment perspective to use different endpoints. That way whether
> the
> Authorization Server uses multiple endpoints or not is a deployment
> decision and still "transparent" to the client.

WRAP did not tackle discovery. Lots of good things happening there
that are complimentary.

Note that we are expecting advancement of OAuth WRAP to be in the IETF
OAuth WG. Adding a new profile would be fine to do here though.

-- Dick

[Paul]

Ill just note that Brian's description of the cron job scenario for
using SAML within the assertion profile isnt really one for which
SAML assertions have been profiled (or for which a SAML protocol
exists)

More common would be for there to be a user in the mix for a SAML
scenario and so there could well be usability value for the Client to
have a RT (although the Authz Server could well decide to not issue an
RT if it wanted a fresh assertion)

Are there not scenarios where, even though a user is involved, a RT is
not appropriate and shouldnt be returned?

Why not allow the Client to simply stipulate it wants an RT? And leave
it up to the Authz Server whether it gets one?

paul

On Nov 10, 3:00 pm, Dick Hardt <dick.ha...@gmail.com> wrote:

[Brian Eaton]

On Tue, Nov 10, 2009 at 1:55 PM, Paul <paul....@gmail.com> wrote:
> Ill just note that Brian's description of the cron job scenario for
> using  SAML within the assertion profile isnt really one for which
> SAML assertions have been profiled (or for which a SAML protocol
> exists)
>
> More common would be for there to be a user in the mix for a SAML

> scenario...

Now I know I said there was no user involved, but role accounts are
people too. =)