170 likes | 190 Views
This status update provides insights into the progress of the VOX project, focusing on registration flow, collaboration with VOMS EDG team, and system components development. Explore the latest advancements in VOMRS services and LRAS functionalities.
E N D
VOX Project Status T. Levshina
Talk Overview • VOX Status • Registration • Globus callouts/Plug-ins • LRAS • SAZ • Collaboration with VOMS EDG team • Preparation for GRID3
VOX Architecture notify Legend GUI Server File/data Out of scope of the project Registration flow Submission flow VOM Admin User Job Broker Kerberos Ticket VOM Proxy Server Grid Resource Extended Proxy LRAS Client notify VOM API LRP Gatekeeper LRAS Server Grid Site VOM API LCAS LRAS DB Site Admin Security Admin Client Security Admin gridmap file LRM Server JOB LRM Client SAZClient SAZ DB Local Center Registration Service Sys admin SAZ Server GSI VOM Registr. Client update register VOMS DB VOM Registration Server
VOM Registration Service • VOMRS provides the following services: • allows single access to registration with VO • facilitates, negotiates and monitors the process of member’s acceptance to grid resources • provides centralized storage of • members DNs,CAs and their personal data • VO institutions and their representatives • VO affiliated grid resource administrators • provides means to query this information • VOMRS consists of: • VOM Registration Server • Web services • Web GUI/Servlets • Command line interface • Registration database (VOMS DB)
VOM Registration Service Components Member Server Registrar Event Manager ClientIF CLI DB Web Services /Servlets WEB CLIENT
VOM Registration Service(Status of component specification and code development) • VOMS DB: • Design is done • Schema is deployed • mysql (for now) • 19 tables • Review just started • VOM Registration Server, Registration API • Design is done • Prototype is deployed • VOM Registration Client • Developed primitive client to exercise server functionality • Started requirements collection (No clear understanding who should provide them) • Web UI • Work has been just started • Again: no requirements, we have to invent them!
Issues It is clear that requirements are evolving and there are many questions that need to be addressed: • How the member’s status is affected if his/her representative: • left the institution • got suspension • What actions are needed when member changes: • Affiliation • Personal information • Primary DN,CA • What happens with members that belong to the institution that is dropped out from VO? Should site, local administrators be notified about it? • Does VO responsibilities include member’s notification about changes in member’s status? • How to handle registered member when his certificate has expired? …
VOX Local Services Gatekeeper Callouts LRAClient SAZClient GSI Authentication & Authorization LRAServer SAZServer Checks in DB to see if the user is authorized or not LRADB SAZDB
Globus Callouts/Plug-ins • SAZ plug-in checks with SAZ server if user has been authorized to use grid cluster Done • Allow/Deny plug-in checks with LRAS if user has access to local grid cluster Done • Timeslot plug-in check with LRAS if user is allowed to run during current timeslot Not started • Mapping plug-in (gridmapfile replacement) allows mapping of user certificate to user unix account Not started
LRAS Local Resource Authorization Service (LRAS) – automates and facilitates the process of managing fine grain access to a local grid Element. It performs the following actions: • pulls information from VOMRS (EDG VOMS service for now) about members (dn,ca) that belong to particular groups • populates local databases with this information • associates VO member with the local account based on the member’s group • controls access to grid resources by changing member status in local database • can notify VO Registration Server that local site is ready for user to submit jobs.
SAZ UIClient Select,Update,Insert and Delete query AIServer Kerberos Authentication AIClient SAZDB GSI Authentication SAZServer SAZClient Only Select query • Admin uses AIClient to insert,delete,update any user DN’s, principals and status. He is authenticated using Kerberos. • User uses UIClient to insert,delete any user’s DN but with his own principal. He is authenticated using Kerberos. • Both Clients talk to AIServer for authentication. • AIServer handles SAZDB (MySql). • SAZClient is invoked from Gatekeeper. • SAZClient talk to SAZServer and passes User’s Cert Chain for authorization. Client is authenticated using GSI. • SAZServer extracts DN from User cert chain and looks in SAZDB for authorization. It also checks for CRL,signature verification and signing policy.
Collaboration with VOMS EDG team • Regular contacts with Vincenzo and Akos (installation problems and questions, bugs report, requirements discussions).Hope for more discussions when Vincenzo visits Fermilab at the end of September • VOX Project • Use core VOMS package to generate extended proxy • Use EDG Java Trust Manager for certificate validation • Still in discussion with VOMS admin team how to collaborate. Some of the proposed approaches are: • Allow VOMRS to be VOMS client (non intrusive approach) • Extend VOMS database and code to accommodate VOX requirements • Any input? We are open for any suggestions… • Grid3 (see next slide) What are LCG plans regarding VOMS core and admin services m?
What is GRID3? Grid2003 (Grid3) is a coordinated project between iVDGL, GriPhyN, PPDG, and the physics experiments, principally being led by USCMS and USATLAS. The purpose of the Grid3 is a project to build a grid environment to: • Provide the next phase of the iVDGL Laboratory • Provide the infrastructure and services need for LHC production and analysis applications running at scale in a common grid environment • Provide a platform for computer science technology demonstrators • Provide a common grid environment for LIGO and SDSS applications
VOX and GRID3 • Phase I (VOMS EDG ) – GRID3 wide distribution • Install VOMS core and admin services for multiple VOs: CMS, ATLAS, iVDGL, SDSS etc • Hands on workshop provided for BNL/ATLAS and SDSS (some issues are still remain with SDSS installation) • VOMS databases will be populated by responsible VO Admin • VO Admins are gathering needed information • VDT 1.1.11 will include the script provided by VOMS admin service as a cronjob to populate gridmapfile from VOMS database (released by September 7) • Later VDT will include VOMS core and admin services (released by October 2003?)
VOX and GRID3 • Phase II (Site Authorization) – Fermilab specific • Install SAZ at Fermilab (released by October/November 2003) • Provide adequate packaging, so SAZ can be installed at any interested site (Looking for alpha users …) • Populate SAZ database with potential users (via SAZ UI) • Each job submitted to Fermilab via gatekeeper will be checked against SAZ database by using Globus callout to allow/deny user access to Fermilab • SAZ Administrators control access via SAZ ADMIN UI • Phase III (Local Resource Control Access) • Local administrator will have the following options to control fine grain access to resources • Static Gridmapfile (in place) • Gridmapfile populated via VOMS makegridmapfile script (in vdt by 9/7) • GUMS package (BNL) (ready) • LRAS package (Fermilab) (released by November 2003)