Single sign-on authentication: introduction
GWS-WG session, IVOA interop meeting, Kyoto, May 2005
Guy Rixon
SSO: what does it mean?
Allow the user to exercise all pre-agreed rights in the VO by signing on once, per UI, per interactive session, to any conforming UI.
As above, but signing on once per session to any conforming UI is sufficient to make all rights available via all conforming UIs.
Basic requirements
Let resource providers make authorization decisions.
Follow natural patterns of access based on agreements between communities and groups.
Supply credentials to inform auth. decisions.
Unlock all user credentials with one sign-on per session.
Make it as simple as possible (but no simpler!)
Axiom: users are registered
User has to establish an identity once (single registration) to use the VO.
Have to authenticate this identity to resources to get in.
Registration generates credentials for authenticating to services.
Issue: where are users registered?
Separately by each service provider (e.g. each archive site)?
Centrally in the IVO?
Centrally in regional VO project?
In their natural community (e.g. university department)?
Issue: when are credentials issued?
At registration, direct to human user?
At session sign-on, to user’ s agent?
Axiom: we support groups
Service provider grants access to groups of users
S/w making auth. decision needs access to group details and membership.
Issue: where are groups defined?
Separately at each service provider?
By user communities?
Same place as users are registered?
Somewhere else?
Axiom: we use digital signatures
For s/w agents authenticating to services:
We use public-key cryptography
We use X.509 identity certificates
Certificates issued by CAs
C.f. human users signing on to VO at start of session
Probably use passwords for that
Issue: how are certificate issued?
Who by?
National/commercial CAs (outside IVO)?
Central CA for IVO?
CAs in regional VO projects?
CAs in user communities?
To whom?
To human users (reusable, long-term cert.)
To s/w agents (single-session proxy cert.)
Axiom: we support delegation
Some work is delegated between a chain of services
e.g. Application -> workflow engine -> DAL -> VOStore.
Delegation of work implies delegation of access rights.
Issue: is delegation controlled?
Use of service implies delegation of all user’ s access?
User can veto delegation?
User can specify delegation of specific right
E.g. write once to particular file on particular VOStore.