GridPP Security Poster

1
EU DataGrid (EDG) GridPPAuthorization and
Access Control

• EDG Virtual Organization Membership Service
  (VOMS)
• Provides information on the users relationship
  with his
• Virtual Organization allowed groups, roles and
  capabilities.
• single sign-on using voms-proxy-init only at the
  beginning of the session (was grid-proxy-init)
• expiration time Authorization is granted for a
  limited time interval (may be different from the
  proxy certificate lifetime).
• backward compatibility the extra VO related
  information is in the users proxy certificate,
  which can be still used with non VOMS-aware
  services
• multiple VO's the user may log-in into
  multiple VO'sand create an aggregate proxy
  certificate, which enableshim to access
  resources in any of them
• scalable authorization Authorization does not
  have to depend on individual identities
• The service is basically a simple account
  database, which serves the information in a
  special format (VOMS credential). The VO manager
  can administer it remotely using command line
  tools or a web interface.

once a day
CA
once a year
VOMS
1. request
3. certificate
2. certificate dn, ca, key

• Authentication
• EDG Certificate Authorities (CA) Working Group
• 20 national certification authorities(including
  EU CrossGrid, USA, Canada, Taiwan CAs)
• policies procedures ? mutual trust
• All CAs trusted by EDG and GridPP sites
• users identified by certificates signed by their
  national Certificate Authority
• Including UK eScience CA for GridPP users

4. VOMS cred VO, groups, roles, capabilities
User
5.b proxy certificate
5.a proxy certificate
5.e proxy certificate
5.d proxy certificate
Java
C
5.c proxy certificate
authentication
authentication
authentication
authentication
TrustManager
Globus Security Infrastructure
valid certificate valid VOMS cred.
valid certificate valid VOMS cred.
valid certificate valid VOMS cred.
valid certificate valid VOMS cred.
pre-process (service specific)
authorization
pre-process (service specific)
Web Services Authorization Framework
authorization
LCAS
requested operation, object id./ACL
dn, attributes
dn, attributes
requested operation, object id./ACL
mapping
mapping
LCMAPS
authorization
GACL
authorization
(local) id
local user
Fine-grainede.g. RepMeC (EDG WP2/WP3)
Coarse-grainede.g. Spitfire (EDG WP2)
Coarse-grainede.g. Compute Element,
Gatekeeper (EDG WP4)
Web
mod_ssl
EDG Java Security EDG TrustManager is a pure
Java based solution for GSI style X.509
certificate path checking with Certificate
Revocation Lists. Using standard CA certificates,
certificate revocation lists (CRL's) and server
credentials (certificates) authenticates the
server to the user and the user to the
server. This can be used for example in Tomcat to
secure any web service without changes in the
code. Includes changes to X.509 certificate path
checking to support Globus proxy certificates
(GSI). EDG Authorization Manager enforcing
policies in Java services The AuthorizationManager
operates with one or several policies. Each
policy has defined an AttributeRepository, which
is used to deduce whether a subject can be
associated with a given attribute (or role). The
AuthorizationManager also has an optional
translation phase after deducing that a subject
indeed is authorized (i.e., can be associated
with the attribute in question), the attribute
name can be translated into another name,
understandable by the local application. Thus,
one can give the AuthorizationManager the triplet
(subjectJohn,attributeDataGridMember,
policylocalDbAccess) and get the answer
"ReadAccessOnTableX" back, an answer that the
local database application knows how to handle.
EDG LCAS enforcing local policies at every
site To ensure the autonomy of the resources
that compose the DataGrid, each site can use an
authorization hook to ensure local policies.
LCAS, which stands for Local Centre Authorization
System, is a site-local service to ensure that
local policies are respected. EDG LCMAPS
integrating Grid users in an existing
infrastructure Operating systems to date have no
specific knowledge of "Grid Users". Therefore
it is needed to translate the idea of a grid user
into that of a local user. And since there
are many different implementations of local
users, even within the same site, a flexible
credential "mapping service" is needed
LCMAPS, or the Local Credential MAPping
Service. Credentials supported are - UNIX
user and group ID's - Pool Accounts from the
gridmapdir system - individual accounts
- AFS and Kerberos

• GridPP GACL
• Grid Access Control List library
• Fine-grained access control to files and
  file-like resources
• Authorization based on Grid certificate names
  (DN) and/or VOMS credentials
• Each ACL has one or more entries (XML)
• admin can modify ACL
• write can write/create files
• list can get a directory listing
• read can read a named file
• ACL consists of lines ltlevelgt ltDN/groupgt
• Also authuser and anyuser
• SlashGrid uses the same format ACLs as the
  GridSite website management system.
• To be extended to support additional AuthZ
  credential formats and languages recommended by
  GGF

• GridPP SlashGrid a framework for Grid-aware file
  systems.
• The dynamic account scheme is a reasonable
  solution for carrying out processing when there
  is no need to store data after the processing is
  complete, but
• any files created by the pool userid will need to
  be cleaned up before the account can be
  re-allocated
• no good for long term storage, as there is no
  guarantee that the userid- Grid DN (distinguished
  name) association will be kept in the long term.
• The obvious solution is to have a file system,
  under /grid, where file ownership depends on Grid
  DNs not temporary userids.
• The problem was solved by putting a file-system
  into the kernel and letting the kernel enforce
  access control restrictions. This construction is
  potentially as fast as the normal disk access.
• This special file-system uses a user space daemon
  for complex operations, such as parsing the
  proxies and doing remote IO.
• SlashGrid uses GACL for access control.

• EDG VO LDAP (before VOMS)
• Each VO maintains AuthZ info in a LDAP server
• mkgridmap tool extracts lists of users from VO
  dbs and creates grid mapfiles
• Static mapping
• GridPP dynamic Pool accounts (gridmapdir)
• A pool of UNIX accounts is created at each site
  per VO, e.g. babar001, babar002, babar003,
• We use a patched version of the Globus gatekeeper
  and the grid ftp-server to associate users to a
  leased Unix userid from the pool.
• Locking retains one to one mapping

• GridPP GridSite a web and file server
• Most websites today implement Access Control via
  cumbersome mechanisms
• E.g. simple username and/or password
• X.509 certificates widely used in HTTPS for
  authentication of web servers to users
• All Grid users have a certificate so use these to
  control access to web servers!
• GridSite is a website management tool
• Flexible for easy use by other projects
• Uses GACL for access control
• Loadable module for dynamic linking into Apache
  webserver
• All technologies supported by web server are
  available (static and dynamic content)
• GridSite server can simultaneously operate as an
  efficient file server, web server and Grid
  Services host

Interworking Collaboration We need to
inter-work with many other Grid projects
including CrossGrid, DataTAG, LCG, PPDG,
GriPhyN, iVDGL, and GridStart. We achieve this
via direct collaboration and active participation
in many GGF Security groups. GGF defines
standards and best practices.
University of Manchester A. McNabCCLRC/Rutherfor
d Appleton Lab L. Cornwall, J. Jensen, D.
Kelsey http//www.gridpp.ac.uk/projects.html http
//cern.ch/hep-project-grid-scg/
mcnab_at_hep.man.ac.uk d.p.kelsey_at_rl.ac.uk
GridPPSecurityPoster29Aug03.ppt