EU DataGrid and GridPP Authorization and Access Control

1. EU DataGrid and GridPPAuthorization and Access Control Andrew McNab, University of Manchester mcnab@hep.man.ac.uk

2. Outline • EDG Testbed Overview • Globus Security • Sysadmins’ issues • Existing VO • Pool accounts • LCAS/LCMAPS Site Access Control • VOMS • SlashGrid • GridSite • Grid ACL’s • Future developments

3. Existing EDG Testbed Currently ~300 users at ~20 sites across Europe

4. Globus Security • EDG currently uses Globus 2 gatekeepers and file servers, and Globus’s GSI model for authentication. • Users and hosts are identified by X.509 certificates, signed by one of ~17 “national” Certificate Authorities • CA policy statement must be acceptable to EDG CA Group • CA root certs/configuration distributed by same channels as bug fixes, security patches etc. • Users can produce delegated credentials (“GSI proxy”) by signing a public key with their user certificate • this can be chained to delegate credentials to remote servers • Authorization is provided by simple text file with certificate names and corresponding local Unix account names. • /etc/grid-security/grid-mapfile consisting of lines like: “/O=Grid/O=UKHEP/OU=hep.man.ac.uk/CN=Andrew McNab” mcnab

5. Testbed site administrators’ initial worries... • How can Grid users gain access without me creating new accounts every day? • How can I limit what they can do? • How can I audit what they’ve done to me? • How can I keep track of files they’ve created? • Local access control and account management usually boils down to • mapping Grid identities into appropriate local Unix identities • while respecting the above.

6. Existing EDG LDAP VO • EDG currently uses Virtual Organisation authorisation servers: centrally provided authorisation listings • published via LDAP (~300 users in ~10 VO ’s) • mkgridmap tool for building local grid-mapfile with local choice of VO ’s. • GUI tools allow VO managers to manage VO membership • Provides a list of certificate DN’s for a given group: eg an experiment, or a group within an experiment. • Groups have to be defined by an admin of the VO • can’t be defined on ad-hoc basis by small groups of users • Will eventually meet scaling issues since each site must frequently (daily?) fetch listings for VO ’s it accepts. • VOMS or CAS “visa” model would help a lot with this

7. Joining an application VO • Users first join the Acceptable Use Policy VO, with their web browser, using their certificate • this involves agreeing to the DataGrid wide AUP, that sets out obligations of sites and users • legal wording done in conjunction with CERN legal experts (who understandably have a lot of experience of international law) • Users can then join the VO of their application (eg an LHC experiment) • VO manager can choose whether to accept user • At each site, AND of AUP VO and Application VO controls access

8. Pool accounts • The other half of removing account creation burden from admins • pre-create pools of accounts and allocate these to users when they request access • Widely used by EDG Testbed sites, but not obligatory • in practice, almost all have chosen to use it • Auditing possible since all DN=>UID mappings recorded in log files. • Same pool mappings can be shared across a farm by sharing /etc/grid-security/gridmapdir/ lock files with NFS. • Existing system works ok for CPU-only jobs. • but not really appropriate if users are creating long lived files at the site in question. • limitations are because files are still owned by Unix UID: can’t recycle UID until all files created have been removed.

9. LCAS / LCMAPS site access • Extension of Globus access control / mapping • LCAS - provides site-specific callouts to check authorisation based on user identity, what is requested, quotas, free-slots in batch system etc. • currently implemented as patched Globus gatekeeper, plus plugins to enforce policies • allows sites to implement complex, locally defined rules for access, including locally written extensions to check site-specific features (eg load on locally written tape-library service) • some of this functionality will also be provided by recent Globus proposal for authorisation callouts (but currently limited to yes/no on identity?) • LCMAPS - manages current mappings of Grid to local identity • makes this available to other local site components • important when not just using a simple, shared grid-mapfile for mapping

11. Virtual Organisation Membership Service: VOMS • Instead of publishing lists of VO and group membership, supply signed attribute certificates to users. • 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 • 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. • This is similar to Globus’s Community Authorization Service (CAS) • however, VOMS is designed for maximum backwards compatibility and to maintain the user as the verifiable and principle source of authentication

12. SlashGrid / certfs / curlfs • Framework for creating “Grid-aware” filesystems • different types of filesystem provided by dynamically loaded (and potentially third-party) plugins. • certfs.so plugin provides local storage governed by Access Control Lists based on Grid certificate name’s and VO groups • certfs is very solid: you can build a bootable Linux kernel on a certfs filesystem (~100,000 file operations in a few minutes) • Since new ACL’s just have creator’s name, this is equivalent to file ownership by certificate name rather than UID. • solves admin worries about long lived files owned by pool accounts. • if pool accounts are prevented from writing to normal disks, then no chance they will write something unpleasant somewhere unexpected. • HTTP/HTTPS plugin (curlfs) ultimately aims to provide some NFS/AFS-like functionality, again governed by Grid creds + ACL’s.

