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

2008-08-20 Thread Scott Battaglia
Thanks for the reply...some comments in-line!

On Fri, Aug 15, 2008 at 6:26 AM, James Henstridge [EMAIL PROTECTED]wrote:

 2008/8/15 Scott Battaglia [EMAIL PROTECTED]:
   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.

 There are a few models that can be used for this:

 1. The user goes to the grades service and requests that their data
 get transferred to the OpenID provider via the attribute exchange
 protocol.  When they go to the portal site, the portal can request the
 data from the OP, again using attribute exchange.

 Of course, in this model there is no direct contact between the portal
 and grades service in this model, so the portal would need some way of
 verifying that the data it got was correct.  Digital signatures are
 probably the answer here, but there is no standard for this yet (there
 was a proposal for this a while back though).


This doesn't look like it would fit our model.  Some of the services are
purely RESTful or SOAP (and are currently designed to take CAS proxy
tickets, which seem similar to OAuth...)



 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)




  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.




  2. Similar to above, we support a concept of opting-out and forcing
  re-authentication.  So an application that contains SSNs may basically
 tell
  the authentication server, I don't care if they've authenticated already,
 do
  it again.

 The PAPE extension would be appropriate here:


 http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html

 A relying party site can ask the OP to reauthenticate the user if they
 were previously authenticated more than N seconds ago (N can be zero).
  Of course, there is nothing to prevent an OP from lying about
 reauthenticating the user.  If that matters to you, then only accept
 OpenID providers you trust.


  The last question:  We don't actually do this in CAS yet, but we've seen
 it
  and a few people have asked for it.  Is there a way to pass information
  along 

Re: specs Digest, Vol 24, Issue 11

2008-08-20 Thread mailme

	
		I ben op het moment niet aanwezig in verband met vakantie.
I zal weer aanwezig zijn vanaf 25 augustus.
Voor urgente gevallen kunt u een SMS sturen naar 06 4615 6834.
		I am currently out of the office   due to a nice holiday.
I will be back on Monday the 25th of August.
For urgent matters send a SMS to 06 4615 6834.
	
	
		Greetz!
		Edward Granville
			Granville Web Development Studio
		http://www.granville.nl
		
	



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


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

2008-08-20 Thread James Henstridge
On Thu, Aug 21, 2008 at 12:49 AM, Scott Battaglia
[EMAIL PROTECTED] wrote:
 Thanks for the reply...some comments in-line!

 On Fri, Aug 15, 2008 at 6:26 AM, James Henstridge [EMAIL PROTECTED]
 wrote:

 2008/8/15 Scott Battaglia [EMAIL PROTECTED]:
   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.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs