Accessing Service on Behalf of the User--supported in OpenId?

[James Henstridge]

On Thu, Aug 21, 2008 at 12:49 AM, Scott Battaglia
<scott.battaglia at gmail.com> wrote:
> Thanks for the reply...some comments in-line!
>
> On Fri, Aug 15, 2008 at 6:26 AM, James Henstridge <james at jamesh.id.au>
> wrote:
>>
>> 2008/8/15 Scott Battaglia <scott.battaglia at gmail.com>:
>> >  <snip />
>> >
>> > 1. Do you guys support accessing a service on behalf of a user.  In CAS
>> > we
>> > call this proxying on behalf of the user.  But essentially, if you're
>> > say, a
>> > portal, and you need to access the grades, you would retrieve a CAS
>> > proxy
>> > ticket and give it to the grades service which would resolve that to the
>> > user as well as the chain of where it came from.
>>
>> 2. Use OAuth.  The portal acquires an access token to the grades
>> service.  This involves sending the user to the grades service to
>> authenticate (which might be done using OpenID).  The portal can then
>> use the access token to request the data directly from the grades
>> service.
>
> This seems like a more viable solution.  This is probably more of a OAuth
> user list question but I figure I'll check here first.  It doesn't look like
> OAuth does attribute exchange, is that true?  Or is there an extension we
> could use (or a standard way to add extensions).  My guess is that would
> start to get a little weird because if there's no interaction then there is
> no way for a user to approve/deny attribute exchanges unless there's a
> central decision made about attribute releases (which may work for us, but
> probably doesn't work in a general case)

OAuth really only defines two things:
1. how the consumer acquires an access token used to talk to the
service provider on behalf of the user.
2. how communication between the consumer and service provider is authenticated.

It doesn't define what the service provider's API look like, so that
part would be up to you to define.


>> > Some of the other stuff is more related to local SSO needs than the
>> > actual
>> > protocol, but I'll ask anyway:
>> > 1. Do you support a method of determining whether someone has
>> > authenticated
>> > already (in CAS we call it gateway)?  For us it relies on the fact that
>> > you
>> > always point to one CAS server, which obviously doesn't need to be true
>> > in
>> > the case of OpenId.    However, in the scenario where you know there is
>> > only
>> > one authenticating server, is this possible?
>>
>> If you are implementing a closed single sign-on system, you can do the
>> following:
>> 1. Make the OpenID provider implement an identifier select endpoint.
>> 2. Make the OpenID provider automatically authenticate users who have
>> already authenticated (perhaps just to known sites).
>> 3. For the relying party sites, if the user is unknown (according to
>> local session cookie), begin an OpenID authentication request to the
>> identifier select endpoint.  The result will include the user's
>> identity.
>
> The system we're building would most likely include SSO, so most of this
> would already happen.  The additional thing CAS offers is that we won't
> force you to authenticate if you haven't already, but we will take advantage
> of the fact that you have if you did already (i.e. for a portal, if you
> haven't authenticated we'll just show a guest layout, but if you have, we'll
> actually display your layout).   My guess is we'll probably have to propose
> our own extension for this.
>
>>
>>
>> If you are designing an open system (user can use whatever provider
>> they want), I don't think there is an answer to this (which provider
>> are you asking whether the user is authenticated to?).
>
> We're actually considering developing a two-tier system.  Locally, we'll
> still be interested in using OpenId, but we'd probably point all of our
> local apps to a central server.  Then our central server would be able to
> handle local users or delegate out to other OpenId servers.

If you're using that system, I guess you could define some kind of
OpenID extension that requests "cancel the authentication request if
the user is not authenticated" and combine that with an identifier
select authentication request.

The central server might also help address some of the trust issues
that exist with specifications like PAPE.


James.