SSO authentication: a new approach
Guy Rixon
gtr at ast.cam.ac.uk
Fri Mar 18 22:27:18 PST 2005
If the initial, unchecked registration puts the user into an anonymous _group_
inside a community, and if the access authorized for that group is lower, does
that serve? Once the user is checked, then they are moved to another group.
If we went with this model, what privileges can be authorized for the
anonymous group? If they can't be allowed to use VOStores then it's not very
helpful.
On Wed, 16 Mar 2005, Paul Harrison wrote:
> Ray Plante wrote:
> > On Tue, 15 Mar 2005, Paul Harrison wrote:
> >
> >>I think that the distinction would have a bearing on any design -
> >>instead of having different classes of CA, all CAs would be equal, but
> >>the less privileged user would only be registered in a low priviledge
> >>community for instance.
> >
> >
> > I'm trying to address a very practical problem: the hassle of getting a
> > certificate. I want to allow users to be able to fill out a registration
> > form and begin access restricted services immediately. This is not the
> > current practice with cert-based trust models. Many sites provide
> > immediate restricted access without the use of certs, so why bother?
> > Because we don't need to support two forms of authentication, for one;
> > interoperability across sites, for two.
> >
> > So, do you want to see an easier way to get a certificate? If not, then
> > weak certs are not useful. If so, can you really trust a process that
> > cuts corners for expediancy as much as a process that takes greater care?
> > When you assign lower priviledges to a user (because we're not really sure
> > they are who they say they are), how do you do that? For one, how do you
> > recognize that this person should get lower priviledges? You can only do
> > it if you control both the granting of the certificate AND the assigning
> > of priviledge. Priviledges, however, are assigned by the maintainer of
> > service and not the CA.
> >
> >
>
> I think that we are both looking at solving the same use case of making
> it easy to get a certificate that can be in use minutes after the user
> has registered.
>
> Effectively what I am arguing for is that once an identity has been
> issued to a user (in the form of a certificate) they keep that identity.
> In the document that you distributed, there is a requirement 2.4-R2
> 'Users should be allowed to "upgrade" a weak certificate to a strong one
> without loss of access to their data' - if there are different classes
> of certificate, this necessarily means issuing a new certificate and
> effectively changing identity, which then means that the effective owner
> of all user's resources needs to be changed to maintain access
> permissions - not a nice process....
>
> What makes it a pain normally to get a certificate (in the UK at least)
> is that once you have made the certificate request with the shared
> secret from your private key, you are expected to turn up in person at
> the CA before they will push the button to send the signed certificate
> back to you - we could relax that process so that the CA always will
> return the signed certificate without this human step. At which point
> the identity confirmed by the certificate is effectively a member of the
> anonymous community - for this identity to be admitted into other more
> priviledged communities perhaps they would have to undergo some more
> rigorous identity check. It means that when checking for authority to do
> an operation, the priviledges will have been assigned to communities and
> then a community service will have to be consulted to check it the
> identity belongs to the community.
>
> There is the other side of the coin, that the user has to trust the CA
> not to allow easy identity theft - if the standard procedures are
> relaxed too much then that becomes a real possibility, accidental or
> malicious.
>
> --
> Paul Harrison
> ESO Garching
> www.eso.org
>
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
More information about the grid
mailing list