INFSO-RI Enabling Grids for E-sciencE GGF16 workshop Authorization Interoperability (Here and Now) David Kelsey, CCLRC/RAL, UK EGEE MWSG Meeting CERN, 7 March 2006

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 2 GGF16 workshop Athens, 16 Feb 2006 Half-day workshop on Grid Authorization –Interoperability “Here and Now” Organised by… Christophe Blanchet(CNRS IBCP&EGEE biomed VO dep) Vincent Breton(CNRS & EGEE Dir of Applications) Bob Cowles(SLAC and OSG Security co-chair) Ake Edlund(KTH and EGEE Director of Security) David Groep(NIKHEF and IGTF chair) David Kelsey(CCLRC and LCG/EGEE JSPG chair) Olle Mulmo(KTH and GGF Security Area Director) Dane Skow(USA and GGF Security Area Director) Von Welch(NCSA and Globus Alliance)

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 3 Background Much work on Grid Authentication -> success –International GridTrust Federation (IGTF) –facilitates cross-Grid authentication Grid Authorization is less mature Many large-scale application communities (VOs) are global in nature –have the need to access multiple Grid infrastructures Authorization (AuthZ) assertions and policy needs to be controlled at the VO level Important requirement for interoperability in AuthZ between Grids –protocols and evaluation of the AuthZ/Policy assertions –different implementations interwork and make AuthZ decisions.

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 4 Aims This workshop will consider short-term (now and next two years) Grid Authorization and Policy implementations, requirements and issues Investigate what improvements can be made to encourage and facilitate interoperability between Grid operational infrastructures Lessons learned from today's implementations –For the Grid security standards activities in GGF for the longer-term future. Highlight the Life Science perspective with requirements from the biomed VO in EGEE and in the overall biomedical community

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 5 Agenda – Session # Welcome, introduction and aims The LHC experiments (particle physics) AuthZ requirements (David Kelsey) The Biomed/EGEE AuthZ requirements (Christophe Blanchet/Rémi Mollon) AuthZ in Open Science Grid (Bob Cowles) Discussion

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 6 Agenda – Session #2 Panel presentations & discussion - AuthZ interoperability issues and plans Von Welch TeraGrid/OSG interoperation issues David Groep EGEE framework and local PDP's Jens Jensen Data management AuthZ Yuri Demchenko GAAA/GT4 gap analysis Christos Kanellopoulos Ideas on interoperation/interoperability Olle MulmoFuture plans and directions (for GGF) leading into general discussion - recommendations for short-term and mid-term direction All slides are available. Should be on GGF16 web (not yet!). In the meantime…

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 7 Links to slides Session #1 Introhttp://hepwww.rl.ac.uk/kelsey/ggf16authzws/intro.ppthttp://hepwww.rl.ac.uk/kelsey/ggf16authzws/intro.ppt LCG Biomed OSG Notes - session #1 Session #2 Von David Jens Yuri Christos Olle Notes - session #2 - number 1 notes1.txthttp://hepwww.rl.ac.uk/kelsey/ggf16authzws/session2- notes1.txt Notes - session #2 - number 2 notes2.txthttp://hepwww.rl.ac.uk/kelsey/ggf16authzws/session2- notes2.txt

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 8 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

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 9 LHC 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)

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 10 LHC 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

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 11 LHC 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)?

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 12 LHC 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

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 13 GGF16 Discussion Taken from notes Can we come up with a common format for FQN? –Basically, this is a problem in string standardization. Can we standardize resource description and job description, and does GLUE have anything to offer in this regard? We now have (almost) a standard syntactical representation of FQN. –Is it useful to address the semantics associated with roles at this time? We have a wide array of (possible) solutions to choose from, but we need to focus on one or two solutions so that we can move forward Two tracks: short-term "here and now" solutions and long-term vision GIN Goal: interop test at SC06 What agreements should we have in place a year from now? We need interoperable credentials, not common credentials. Determine issues here and now, prioritize them, and then invest development effort in the highest priority items. GGF OGSA-AuthZ WG looking for input Concrete interactions between GGFs are needed. (Too much intervening time between GGFs.) –How? When? Where?

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 14 MultiGrid Auth Group Input from Dane Skow MultiGrid = “Grid Interoperability Now” activity (GIN) –Aiming for SuperComputing 2006 –There is a GGF mail list for GIN AuthN/AuthZ They will discuss use of common role definitions A proposal: Group User: would be provisioned with the default permissions and capabilities for the standard usage of a resource by that group Role Admin: would be provisioned full permissions and capabilities allowed to the group managers (probably not equivalent to root access to a machine) Role Storage Admin: would be provisioned with the ability to read/ write/delete all files and directories owned by the group Role Priority Admin: would be provisioned with the ability to adjust priorities for queued requests by that group on a resource. (This probably implies the requirement for a common interface for manipulating priority of queued requests).

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 15 TONIC group This was shown, but no great enthusiasm! TONIC Taskforce Organizing Near-term Interoperation for Credentials Draft Charter: Community group formed to develop interoperation agreements to support various levels of interoperation between grids participating in the Grid Interoperation Now (GIN) activity. Create documents defining interoperation agreements for levels of interoperation. Act as an intermediate between the immediate needs of the production grid interoperation actions and the standards development process. Conclusion –GGF Security Area Directors to decide the way forward

Enabling Grids for E-sciencE INFSO-RI GGF16 AuthZ 16 MWSG discussion Scope? –EGEE and OSG only? Timeframe? –“Here and Now”?  2 years?  Timeframe of EGEE-II?  Developed, tested and deployed VOMS took 3 years What are the urgent topics? –Common role names?  “Without standardization of attributes, cross-domain authz is not possible” (Christos K) –Batch job priorities – how? –Data access? –More?