The LHC experiments AuthZ Interoperation requirements GGF16, Athens 16 February 2006

1. The LHC experimentsAuthZ Interoperation requirementsGGF16, Athens16 February 2006 David KelseyCCLRC/RAL, UKd.p.kelsey@rl.ac.uk

2. Outline Authorization for Particle Physics (LHC at CERN) • Introduction: Experiments and WLCG • EGEE AuthZ and VO management • AuthZ/Interoperation requirements • ATLAS as an example • VOMS deployment • Issues and Interoperation • Some personal comments • Disclaimer: The information contained here is not official statements by WLCG or the LHC Experiments or EGEE or GridPP David Kelsey, GGF16, LCG AuthZ

3. High Energy Physics using a worldwide computing grid CERN December 2005 WLCG = The Worldwide LCG Collaboration

4. The LHC Accelerator The accelerator generates 40 million particle collisions (events) every second at the centre of each of the four experiments’ detectors

5. Which are recorded on disk and magnetic tapeat 100-1,000 MegaBytes/sec ~15 PetaBytes per year for all four experiments LHC DATA This is reduced by online computers that filter out a few hundred “good” events per sec.

6. CMS LHCb ATLAS ALICE Resources for LHC Data Handling 100,000 of today’s fastest processors 15 PetaBytes of new data each year 150 times the total content of the Webeach year 1 Petabyte (1PB) = 1000TB = 10 times the text content of the World Wide Web** ** Urs Hölzle, VP Operations at Google

7. 1800 physicists (including 400 students) 150 universities/laboratories34 countries. High Energy Physics: a global community

8. Global Science needs a Global Grid • LCG depends on two major science grid infrastructures –EGEE and the US Open Science Grid • Interoperation very important EGEE Feb 2006 184 Grid sites 42 countries 21,000 CPUs

9. Authorization & VO Management in EGEE • In EGEE gLite and LCG middleware • Global AuthZ (VOMS) • Virtual Organization Membership Service • VO members, their groups and roles • Provides digitally signed AuthZ attribute certificate • Included in the grid proxy certificate • A “PUSH” model (user can select roles and VOs) • Local AuthZ • Local Centre Authorization Service (LCAS) • A framework to handle local policy (e.g. banned users) • Local Credential Mapping (LCMAPS) • Provides local credentials (Kerberos/AFS, ldap nss…) • Local policy decisions (CE and SE) • Can decide and enforce policy on VOMS attributes • n.b. LCAS/LCMAPS is just one local AuthZ service David Kelsey, GGF16, LCG AuthZ

10. LHC AuthZ requirements Some general AuthZ requirements (not complete list!) • A VO (experiment) wishes to centrally control • Fine-grained access control (data) • Fine-grained access control/priority (cpu) • Priority likely to be dynamic • By Group membership, by role, or individual • Individuals may belong to more than one VO • User must be able to choose for each session • User must be able to select a role(s) per session • Not always super-user! • Sites need to apply local policy based on AuthZ attributes • No need for data encryption – integrity more important • Privacy (no read) between experiments (or groups) needed • Accounting/Auditing required (at group/role/individual) • AND MUST INTEROPERATE BETWEEN GRIDS David Kelsey, GGF16, LCG AuthZ

11. ATLAS (Alessandro De Salvo)Workload Management groups and roles • Workload Management roles (3) • Grid software administrator • Responsible of the installation of the experiment software. • Production manager • Production user, will have higher priority than normal users for official group productions and will be able to place files in commonly accessible areas • User • Any normal user • Workload Management groups (~20) • Physics and Combined Performance working groups • One group for each Physics Working Group and Combined Performance Group • Testing, validation and central production activities groups David Kelsey, GGF16, LCG AuthZ

12. ATLASDatabase and Data Management groups and roles • Database access roles (5) • Administrator • Administrators manage the installation of database servers and give access rights to other users. • Developer • Database applications developers for particular software domains (full access right to particular databases) • Editor • People having UPDATE or DELETE rights • Writer • People having INSERT or SELECT rights • Reader • People having only the SELECT privileges • Data Management groups and roles • The same groups and roles as for the Workload Management David Kelsey, GGF16, LCG AuthZ

13. VOMS deployment in LCG • One central VOMS service (CERN) per experiment • for use on allGrids • Linked to the Experiment User Database (HR) • Difference between a group and a role? • Membership of all Groups • always present in VOMS proxy cert • Roles may be requested (or not) by the user • E.g. super-user David Kelsey, GGF16, LCG AuthZ

14. Interoperation/Issues (1) • All GRIDs must understand VOMS attributes • All services/middleware must understand VOMS • Gridftp will be used for some years ahead • Not VOMS-aware so still need a grid mapfile • User therefore can only belong to one VO • Local sites need to interpret the attributes sensibly • Not necessarily the same, but not contradictory • Cannot today implement large numbers of groups and roles • batch systems/schedulers use UNIX group id • Need a separate gid for every combination of group/role • too many! • LHC trying to limit the number for now • (Per VO) 2 to 4 groups and 2 to 4 roles (sum <= 6) David Kelsey, GGF16, LCG AuthZ

15. Interoperation/Issues (2) • Can we standardise the names of common roles? • No conclusion yet in LHC • Concerns about names becoming hard-wired into code • May be too hard or not worth it • LHC Groups/Roles today • All experiments have one group = “lcg1” • For general users (old names stick!) • CMS has defined some physics groups (no need to standardise) • StandardModel, HeavyIons, Higgs, … • Role names • VO-Admin (the VO managers) • lcgadmin (software managers) • production (managers of data production) • But note… also cmsprod and usprod David Kelsey, GGF16, LCG AuthZ

16. Interoperation/Issues (3) • How do VO’s define a global/central policy? • And will this be interpreted same by all Grids? • Each VO needs to be able to set processing priority • By group (to give a physics topic priority) • Dynamically and for short periods of time • Without having to get sites to reconfigure • Should they assign a role? • Or a VOMS “capability” (not used yet) • Or maybe nothing to do with VOMS • E.g. VO Global policy could be applied at the Resource Broker (new G-PBox)? David Kelsey, GGF16, LCG AuthZ

17. Interoperation/Issues (4) • A user can belong to multiple groups • How does the work performed run/accounted correctly (in correct group) • And will all Grids do this the same way? • And linked to AuthZ… • Will Grids be able/willing to share accounting and/or auditing information? • This is required by the VO • But usually handled by the Grid Operations • Technical and/or legal problems David Kelsey, GGF16, LCG AuthZ

18. References • The Worldwide LHC Computing Gridhttp://lcg.web.cern.ch/LCG/ • LCG/EGEE Joint Security Policy Group http://proj-lcg-security.web.cern.ch/ • EGEE JRA3 (Security)http://egee-jra3.web.cern.ch/ David Kelsey, GGF16, LCG AuthZ

19. Personal Comments • EU DataGrid, EGEE and LCG have been working with VOMS for several years now • And still we are only just getting it going • VOMS is logically rather simple • But lots of details need to be handled • Its difficult meeting AuthZ requirements within a Grid • Let alone between Grids • Production Grids do not like change • E.g. LCG wants stability over the LHC startup (1 year?) • To have any chance of a working AuthZ system between large global production Grids we must start simply and improve slowly • When security is too hard, people turn it off! David Kelsey, GGF16, LCG AuthZ