Presentation on theme: "The LHC experiments AuthZ Interoperation requirements GGF16, Athens 16 February 2006 David Kelsey CCLRC/RAL, UK"— Presentation transcript:
The LHC experiments AuthZ Interoperation requirements GGF16, Athens 16 February 2006 David Kelsey CCLRC/RAL, UK email@example.com
16-Feb-06David Kelsey, GGF16, LCG AuthZ2 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
Les Les Robertson LCG Project Leader High Energy Physics using a worldwide computing grid CERN December 2005 WLCG = The Worldwide LCG Collaboration
last update 20/04/2014 17:24 LCG les robertson - cern-it-4 The accelerator generates 40 million particle collisions (events) every second at the centre of each of the four experiments detectors The LHC Accelerator
last update 20/04/2014 17:24 LCG les robertson - cern-it-5 LHC DATA This is reduced by online computers that filter out a few hundred good events per sec. Which are recorded on disk and magnetic tape at 100-1,000 MegaBytes/sec ~15 PetaBytes per year for all four experiments
last update 20/04/2014 17:24 LCG les robertson - cern-it-6 Resources for LHC Data Handling 15 PetaBytes of new data each year CMS LHCb ATLAS ALICE 1 Petabyte (1PB) = 1000TB = 10 times the text content of the World Wide Web ** ** Urs Hölzle, VP Operations at Google 100,000 of todays fastest processors 150 times the total content of the Web each year
last update 20/04/2014 17:24 LCG les robertson - cern-it-7 High Energy Physics: a global community 1800 physicists (including 400 students) 150 universities/laboratories 34 countries.
last update 20/04/2014 17:24 LCG les robertson - cern-it-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 EGEE Feb 2006 184 Grid sites 42 countries 21,000 CPUs
16-Feb-06David Kelsey, GGF16, LCG AuthZ9 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
16-Feb-06David Kelsey, GGF16, LCG AuthZ10 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
A. De Salvo – ATLAS plans and requirements for Authorization in LCG for 2006 – LCG Authorization Workshop 13-9-2005 16-Feb-06 David Kelsey, GGF16, LCG AuthZ11 ATLAS (Alessandro De Salvo) Workload Management groups and roles Workload Management roles (3) Workload Management roles (3) Grid software administrator Grid software administrator Responsible of the installation of the experiment software. Production manager 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 User Any normal userAny normal user Workload Management groups (~20) Workload Management groups (~20) Physics and Combined Performance working groups Physics and Combined Performance working groups One group for each Physics Working Group and Combined Performance GroupOne group for each Physics Working Group and Combined Performance Group Testing, validation and central production activities groups Testing, validation and central production activities groups
A. De Salvo – ATLAS plans and requirements for Authorization in LCG for 2006 – LCG Authorization Workshop 13-9-2005 16-Feb-06 David Kelsey, GGF16, LCG AuthZ12 ATLAS Database and Data Management groups and roles Database access roles (5) Database access roles (5) Administrator Administrator Administrators manage the installation of database servers and give access rights to other users. Developer Developer Database applications developers for particular software domains (full access right to particular databases) Editor Editor People having UPDATE or DELETE rightsPeople having UPDATE or DELETE rights Writer Writer People having INSERT or SELECT rightsPeople having INSERT or SELECT rights Reader Reader People having only the SELECT privilegesPeople having only the SELECT privileges Data Management groups and roles Data Management groups and roles The same groups and roles as for the Workload Management The same groups and roles as for the Workload Management
16-Feb-06David Kelsey, GGF16, LCG AuthZ13 VOMS deployment in LCG One central VOMS service (CERN) per experiment –for use on all Grids –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
16-Feb-06David Kelsey, GGF16, LCG AuthZ14 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)
16-Feb-06David Kelsey, GGF16, LCG AuthZ15 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
16-Feb-06David Kelsey, GGF16, LCG AuthZ16 Interoperation/Issues (3) How do VOs 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)?
16-Feb-06David Kelsey, GGF16, LCG AuthZ17 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
16-Feb-06David Kelsey, GGF16, LCG AuthZ19 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!