SSO authentication: a new approach

[Guy Rixon]

Ray,

thanks for the comments.

regarding "single registration", I do of course mean each user registering
just once rather than all users registering at one point.

We have a per-project registration in the UK. The national e-Science programme
operates a CA with registration authorities in each university. The Cambridge
RA isn't in our department, it's in the central computing service down town.
The CA itself is at RAL. To get a certificate, I have to apply to the CA, then
make an appointment (!) to see the RA then drive across town with my
(physical, none-M$) passport (!) and sign for the certificate (!), then go
back to the office and extract the actual certificate from the on-line system.
The whole process sucks, and one would have to be desparate (or silly) to use
that system. We need something a lot more user-friendly.

For the early days, we can register users remotely at project-level CAs, based
on email and phone checks. As the user-base grows, this system will fail to
scale and I still think we'll go back to department-based registration.
However, departments may be able to register guests from other HEIs; it will
just take longer to check those applications.

In the UK, JISC is getting ready to set up Shibboleth registration-points all
over the accedemic community.  Part of Shibboleth is a service that emits SAML
statements to do with users being logged on. Our authorization tickets may
also be SAML statements. We may be able to merge our community services with
Shibboleth's facilities such that users registered with Shibboleth can
automatically use the VO.  More likely, it will work the other way: our
community services will be valid as identity agents in Shibboleth.

Your weak certficates: how does a receiving service distinguish them from a
strong certficate? Do they have a different CA?

Cheers,
Guy

On Thu, 10 Mar 2005, Ray Plante wrote:

> Hi Guys,
>
> (no pun intended.)
>
> I think the time is right to try to tackle this on in the VO.  I pretty
> much agree with Guy's write up.  I just want to share my current take on
> some of the issues he brings up.  I also want to share part 1 of a 3-part
> white paper (attached) I'm working on addressing authorization issues
> (but which also talks about authentication).  I think it's largely
> consistant with Guy's vision.  One caveat about the white paper: it is
> meant to layout how we could manage authorization using a particular grid
> tool (Globus Community Authorization Service); however, the model need not
> be dependent on this.  I think an equivalent system could be assembled
> using, say, Shibboleth.
>
> > single sign-on
>
> Yes!
>
> > single registration system
>
> As Guy points out, if we want trust to transfer across administration
> domains, we need to minimize the number of roots of trust (i.e. CAs).  A
> single registration system for the global VO would do it; however,
> administratively, I'm not sure how practical this is (because services
> need to be maintained...$$$...and the whole thing).  So, I was thinking
> perhaps this might be handled on a per-project basis--e.g. NVO,
> AstroGrid/EVO, JVO, etc.--and then these projects would agree to trust
> each other's CAs.  At least a per-project approach might be a good first
> step to ultimately a global CA.
>
> > where to register (home institutions)
>
> I'm not sure how doable this is in the near-term for a few reasons:
>
>   o  I'm not sure I could convince anyone at my home astronomy department
>      (let alone someone higher up in the University food chain) to take
>      this responsibility.  Perhaps after VO gets more community traction,
>      this would be more practical.
>
>      Shibboleth operates this way, but typically it leverages the
>      university's library, which already manages users on a university
>      level.  I guess if we use Shibboleth, perhaps we can leverage this
>      infrastructure.
>
>   o  Many legitimate users may not be part of an institution that can
>      readily manage approval.  In addition to amateurs and astronomers
>      working in industry, I think we might include the lone astronomer at
>      a small teaching college.
>
> Nevertheless, strong trust starts with trusted humans, so this may be the
> only practical way to do it on the large scale.  I'll note that
> observatories have an operational trust model when the dole out telescope
> time.  Perhaps we can leverage this.
>
> On Thu, 10 Mar 2005, Paul Harrison wrote:
> > * 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.
>
> Actually, I think we do need to support "less-trusted" entities, as the
> attached document argues.  Many services we'll want to provide, including
> VOStore, do not actually require that the user connecting is actually who
> they say they are; they only need to guarantee that the person connecting
> is the person who originally, say, created the space.  This is the model
> for the hundreds of portals we already have logins for today to which we
> could have registered a fake name.
>
> I have proposed the concept of a "weak" certificate.  These are less
> trusted certificates that are granted without a human in the loop as is
> done with a traditional "strong" certificate.
>
> cheers,
> Ray
>
>
>
>

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