EDG Access Control and User Management (ie Local Authorisation and Accounts)

1. EDG Access Control and User Management(ie Local Authorisation and Accounts) Andrew McNab, University of Manchester mcnab@hep.man.ac.uk

2. Outline • EDG Testbed Overview • Sysadmins’ issues • Existing VO vs CAS • Pool accounts • SlashGrid • Grid ACL’s • XML Grid ACL’s • GACL library • GGF Authorisation Working Group • WP2 Java Security • WP4 LCAS/LCMAPS Site Access Control

3. Existing EDG Testbed Currently ~25 sites across Europe

4. 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.

5. Existing EDG LDAP VO • EDG already has a type of VO authorisation server in use: 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 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 • Current system gives the functionality running experiments like BaBar cope with, so ok. • However, scaling issues since each site must frequently (daily?) fetch listings for VO ’s it accepts.

6. 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

7. VOMS - VO Membership Service • This is similar to first CAS prototype, but retains user identity. • where CAS gave the user a VO-specific proxy to use, VOMS provides the user with an attribute certificate to include in their own proxy cert • This means proxy can be used with existing GSI-based services • but VOMS-aware services can see additional credentials, like VO or subgroup membership • this will remove the necessity to fetch membership lists every day • but for legacy services, DN membership list can still be obtained to construct grid-mapfile’s etc • VOMS administered in much the same way as existing LDAP VO • Users use voms-proxy-init tool which fetches signed attribute certificate from VOMS and includes this in proxy cert extensions • This will be deployed during current EDG 1.3/2.0beta development

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 gridmapdir lock files with NFS. • Existing system works ok for CPU+tmpfile only jobs. • but not really appropriate if users 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. SlashGrid / certfs / curlfs • Prototype framework for creating “Grid-aware” filesystems • different types of filesystem provided by dynamically loaded (and potentially third-party) plugins. • Source, binaries and API notes: http://www.gridpp.ac.uk/authz/slashgrid/ • certfs.so plugin provides local storage governed by Access Control Lists based on Grid DN’s (and groups.) • Since new ACL’s just have creator’s DN, this is equivalent to file ownership by DN 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 NFS/AFS-like functionality, again governed by Grid ACL’s.

10. Grid ACL’s • For simplicity, would want to have an ACL format we can use local and remote files, and other types of resources. • Current SlashGrid prototype and GridSite use per-directory 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. • Implementing ACL’s also solves some other issues that emerged during with Testbed 1: • eg per-UID tape storage: can store all tape files with one UID but associate ACL with the file and use that. • Sysadmins want disk filesystem ACL’s on same physical disk as files if possible.

11. Grid ACL vs VOMS (or fine-grained VO/CAS) • VOMS provides ACL-like feature of specifying what capability (eg write) is permissible on an object (eg higgs-wg-montecarlo). • (If using lots of subgroups within an LDAP VO, could achieve much the same thing: eg define a group of people in higgs-wg-montecarlo-write) • In some cases, this could be used to provide ACL functionality. • However, it 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 VOMS machine • The two systems should be seen as complementary • when you create some Higgs Monte Carlo simulation, put it somewhere the ACL gives write access for people with “higgs-wg-montecarlo” group.) • when you just create a temporary directory, the ACL defaults to just the creator having admin access.

12. An example XML Grid 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>

13. GACL library • XML ACL format not finalised but have several products in use which need to use it: GridSite for www.gridpp.ac.uk; SlashGrid; fileGridSite; and EDG Storage Element. • ACL may change again in the future; may need to understand different (ugh!) ACL’s from other Grid projects. • Insulate ourselves from this by putting ACL handling functions into a standalone library, and make this understand the current XML. • Handles 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

14. GGF Authorization Working Group (Authz) • This had BOF at GGF6 and is with GFSG now • proposed chairs Markus Lorch (VT) and Andrew McNab (Manchester) • Initial objectives are authorisation Glossary, Requirements and Systems Review documents. • But underlying aim is to get all the authorisation people talking to each other, and hopefully standardising. • Areas we’re hoping for convergence in, are: • VOMS vs CAS vs IETF Attribute Certificates • GACL acl’s + other ACL’s • Callouts/plugins for services to enforce locally defined policies • Fitting authorisaiton solutions emerging from Grids into wider Web Services security world • See http://zuni.cs.vt.edu/grid-authz for Authz WG website

15. Other authorisation work • EDG WP2 (Data Management) has built a set of Java security modules • this includes modules for verifying GSI proxies, and enforcing ACL and grid-mapfile access control • can provide security handling for other Grid services • filtering of both plain HTTP and SOAP requests, and queries from service itself during processing • EDG WP4 (Fabric Management) site access system • LCAS - provides site-specific callouts to check authorisation based on user identity, what is requested, quotas, free-slots in batch system etc • LCMAPS - manages current mappings of Grid to local identities • some of this functionality will also be provided by recent Globus proposal for authorisation callouts, but limited to yes/no on identity only

16. WP2 Authorization (slide from Joni Hahkala)

18. Summary • Most of the concerns of Testbed site admins are being addressed • Current VO system is probably sufficient, but VOMS (or CAS) would be more flexible. • Pool accounts are useful but limited by UID file ownership issues. • SlashGrid / certfs provides a solution to this. • GACL library provides API for handling XML Grid ACL’s • Standardisation of these efforts starting with GGF Authz WG • Java Security tools being written for Grid Services to use • LCAS/LCMAPS allows flexible, locally configurable site policies • See http://www.gridpp.ac.uk/authz/ for links to source code and details of all tools mentioned in this talk