SSO authentication: a new approach

[Guy Rixon]

Eric,

you've given us a lot to think about.  I'd like to reply first concerning your
initial question and your detailed sequence of operations; I'll defer
discussion of the other web-of-trust model to later email.

On Thu, 10 Mar 2005, Eric Saunders wrote:

> 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.

If you run a workflow or similar long-running experiment, and if you leave it
to run unattended, then something has to be left in charge, activating each
stage of the experiment when it comes due. If this is your personal user-agent
(running as a background process on your desktop PC, say), then you don't need
any other agent to have access to your full set of privileges. However, if
your local user-agent isn't running all the time (e.g. it is on your lap-top)
then you may have another agent, on a server, quite probably associated with
your portal/community, looking after things for you. In this case, it helps
for the latter agent to have all your privileges at hand.

The set of tickets you generate to authorize bits of an experiment varies
according to which services you choose.  If the agent doing the workflow has
all your privileges, then it can choose among equivalent services at the time
of execution to optimize thing; if it doesn't, then you'll have to choose all
the service and issue all the tickets when you set the experiment up.


> 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.

You've made a few assumptions in this sequence that don't hold for all likely
use cases.  I'll point them out as they come up.


> 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.

You're assuming that your user agent can do this.  If it's a web browser, then
it probably can't issue tickets by itself. It might be able to get the tickets
from, say, your community, but it may be difficult to push these tickets back
to the portal (would they go as HTTP cookies, perhaps?).


> 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.

This assumes that the portal itself has privileges at the remote facility. Can
we require this in all cases?

If the privileges are actually tied to your identity, then either the portal
can't use them; or you need a ticket authorizing the portal to do so; or you
need to open your identity and all privileges to 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.

You're assumming that the data flow to VOSpace via the portal. This is
undesirable since it involves two transfers of every byte. Some systems may
want to move the data direct from the producer to VOSpace. AstroGrid's CEA
does this routinely.

If the data go direct from the remote service to VOSpace, then the ticket for
access to VOSpace has to be passed to the remote service. It has to authorize
that service, not the portal. Therefore, either the user agent has to be made
aware of the specific service being used, or the portal has to be able to make
of get a new ticket without reference to the UA.

> 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.

I like encapsulation, too. That's why I think it's useful to make the portal
fully trusted and authorized: so that we don't have to break encapsulation by
passing authorization details up to the UA.

> 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 idea of a callback for authorization - it's usually
called "pull authorization" - is good. However, the agent making the
authorization responses needs to be on-line all the time. As discussed above,
this may be a job better done in the portal, or in the community service.

>
> 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.

I agree with both points. However, I think there are cases where the
encapsulation counts than the restriction of the identity.

Regards,
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