SSO authentication: a new approach

[Eric Saunders]

Guy,

I have a couple of issues with the trust model as it's been defined here.

Firstly, what is the benefit of allowing fully trusted agents other than
your personal user agent to assume your identity? If each step of a 
workflow is authorised, then it follows that the whole workflow must be 
valid.

Consider the following simple example. I want to run a set of simulations
on some remote facility, and have the final output returned to my VOSpace 
for further processing. The delegation proceeds as follows.

1. I instruct my user agent.

2. My user agent contacts the portal agent for the facility and makes the
request. My user agent provides the portal with a single use 'ticket'
which allows the portal access to a single directory of my VOSpace, for
writing only, with a short but reasonable expiry date.

3. The portal agent verifies my community and decides to trust me.

4. The portal agent authorises cpu time and temporary scratch disk
allocation from separate services at the remote facility, *using its own
identity*. These facilities are completely abstracted from everybody
beyond the portal.

5. The job runs. The portal agent uses the ticket to dump the data from 
the internal data store to my VOSpace location. The ticket is now 
invalidated. The portal returns a status message to my user agent.

In this example, we only had to export our user privileges to access the
final data write back. When we did so, we minimised the extent of these
privileges. If we needed other services requiring user privileges, the
same temporary ticket model still works. This is just an example of the
Gang of Four 'Facade' pattern: allow encapsulation of a subsystem using a
high-level interface, simplifying subsystem usage and hiding structural
details. In this case, our high-level interface is simply the set of
allowed personal actions which we make available to the other components
of the workflow. We could even make this explicitly OO by passing the
interface API of our agent to the other workflow components.  Now, when
the portal wants to give us our data back, it calls a 'dumpDataToVOSpace'
method on our user agent, which verifies the portal is allowed to do this,
then goes ahead and unlocks the storage location, passing back a suitable
URI or whatever to the portal.

The advantages of this approach are the same as those of encapsulation in 
any other piece of software. The less each component knows about each 
other component, the less can go wrong, whether maliciously, because of 
bugs, erroneous assumptions or simply poor security. Each component is now 
effectively sandboxed.

The other big advantage is that we are not giving away our private
identity to arbitrary software entities, and simply trusting that they
will do the right thing, now and forever. This is inherently risky,
because if a single point in the trust model ever fails, we lose our
identity integrity permanently.

My other point is to do with acquiring trust. While the system is small 
scale, it will be possible to individually validate communities and thus 
establish a trust network. However, as the system scales, this becomes 
more and more difficult. The problem has already arisen in the real world 
in the form of public-key verification between private individuals. The 
weakness of all public-key systems (of which digital certificate schemes 
are a subset) lies in the validity of the public keys - i.e. that a public 
key can be trusted to truly belong to the identity it represents. Once we 
can no longer personally validate keys, this is a problem.

I recommend a web of trust model like that used for public key email 
encryption. See http://www.gnupg.org/gph/en/manual.html#AEN385 for a good 
discussion of how this works. The only assumption is that users in the web 
of trust will, for the most part, authorise keys responsibly. This seems 
reasonable for a specialised environment like the VO. The model is also 
very flexible - individual key holders can specify their trust level based 
on their security needs and/or paranoia - a key issue when trying to 
federate resources run under distinct local security policies. Note that 
this also allows 'degrees of trust'.

Cheers

Eric

---------------------------------------
Eric Saunders
eSTAR Project (http://www.estar.org.uk)
Astrophysics Group
University of Exeter
---------------------------------------


On Thu, 10 Mar 2005, Guy Rixon wrote:

> Paul,
> 
> thanks for the comments.
> 
> The "less-trusted" entities are the case where I trust some service to perform
> a specific action, which I state via authorization tickets, but not to use my
> other privileges. I think this _is_ a form of partial trust; maybe it bneeds
> better explanation.
> 
> Diagrams will come in due course. I have one suitable one that I need to get
> out of power point and I may draw others.
> 
> You're right: the interactions with other trust systems need discussion.  I'll
> add material about this later.
> 
> Guy
> 
> On Thu, 10 Mar 2005, Paul Harrison wrote:
> 
> > I agree that this is the best starting point to create an architecture -
> > in addition to the text, a diagram would be useful to illustrate the
> > trust domains (with their contents) and the trust relationships between
> > them. I think that this is a pretty good starting point. I have a couple
> > of issues though
> >
> > * In the document you talk about "less-trusted" entities - surely in a
> > trust model something should either be trusted or not-trusted, there can
> > be no degrees of trust.
> >
> > * I think that there should be some discussion of what should be done in
> > the case where there needs to be a trust relationship set up between the
> > an existing  authentication system (e.g. the existing particle physics
> > Grids) and the IVOA one.
> >
> > Guy Rixon wrote:
> >
> > >Hi everybody!
> > >
> > >The 2004 discussions of single-sign-on authentication stalled due to
> > >disagreements and misunderstanding about the trust model. Since then, there
> > >have been other discussions about this (in AstroGrid and in EuroVO-VOTech and
> > >among the GWS members discussing VOStore). From this, I've synthesized a trust
> > >model that seems to work and which defines the architecture of an SSO system
> > >that we could use. Here's the initial document:
> > >
> > >  http://wiki.astrogrid.org/bin/view/Astrogrid/TrustModelForVO
> > >
> > >(VOTech and AG people: it's compatible with what I said at the DS-3 meeting.)
> > >
> > >(VOStore people: it's a poshed-up version of what we discussed earlier this
> > >week.)
> > >
> > >If this finds favour, then I'll write it up as an IVOA document.
> > >
> > >It would be good if we could get some consensus on this trust model and
> > >excellent if it could be agreed by or during the Kyoto interop.
> > >
> > >Please note that the trust model sets the requirements for the SSO protocols.
> > >Until we sort out the trust model we can't sort out SSO.
> > >
> > >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
>