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 VOMS DB VOM Registration Server VOM Registr. Client register notify VOM Proxy Server User VOM Admin Job Broker Kerberos Ticket Extended Proxy JOB notify VOM API Local Center Registration Service Site Admin SAZ Server SAZ DB Security Admin Client Security Admin gridmap file LRM Server LRM Client Sys admin Legend GUI Server File/data Out of scope of the project Registration flow Submission flow LRAS DB LRAS Server LRAS Client LRP VOM API update Grid SiteGrid Resource Gatekeeper LCAS GSI SAZClient

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 ClientIF DB Web Services /Servlets CLI Member WEB CLIENT Registrar Event Manager Server

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!

WEBUI Examples (General Information)

WebUI Examples (Member Registration)

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 LRAClientSAZClient LRAServerSAZServer LRADBSAZDB Callouts GSI Authentication & Authorization Checks in DB to see if the user is authorized or not

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 AIClient AIServer SAZClient SAZServer SAZDB Kerberos Authentication GSI Authentication Only Select query Select,Update,Insert and Delete 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) 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 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)