Security: Authorization, Access Control and Usage Control

1
Security Authorization, Access Control and Usage
Control

• Andrew McNab, University of Manchester
• mcnab_at_hep.man.ac.uk

2
Outline

• Certificates and VO servers
• New VOMS system
• Using VOMS
• Access Control GACL
• mod_gridsite
• mod_slashgrid?
• Usage Control PBS and Unix disk quotas
• Usage peering and retrospective usage targets
• Genuine accounting
• Future security work

3
Certificates and VO servers

• EDG users and hosts are identified by X.509
  certificates, signed by one of 20 national
  Certificate Authorities.
• Jobs use a short term certificate derived from
  this GSI Proxy.
• X.509 defines how users public key and the CAs
  signature of key the users name is stored.
• This provides authentication equivalent to an ID
  Card.
• Simplest way to build authorization and access
  control using this, is with a list of authorized
  users for a resource.
• This is what EDG currently does with LDAP VO
  servers.
• Lists of members for each Virtual Organisation
  (ATLAS, BaBar etc) are published.
• Sites make local authorized user lists
  (grid-mapfile) from this.
• However, scaling and latency issues since all
  sites must fetch list of all users currently
  authorized

4
Virtual Organisation Membership Service VOMS

• Instead of publishing lists of VO and group
  membership, supply signed attribute certificates
  to users Ticket rather than ID Card.
• Users can then present these attribute
  certificates to sites/resources and obtain access
  with group privilege, role etc.
• Certificates can be included in GSI proxy
  certificates as extensions
• A ticket in your ID card wallet.
• Multiple attribute certificates can be used
  simultaneously, even from different VOMS servers
  and VOs.
• Potential to allow users to create ad-hoc groups
  within VO, and to discard unnecessary VOMS
  credentials at delegation steps.
• Implementation is backwards compatible with
  normal Globus and HTTPS use of certificates
• so still compatible with other Grid projects and
  HTTPS webservers.

5
Using VOMS

• Virtual Organisation sets up a VOMS server
• This has a list of members of the VO, and what
  groups, roles and capabilities they have.
• They can be listed in more than group.
• Instead of using grid-proxy-init to make
  temporary proxy each day, users use
  voms-proxy-init command
• This contacts VOMS server and creates proxy with
  VOMS extensions
• Main body of proxy proves identity
• VOMS extension(s) prove VO and group memberships.
• Users can choose which subset of their groups to
  include in proxy
• Useful for privacy (bio applications esp.) and to
  avoid giving unnecessary rights to jobs.

6
Access Control GACL

• When going beyond simple lists of users, need a
  more flexible way of writing access control
  policies that can include individuals, VO-LDAP or
  VOMS groups.
• GridSite, SlashGrid and Storage Element use GACL,
  simple Access Control Lists written in XML.
• Simplicity important because these fileserver /
  filesystem applications involve very many access
  control evaluations.
• However, GACL isnt a recognised standard and
  something standards-based would be better.
• Could go to, say, an equivalent subset of XACML.
• Proposed OGSA Authorization WG in GGF may endorse
  some way of using (probably) XACML as an
  Authorization Language.

7
GridSite

• GridSite manages access to websites and HTTP(S)
  fileservers
• Users and admins load GSI cert key into
  unmodified web browsers
• Originally produced for www.gridpp.ac.uk
• GACL ACLs control level of read and write access
  to file/directory
• Write access by HTML forms (interactive) or HTTP
  PUT (programmatic)
• Programmatic access makes webserver export
  something looking more like a filesystem GET
  (read), PUT (write), HEAD (stat), DELETE (unlink)
• New 0.9 architecture provides extended
  functionality via Apache module.
• Support for efficient HTTP GET and PUT
  operations.
• ACLs enforced at low level inside Apache request
  processing
• so now available for coarse grained access
  control to PHP, CGI, JSP etc as well as HTML.

8
mod_gridsite
grst-admin.cgi page editing, file upload, ACL
editing etc.
grst-proxy.cgi G-HTTPS, 3rd party COPY, proxy
GET PUT
mod_gridsite .html headers and footers
.shtml, mod_perl CGI, PHP
mod_jk JSP with Tomcat
mod_gridsite PUT, DELETE, MOVE
mod_gridsite GACL access control GACL gt env
vars
mod_ssl plain HTTPS gt env vars
HTTP
mod_ssl-GSI HTTPS with GSIVOMSCAS gt env vars
9
SlashGrid

• Framework for creating Grid-aware filesystems
• different types of filesystem provided by
  dynamically loaded (and potentially third-party)
  plugins.
• client-side daemon manages access and remote file
  fetching cf AFS cache daemon on clients.
• Supports access control by GACL.
• Remote filesystems possible curlfs plugin maps
  remote HTTP(S) server into local filesystem.
• However, existing SlashGrid implementation uses
  coda kernel module
