EGEE is a project funded by the European Union under contract IST New VO Integration Fabio Hernandez ROC Managers Workshop, May

Milan, May 10-11, Contents Objective Overview of the procedure Case study: VO management in LCG Implementing the procedure  Short-term solution  Mid-term solution

Milan, May 10-11, Objective Identify the procedure to bring a new virtual organization into the EGEE grid infrastructure Identify the tools needed to support the procedure Adopt an implementation strategy for the procedure  Both for short and long term

Milan, May 10-11, Proposed Procedure Step 1: new VO acceptance by the operations group  VO representative requests inclusion through the OAG During the lifetime of the EGEE project this request must be done by NA4 Should include some (even rough) estimation of requested resources May include already identified RCs which agree on providing resources for the VO Must include an appointed VO manager  OAG advises operation management on the opportunity of including the new VO  OMC requests ROCs to identify RCs willing to provide resources for the new VO’s users There should be at least one of them

Milan, May 10-11, Proposed Procedure (cont.) Step 2: identify one or more CICs/ROCs to run core grid services for the new VO  VOMS, RLS, RB, UIs, BDIIs, …  identify one CIC responsible for coordinating the set up of these services Step 3: when the VO services are ready, inform the registrar so that the user registration procedure include the newly accepted VO  Assuming we want a unique registrar for all the users of the EGEE grid  More on this later Step 4: RCs providing resources to the new VO must modify some configuration files Step 5: the new VO users can then start registering and are allowed to enter the grid!

Milan, May 10-11, Case Study: LCG Unique registrar for all supported VOs  Run by CERN  Currently accepting the 4 LHC experiments, Babar, D0 and the LCG Deployment Team VO  User information includes contact information (family name, given name, home institute, address, telephone number and VO affiliation) Currently one individual can belong to only one VO at a time When a new user (holding a user certificated issued by an accepted CA) fills the registration form…  A new entry in the registrar’s data base is created  The request is forwarded to the VO’s manager for approval and inclusion in the VO’s data base The registrar’s data and the VO’s data can be queried through the LDAP protocol  Used by RCs to grant users access to grid resources

Milan, May 10-11, Case Study: LCG (cont.) A separate management service is run for each VO  Currently they are all LDAP-based  The VO manager(s) adds/deletes entries in the LDAP data base No authorization information is stored in the VO data base  Every VO member has the same privileges when accessing grid resources A few members of the each VO have the role of Experiment Software Managers  They have appropriate permissions to modify the experiment’s installed software on RCs

Milan, May 10-11, Implementing the Procedure: Short Term Solution NA4 requested the inclusion of a bio-medical VO in LCG-2 (a.k.a. EGEE-0)  Need to identify RCs willing to provide services for this VO  Two sites in France will: IN2P3 Lyon and IN2P3 Clermont-Ferrand  Anyone else from other regions? Set up a LDAP-based VO management service  This allows for compatibility with the procedures and tools in use by LCG-2  Currently being done in Lyon

Milan, May 10-11, Implementing the Procedure: Long Term Solution (?) Set up VOMS-based service for bio-medical VO  Upward compatibility guaranteed  This will be done in Lyon as soon as the LDAP-based service is up and running  Migration path from LDAP-based to VOMS-based is available

Milan, May 10-11, VOMS Virtual Organisation Membership Service DataGRID middleware Grid service which allows a user to prove he is a member of a VO and that he has certains roles within the VO Features  A user can belong to more than one VO  A user can belong to several groups within a VO  A user can have several roles within a VO Authorization information is embedded in the user grid credentials  Grid services contacted by the user use this information to granting/revoking access to resources  Trust relationship between RCs and the VO

Milan, May 10-11, Questions Should national/regional VOs follow the same procedure? Do we want a unique registrar for the whole grid?  Unique entry point for new users  Who will run it? Can we share the registrar with LCG?  Registrar may be unavailable for a period of time without (big) impact for the service  However, it contains information that is very useful from the operations point of view, namely the users contact information Do we want in the long term to replicate registrar to provide high availability? Do we need an ‘Operations’ VO for people deploying the software?  Something similar to ‘dteam’ in LCG-2 but restricted to operations people Do we need a ‘Guests’ VO for people not belonging to one of the accepted VOs?  For letting people to become familiar with the infrastructure, for instance