VO Services Architecture

1. 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 Gabriele Garzoglio

2. VO Services VOMRS VOMS synch synch ID Mapping? Yes / No + UserName CE WN SE gLExec SRM Gatekeeper Prima gPlazma / Prima Prima Submit request with voms-proxy Pilot SU Job (UID/GID) Submit Pilot OR Job (UID/GID) Storage Legend Batch System AuthZ Components VO Management Services VO Services Architecture VO Grid Site Site Services SAZ GUMS 3 2 7 6 Is Auth? Yes / No 1 register 4 get voms-proxy 5 10 Access Data (UID/GID) Schedule Pilot OR Job 8 8 9 Gabriele Garzoglio

3. 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 ? Gabriele Garzoglio

4. 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 Gabriele Garzoglio

5. 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 ? Gabriele Garzoglio

6. 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) Gabriele Garzoglio

7. GUMS vs. gridmap-files Gabriele Garzoglio

8. 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? Gabriele Garzoglio