• (Mostly) Linux specific.
• Difficult to permit partial reads of remote
  files.
• Various options for other kernel-gtSlashGrid
  connectors considered
• In particular, OpenAFS kernel module and NFS.

10
mod_slashgrid

• Old SlashGrid daemon has to
• listen on a socket for filesystem operations
  (from kernel)
• manage a hierarchy of files, including access
  control
• support third party plugins in C, Java, other
  languages
• This sounds very like a web server.
• Apache 2.0 transports/filters stack allows
  non-HTTP protocols
• eg mod_ftp and even mod_pop3 has been written.
• Rework SlashGrid as an Apache module, exporting
  GridSite web server filesystem via local TCP
  NFS rather than HTTP.
• We get remote filesystems for free via
  mod_proxy and mod_cache
• Access control already done, via mod_gridsite.
• Can now write third-party filesystem plugins in
  C/C, Perl, Python, Java, PHP, Bash - anything
  you can write web server CGI/dynamic content in.

11
mod_gridsite mod_slashgrid
mod_perl, CGI, PHP
mod_jk JSP with Tomcat
mod_gridsite PUT, DELETE, MOVE
mod_proxy, mod_cache remote servers
mod_gridsite GACL access control GACL gt env
vars
mod_ssl plain HTTPS gt env vars
mod_slashgrid NFS with env vars according to UID
credentials
HTTP
mod_ssl-GSI HTTPS with GSIVOMSCAS gt env vars
kernel NFS local mount of /grid
12
Usage Control PBS and Unix quotas

• Of Securitys Authentication, Authorization and
  Accounting, we have made significant progress
  with the first two.
• But without Accounting, individual users can
  monopolise resources.
• First step towards Accounting is local Usage
  Control quotas etc.
• Can already implement basic usage control using
  PBS and Unix quotas, resource limits etc.
• Since users allocated to one of a pool of
  accounts for their VO, could set up pool accounts
  with appropriate Unix groups, quotas etc.
• This has been investigated by some Testbed sites
  in various ways.
• However, this is quite inflexible and imposes
  static upper limits rather than allocating some
  amount of resources for the job duration.
• Ideally should be integrated into the job
  description and management somehow, so know how
  much is allowed and to clean up afterwards.

13
Usage Peering and retrospective targets

• On what accounting basis will sites put genuine
  resources of their own into the Grid?
• (This is much simpler if resources are earmarked
  for a specific user community - eg Tier 1A
  partitions - but difficulty is for Tier 2 sites.)
• One way is for sites (or groups of sites) to peer
  with each other in terms of usage over some
  accounting period.
• For example, University A peers with College B,
  agreeing that during the accounting period,
  members of A and B will get equal amounts of
  usage of each others sites.
• Could also do this with groups/collaborations eg
  University A joins C-Grid by making a
  certain amount of its resources available to
  other C-Grid sites in return for the same total
  use of other C-Grid sites.
• Can do this with existing technology by putting
  non-local members of College B or C-Grid into
  Unix groups and manually throttling CPU, disk etc
  use during accounting period to fit agreed
  targets.

14
Genuine accounting

• Genuine accounting may include per-user
  measurement of use, enforcement of credit
  limits, charging, getting a price for a job and
  brokering based on price.
• Would be possible to do things purely
  economically with this in place
• eg University A gets 1,000,000 of equipment from
  SRIF and rents it out to users on the open
  market. Uses the income to buy access to
  resources when its own users need it.
• (Money was invented to save us from peering
  a.k.a a barter economy.)
• In that kind of Grid, can choose how to operate
  between that and the other extreme position our
  equipment that only we use.
• Even though optimisation / brokering /
  marketing outside of the scope of Security, but
  we need to provide the local accounting tools
  needed.
• The choke points weve put in place for Access
  Control are very suited to Usage Control and
  usage recording.

15
Future Developments

• EU DataGrid and GridPP-1 nearing end of lifespans
• Security part of GridPP-2 proposal includes
  completion of Authorization work and implementing
  systems required for Accounting.
• This will need to be co-ordinated with
• LCG requirements - already recognised the need
  for Usage Control as an urgent requirement from
  applications.
• EGEE work - again, Security Taskforce recognised
  Usage Control and Accounting as significant area
  that is missing.
• GGF - various accounting and economic models
  working groups already running, with large UK
  contributions from Manchester and London
  e-Science centres.

16
Summary

• VOMS provides users with authorization
  credentials
• more scalable than current VO-LDAP system
• GACL represents Grid access control policies
  (access control lists) in XML.
• GridSite enforces these for web/fileservers.
• SlashGrid being brought into this system as
  Apache module
• more portable and better able to handle partial
  remote file access.
• Basic Usage Control possible using Unix
  mechanisms.
• Usage Peering with retrospective targets would
  provide a way of doing accounting in the near
  term.
• Aim to provide more advanced accounting tools for
  LCG etc in GridPP-2.