Access control for the VO: work for VOTech DS3

1
Access control for the VOwork for VOTech DS3

• Guy Rixon
• February 2005

2
This talk

• Security goals
• Challenges and techniques
• Where the VO is going
• Work for DS3

3
Requirements

• Computers not compromised by VO
• VO resources not damaged by attackers
• VO resources not damaged by users
• Private files stay private
• Resources rationed where necessary
• Access control does not impede users
• Access control does not prevent interoperation

4
Services not compromising the hosts

• Minimal privilege
• E.g. dont run as root
• Minimal 3rd-party software
• E.g. dont deploy httpd if not needed
• Chroot jail
• Keep up to date with patches

5
Ease-of-use constraint

• Access control invisible after session start
• gt single sign-on (SSO)
• gt delegation of access rights to agents
• Registration of users into system not onerous
• C.f. UK e-Science certification
• Ideally, users pre-registered by their employers
• gtregistration is distributed amongst
  institutions, not centralized
• gt idea of community as registration point
• Allow sharing of resources
• User-defined groups

6
Interoperability constraint

• Need standard systems
• Standard in Euro-VO
• Standard in IVO, via IVOA
• Not a separate system for each regional VO
• Only a small number of distinct protocols for
  authentication, authorization.
• E.g. one for SOAP, one for raw HTTP, but only one
  for each.

7
Protecting/rationing resources

• Authorization
• Is user U allowed to do operation O?
• Static rights lists
• Dynamic tracking of quota
• Authentication
• Which user sent this command?
• Which agent sent this command?
• Is that agent allowed to act for the user?
• Is the message unaltered?
• Is the message a replay?
• Accounting
• Routine who used what? How much is left?
• Exceptional who was working when things went
  wrong?

8
Delegation chain
User
User agent
Workflow agent/service broker
DSA/data processing
VOSpace
9
Identity delegation

• Service S trusts user U.
• U trusts agent A.
• U lets A authenticate as U.
• gt S trusts U as much as A.
• gt A can do anything U can to S.
• gt A could misuse Us privileges.
• gt U doesnt need to know which privileges are
  required.

10
Privilege delegation

• Service S trusts user U.
• U does not entirely trust agent A.
• U gives A a ticket authorizing a specific action.
• Ticket is specific to A.
• A authenticates to S as itself.
• A gives S the ticket.
• gt S allows A only the actions in the ticket.
• gt A cant misuse Us privilege
• gt U needs to know what tickets are required

11
Delegation trust boundaries
All agents/services
Trust with ticket
Trust with ID
DSA/data proc
UA
SSO
Workflow
VOSpace
12
Bridging communities
IVOA
EuroVO
Web archives/ Digital libraries
HPC/grid
13
Emerging architecture registration

• Group users into natural communities
• E.g. University departments
• One registration point per community
• Registration done by Registration Authority
• RA local to community gt knows users
• RA uses local, passworded interface to register
• Users can be pre-registered by RA
• Registration -gt SSO password for each user

14
Emerging architecture SSO

• User signs on by giving SSO p/w to user agent
• UA forwards SSO p/w to community service
• Community checks p/w, issues credentials
• Key pair for digital signature
• Identity warrant tied to key pair (X.509?)
• Etc?
• Credentials sent using SAML
• UA retains, uses credentials during session
• Discard credentials at end of session.

15
Emerging architecture authentication

• Several different schemes
• Digital signature on message, unprotected
  transport
• Use for SOAP messages
• Digital signature of challenge phrase, then TLS
  protection of message transport
• GSI use for GridFTP and SRB
• Temporary passwords
• Established by the SSO system, passed in HTTP
  cookies
• Use for HTTP services, web sites and D-Space
  (Shibboleth)

16
Emerging architecture authorization

• Policy
• may be held inside service it applies to
• may be held in community
• In each case, policy may be based on user groups
• Membership of groups always held in community
• gt authorization usually requires transfer of
  data from community to service
• Pull service contacts community at time of
  authorization
• Push authorization tickets sent with request
  to service
• User delegates identity -gt pull authorization
• User delegates specific rights -gt push
  authorization
• Use both modes in different parts of system

17
Prototyping work for DS-3

• Find WS-Security libraries for Axis SOAP
• Try Shibboleth for protecting web-sites
• Shibboleth gateway for getting into D-space
• Shibboleth as credential source for SOAP security
• GSI gateway for talking to GridFTP
• Language for authorization tickets (SAML based?)