Introductory note for SSO proposal

[Guy Rixon]

Doug,

there has been some discussion of this within AstroGrid space: see

http://forum.astrogrid.org/viewtopic.php?t=764

It mainly centres on how to retain single-sign on when users need to combine
privileges from different communities where they are registered.

I think my suggestion, in the AG forum, for federating the communities and
authorization services answers your needs for local registration.  This
federation feature is not yet in the IVOA proposal but I guess it should be.

Cheers,
Guy

On Thu, 1 Jul 2004, Doug Tody wrote:

> Guy -
>
> This looks good, but it would be very helpful to do a walk-through of a
> typical use case to illustrate in concrete terms what is being proposed,
> down to the level of the specific software required to implement such
> a capability.
>
> For example, suppose we have the following scenario:
>
>     o	Site A maintains a user database of all users of the facility.
>     	Probably we want to associate the central sign-on authority for
> 	the site with this user database.  When a user first accesses
> 	the system, e.g., via a Web page, or via a remote Java client,
> 	we somehow authorize the user with this authority.
>
>     o	The user runs some Java client, say a proposal submission tool,
> 	which wants to query a database at the site, and ultimately
> 	update information in the database.  The Java client will need
> 	to authenticate with the master sign-on authority for the site.
> 	This presumably returns some sort of ticket back to the client
> 	which it can then pass off to the database front-end to gain
> 	secure access.	How does this work and what software is used?
> 	What is the lifetime and scope of the ticket?  Can it be passed
> 	around to different clients on different computers or possibly at
> 	different sites?   How?  We will need different "communities" as you
> 	say, e.g., for PIs and their CoIs, for the TAC, for the local staff,
> 	and so forth.  A single person might be in more than one community.
>
>     o	The same authorization mechanism would then be used to retrieve
> 	data from the archive.	Again, this could have various front ends.
> 	A typical scenario might be for a user or client program at site
> 	A to perform a query to site B and pass a secure request to site
> 	C to initiate a third-party transfer of the data back to site A.
>
> Each site would want to maintain its own user database and authentication
> mechanism since this same mechanism would probably be used for internal
> operations.  We might need to gateway whatever is used internally to
> whatever is used for site-to-site authentication within the VO, or perhaps
> this could be another example of a community.
>
> Thanks.
>
> 	- Doug
>
>
>
> On Tue, 29 Jun 2004, Guy Rixon wrote:
>
> > Hi,
> >
> > I've split the introductory material out of the single-sign-on proposal as
> > promised and drafted it as an IVOA note:
> >
> > http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/SSO-introduction.htm
> >
> > Let me know if you think this needs changing: content, presentation, whatever.
> > If nobody wants any changes, then I'll pass the note to Marco as v1.0 around
> > the end of next week.
> >
> > The actual profiles will follow.
> >
> > Cheers,
> > Guy
> >
> > Guy Rixon 				        gtr at ast.cam.ac.uk
> > Institute of Astronomy   	                Tel: +44-1223-337542
> > Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523
> >
> >
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523