infso-ri-508833 enabling grids for e-science ggf16 workshop authorization interoperability (here...

INFSO-RI-508833

Enabling Grids for E-sciencE

www.eu-egee.org

GGF16 workshopAuthorization Interoperability (Here and Now)David Kelsey, CCLRC/RAL, [email protected]

EGEE MWSG MeetingCERN, 7 March 2006

GGF16 AuthZ 2


INFSO-RI-508833

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


INFSO-RI-508833

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


INFSO-RI-508833

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


INFSO-RI-508833

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


INFSO-RI-508833

Agenda – Session #2

Panel presentations & discussion - AuthZ interoperability issues and plans

Von Welch TeraGrid/OSG interoperation issuesDavid Groep EGEE framework and local PDP'sJens Jensen Data management AuthZYuri Demchenko GAAA/GT4 gap analysisChristos Kanellopoulos Ideas on interoperation/interoperabilityOlle 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


INFSO-RI-508833

Links to slides

Session #1Intro http://hepwww.rl.ac.uk/kelsey/ggf16authzws/intro.pptLCG http://hepwww.rl.ac.uk/kelsey/ggf16authzws/kelsey.pptBiomed http://hepwww.rl.ac.uk/kelsey/ggf16authzws/blanchetmollon.pdfOSG http://hepwww.rl.ac.uk/kelsey/ggf16authzws/cowles.ppt

Notes - session #1 http://hepwww.rl.ac.uk/kelsey/ggf16authzws/session1-notes.txt

Session #2Von http://hepwww.rl.ac.uk/kelsey/ggf16authzws/welch.pptDavid http://hepwww.rl.ac.uk/kelsey/ggf16authzws/groep.pptJens http://hepwww.rl.ac.uk/kelsey/ggf16authzws/jensen.pptYuri http://hepwww.rl.ac.uk/kelsey/ggf16authzws/demchenko.pdfChristos http://hepwww.rl.ac.uk/kelsey/ggf16authzws/kanellopoulos.pptOlle 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


INFSO-RI-508833

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


INFSO-RI-508833

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


INFSO-RI-508833


• 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


INFSO-RI-508833


• 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


INFSO-RI-508833


• 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


INFSO-RI-508833

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


INFSO-RI-508833

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


INFSO-RI-508833

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


INFSO-RI-508833

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?

infso-ri-508833 enabling grids for e-science ggf16 workshop authorization interoperability (here...

Documents