GGF16 workshop Authorization Interoperability ( Here and Now)

1. GGF16 workshopAuthorization Interoperability (Here and Now) David Kelsey, CCLRC/RAL, UKd.p.kelsey@rl.ac.uk EGEE MWSG MeetingCERN, 7 March 2006

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) 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. 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 GGF16 AuthZ

5. Agenda – Session #1 10.30-10.35 Welcome, introduction and aims 10.35-11.00 The LHC experiments (particle physics) AuthZ requirements (David Kelsey) 11.00-11.25 The Biomed/EGEE AuthZ requirements (Christophe Blanchet/Rémi Mollon) 11.25-11.50 AuthZ in Open Science Grid (Bob Cowles) 11.50-12.00 Discussion 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 Mulmo Future 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… GGF16 AuthZ

7. Links to slides Session #1 Intro http://hepwww.rl.ac.uk/kelsey/ggf16authzws/intro.ppt LCG http://hepwww.rl.ac.uk/kelsey/ggf16authzws/kelsey.ppt Biomed http://hepwww.rl.ac.uk/kelsey/ggf16authzws/blanchetmollon.pdf OSG http://hepwww.rl.ac.uk/kelsey/ggf16authzws/cowles.ppt Notes - session #1 http://hepwww.rl.ac.uk/kelsey/ggf16authzws/session1-notes.txt Session #2 Von http://hepwww.rl.ac.uk/kelsey/ggf16authzws/welch.ppt David http://hepwww.rl.ac.uk/kelsey/ggf16authzws/groep.ppt Jens http://hepwww.rl.ac.uk/kelsey/ggf16authzws/jensen.ppt Yuri http://hepwww.rl.ac.uk/kelsey/ggf16authzws/demchenko.pdf Christos http://hepwww.rl.ac.uk/kelsey/ggf16authzws/kanellopoulos.ppt Olle http://hepwww.rl.ac.uk/kelsey/ggf16authzws/mulmo.ppt Notes - session #2 - number 1 http://hepwww.rl.ac.uk/kelsey/ggf16authzws/session2-notes1.txt Notes - session #2 - number 2 http://hepwww.rl.ac.uk/kelsey/ggf16authzws/session2-notes2.txt 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 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) 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 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)? 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 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? 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). GGF16 AuthZ

15. TONIC group This was shown, but no great enthusiasm! TONICTaskforce 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 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? GGF16 AuthZ