13. SlashGrid as container environment • Basic SlashGrid use maps area like /var/spool/slashgrid/grid/xxx to /grid/xxx, with mapping controlled by plugin code. • But also allows virtual directory hierarchies which don’t correspond to real areas on disk • “gridmap” plugin, populated with symbolic links: eg /grid/p/atlas001 -> /grid/u/O=Grid/O=UKHEP/OU=hep.man.ac.uk/CN=Andrew%20McNab • Could go further and create whole user environments on demand • can be a “sandbox” if we prevent operations outside this environment • can be tailored to user’s application (eg default shared library versions) • This means we could achieve a lot of the security and uniformity between sites that, say, a Java VM has, but with native binaries. • This would be very complementary to new GT3 GRAM and execution environment factory.

14. Current ACL’s • When building GridSite, SlashGrid and the EDG Storage Element, we needed a simple ACL format to use for prototyping. • Current SlashGrid and GridSite use per-directory XML ACL in .gacl • As a file, this can be stored in directories, copied via unmodified https or gsiftp channels and easily manipulated by scripts and applications. • Sysadmins want disk filesystem ACL’s on same physical disk as files if possible (or managed off-site!) • Implementing ACL’s also solves some other Grid vs Unix issues that emerged during with Testbed: • eg per-UID tape storage: can store all tape files with one UID but associate ACL with the file and use that. • Clearly, isn’t a recognised standard, and we could go to, say, a subset of XACML: however, things like filesystems are very performance sensitive.

15. Current ACL format <gacl version=“0.0.1”> <entry> <dn-list> <url>ldap://ldap.abc.ac.uk/ou=xyz,dc=abc,dc=ac,dc=uk</url> </dn-list> <voms-cred> <voms>/O=Grid/OU=abc.ac.uk/DN=AbcVOMS</voms> <vo>Abc</vo> <group>readers</group> </voms-cred> <allow><read/></allow> </entry> <entry> <person> <dn>/O=Grid/DN=Andrew</dn> </person> <allow><read/><list/><write/></allow> <deny><admin/></deny> </entry> </gacl>

16. Grid ACL vs fine-grained VO: CAS, VOMS etc • CAS or VOMS can provide ACL-like feature, specifying what capability (“write”) is permissible on objects (“higgs-wg-montecarlo”) • In some cases, this could be used to provide ACL functionality. • However, we think this is too coarse-grained and too heavyweight for all contexts • eg if my job creates a temporary, working directory in /grid/tmp, I don’t want to have to set up a new entry on the central CAS or VOMS machine • The two types of system should be seen as complementary • when you create some Higgs Monte Carlo data, you set its ACL to give write access for people with “higgs-wg-montecarlo-admin” credential. • when you create a temporary working directory, you set its ACL to give only you read and write access. • applications should “find their own level” when splitting policy between local ACL or VO-wide authorisation service

17. GACL library • XML ACL format not finalised but have several products in use which need to use it: GridSite; SlashGrid; and EDG Storage Element. • ACL will almost certainly change again in the future; and may need to understand different ACL’s (eg XACML?) from other projects. • Insulate ourselves from this by putting ACL handling functions into a standalone library, and make this understand the current XML. • Handles read/list/write ACL’s in a reasonably general way • packs C structs and linked lists with their contents • provides access functions to manipulate the structs as new types. • Despite current C implementation, API is readily translatable to object-orientated languages • Java API and implementation being produced

18. 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 • ACL’s control level of read and write access to file/directory • Write access by HTML forms (interactive) or HTTP PUT (programmatic) • Website admins can define groups of users with specific rights • Can delegate administration of that group to one or more members. • Group membership can also be published in EDG VO LDAP format. • New 0.9 architecture also provides support for efficient HTTP GET and PUT operations via Apache module. • ACL enforcement now available for PHP, CGI, JSP etc as well as HTML • GridSite used by several external projects, including e-Science Level 2 Grid support website.

19. GridSite 0.9 architecture 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 > env vars HTTP mod_ssl: plain HTTPS > env vars mod_ssl-GSI: HTTPS with GSI+VOMS+CAS> env vars

20. Future Developments • EU DataGrid officially finishes 31st Dec 2003 • EGEE is an EU Framework 6 proposal to deploy an EU-wide Grid, largely using EDG technology for HEP, Bioinformatics and other e-Science. • GridPP comes to an end in 2004, and GridPP-2 proposal is being drafted for PPARC e-Science 2nd Phase. • CERN is also sponsoring the LHC Computing Grid to deploy a Grid for High Energy Physics. • All of these projects stress deployment and operations rather than middleware development. • However, development of Accounting and Usage Control mechanisms is acknowledged as essential to running these production services. • We propose to extend GridPP Authorization work into Accounting, and to collaborate with e-Science NW / MC expertise in this area.

21. Summary • Most of the concerns of Testbed site admins are being addressed • LDAP VO system is currently sufficient, but VOMS or CAS would be more flexible and scalable. • Pool accounts are useful but limited by UID file ownership issues. • SlashGrid / certfs provides a solution to this. • LCAS/LCMAPS allow flexible, locally configurable site policies. • GridSite provides a way of controlling HTTP(S) via Grid credentials. • GACL library provides API for handling Grid ACL’s. • Extending work into Usage Control, not just Access Control. • See http://www.gridpp.ac.uk/authz/ for links to source code and details of all tools mentioned in this talk