VO Services Architecture

8
Gabriele Garzoglio July 2007 1/16 OSG IS and ReSS VO Services Architecture Gabriele Garzoglio Computing Division, Fermilab OSG User Meeting Jul 2007 Overview Overview of the Architecture Main Stakeholder’s Requirements GUMS vs. gridmap-files Questions for OSG

description

VO Services Architecture. Overview Overview of the Architecture Main Stakeholder’s Requirements GUMS vs. gridmap-files Questions for OSG. Gabriele Garzoglio Computing Division, Fermilab OSG User Meeting Jul 2007. VO Services. VOMRS. VOMS. synch. synch. ID Mapping? Yes / No + - PowerPoint PPT Presentation

Transcript of VO Services Architecture

Page 1: VO Services Architecture

Gabriele GarzoglioJuly 2007 1/16

OSG IS and ReSS

VO Services Architecture

Gabriele GarzoglioComputing Division, Fermilab

OSG User Meeting Jul 2007

Overview• Overview of the Architecture• Main Stakeholder’s Requirements• GUMS vs. gridmap-files• Questions for OSG

Page 2: VO Services Architecture

Gabriele GarzoglioJuly 2007 2/16

OSG IS and ReSS

VO Services Architecture

AuthZ Components

Legend

VO Management Services

GridSite

GUMS

Site Services

SAZ

CEGatekeeper

Prima

Is Au

th?

Ye

s / No

SESRM

gPlazma / PrimaID

Ma

pp

ing

?Y

es / N

o +

Use

rNa

me

VO Services

VOMRS VOMSsynch

reg

iste

r

get voms-proxy

Submit request with voms-proxy

synch

1

4

5

672 3

WNgLExec

Prima

StorageBatch

System

Su

bm

itP

ilot O

R Jo

b

(UID

/GID

)

Acce

ssD

ata

(UID

/GID

)

8 8

Sch

ed

ule

Pilo

t OR

Job

9

Pilot SUJob

(UID/GID)

10

VO

Page 3: VO Services Architecture

Gabriele GarzoglioJuly 2007 3/16

OSG IS and ReSS

Stakeholders’ Main Requirements 1

• It should be possible to control access privileges to resources according to the VO organizational structure– Role/Group-based access to resource– Are you supporting Role/Group-based authorization to your resources?

• It should be possible to establish an execution environment that protects user’s processes and data– Use UID/GID-based OS protection mechanisms (process interaction,

FS access control, etc.)– Give each user an individual account, even if access decision is based

on user’s group and role (Pool accounts)– Sites create pool accounts for requesting VOs OR one pool account for

all “opportunistic” VOs. Have you thought what’s best for you?• It should be possible for a group of users to share the same

execution environment– Grid identity mapping to same UID/GID (Group accounts)– Today, are people concerned about giving each member of the group

access other group member’s credentials ?

Page 4: VO Services Architecture

Gabriele GarzoglioJuly 2007 4/16

OSG IS and ReSS

Stakeholders’ Main Requirements 2

• It should be possible for a user with a personal account at a site to be mapped to that account when entering the site via grid interfaces– Use grid identity to identify local account by

interacting with user directory services (LDAP, etc.)

• It should be possible to manage access control policies centrally at a site– Site-centric instantiation of the Policy Decision Point

(GUMS)– How many resource gateways (gatekeepers, gridftp,

SRM, …) do you maintain at your site today

Page 5: VO Services Architecture

Gabriele GarzoglioJuly 2007 5/16

OSG IS and ReSS

Stakeholders’ Main Requirements 3

• It should be possible for a user to run a job with the user/group/role’s privileges even if the job is handled by a pull-based Workload Management System (WMS). – In pilot-based job submission (e.g. Panda, Condor Glide-in, …),

pilot jobs occupy a batch slot via standard grid mechanisms, then pull the user job from a VO queue

– The user job must run with the user’s privileges, NOT the pilot privileges

– The pilot job can use the gLExec command in order to “su” to the user’s UID/GID

– Are you planning to support pilot jobs at your site? Do you plan to support user’s process and data protection ?

Page 6: VO Services Architecture

Gabriele GarzoglioJuly 2007 6/16

OSG IS and ReSS

Stakeholders’ Main Requirements 4

• VO’s should be able to appoint VO/group/subgroup/role representatives to manage user membership– VOMRS manages the registration workflow according

to VO policies. VO can define VO administrators, delegate responsibilities, etc.

• The VO Registration system should be able to interface to HR databases to get existing user attributes– VOMRS can interface to 3rd party HR databases

(examples: FNAL, CERN, SAM)

Page 7: VO Services Architecture

Gabriele GarzoglioJuly 2007 7/16

OSG IS and ReSS

GUMS vs. gridmap-filesSupport group/role-based mapping to local UID/GID

• Supports pool accounts

Supports only DN mapping to UID/GID

• No facility to manage pool accounts

Policies are managed centrally at a site

One mapping policy (gridmap-file) per resources

Requires to run a set of services (Tomcat / MySQL)

Requires the maintenance of only 1 file

Data is entered through interfaces (some consistency check)

Sometimes difficult to spot typos (extra “, etc.)

Page 8: VO Services Architecture

Gabriele GarzoglioJuly 2007 8/16

OSG IS and ReSS

Open Questions for OSG

• Claim: “The overhead of administering GUMS outweighs the advantages for small sites”. – Is a site that does not support role-based

authorization useful to the OSG VO?– What is a “small” site?– Can GUMS admins comment on the

administration effort for GUMS?– Do you feel that your concerns are properly

addressed by the VO Services support team?