(see “Fermilab CD VO Briefing” - Lothar Bauerdick)
Integration Phase (WBS 1.3.3.1, 1.3.3.4)
-
Deliverable 1: (Jan 2003): Registration Schema
Definition for USCMS
a) the union of all information required for required site registrations –
see
document (http://computing.fnal.gov/projects/VO/VOProjectDefinition.htm)
b) timestamps of information
validation
c) identity of validator
d) the di-directional mapping of PKI identities to individuals.
e) list of roles/authorities permitted (with appropriate change control/logging
ala a-c) )
Apparently, this means registration confirmation from institutional representatives, site admin etc
See document http://www.uscms.org/s&c/VO/design/VOMRS_Architecture_3.doc
-
Deliverable 2: (Jan 2003)
A USCMS VO membership service to hold information about members according to
the above schema and their authorizations.
The schema must be able to be upgraded dynamically as new schema
elements are added. A change in the
schema should not require a complete shutdown of the registration systems.
Apparently,
this means that the request of new personal data should not required changes is
schema definition (Done: see document http://www.uscms.org/s&c/VO/design/VOMRS_Architecture_3.doc)
-
Deliverable 3: (April 2003)
The USCMS VO secretariat will have to develop with the resource providers, the
mechanisms and interfaces to register members with the various resource
providers that require registration (eg- USCMS Tier-1, Tier-2, Worldgrid,
etc.). There also will have to be an acknowledged information channel back to
the user to provide information and requirements like acceptable use policies.
Registrar will automatically notified reiterated administrators about new user registration. A mechanism is provided for administrator to pull information from VO and allow or deny access for a particular user. (Working prototype)
There must also be revocation authority.
Administrators will be able to deny access to their grid resources, vo admin can revoke/deny/suspend membership (working prototype). Valid CA is checked during authentication.
(Develop procedural, web form and documentation support for user account application and tracking. Work with the Fermilab account
management, security team, Certificate Authorities and CMS organization to provide an interface and guidance validation, assignment and tracking of accounts.)
(Web forms, CLI developments are in progress. We are working closely with Fermilab security team. The tools for local resource provider are developed – see LRAS. ) I do not understand what is guidance validation
-
Deliverable 4: (April 2003)
Documentation of the registration system, the interfaces, and the
infrastructure deliverable to the developers of AAA systems.
(SAZ and LRAS documentation is in alpha version; VOMRS
architecture and database schema has been published on the web)
-
Deliverable 5: (January 2003)
A simple well-defined registration mechanism and interim developer support to
handle registration until Deliverable 3 is ready.
I guess
this is in place already, out of VOX project scope
Deliverable 1: (Jan 2003)
Move away from group certificates on the DGT and the IGT. (Also relevant to
accounting.) Require the use of
personal DOE Science Grid certificates on the DGT and the IGT.
out of VOX
project scope
- Deliverable 2: (Jan 2003)
Deploy the KCA at Fermilab with appropriate attention to documentation for
support. Document the maintenance
requirements of the KCA, and maintain contacts with KCA providers for ongoing
supports and upgrades.
Done (out
of VOX project scope, but time spent was attributed to VOX)
-
Deliverable 3: (January/February 2003)
Pilot deployment of KCA with VOMS on the development grid testbed. We should be able to authenticate users with
KCA both onsite and offsite FNAL and authorize them to submit jobs from onsite
and offsite to run on FNAL resources. (Cross listed with Package 3, deliverable
2)
(KCA and VOMS EDG/Data Tag – are DPE and
tested)
-
Deliverable 4: (April 2003)
Require KCA certificates on the DGT and the IGT for batch jobs with arbitrary
payload destined for Fermilab.
(out of
VOX project scope)
-
Deliverable 5: (April 2003)
An interface or process by which a member of the Virtual Organization outside
of Fermilab can obtain KCA certification in a timely manner.
(work in progress to automated registration work flow; the negotiations with User Office to simplify registration requirements at Fermilab for grid users are in progress, but this is out of VOX scope)
- Develop the agreements with resource providers about acceptable authentication methods/tokens by request type. Engage in R&D on how to advertise, arbitrate, transport these. (Extend the gridmapfile mechanism for user authentication for grid simulation production jobs and incorporate the required Kerberos authentication to satisfy the Fermilab Strong authentication policies and provide a usable system for the CMS production system.)
(see LRAS
module http://www.uscms.org/s&c/VO/design/presentationofLRM.ppt and http://tam01.fnal.gov:8080/src/FNAL/vo/doc/html
)
-
Deliverable 1: (Jan
2003)
Deploy the EDG gatekeeper (with LCAS hooks) and provide LCAS modules to
implement:
a) enforcement of VO policy (use VOMS contents of proxy) – (out of VOX scope, extended proxy is provided by VOMS
EDG/DataTag)
b) enforcement of resource provider policy (site authorization callout) (done)
c) enforcement of resource policy (locally permitted users) (done)
d) SAS modules need to be written – (SAZ is
re-written, alpha version is deployed)
e) Include EDG gatekeeper into the VDT. (out of
scope of VOX, I think this is changed )
These should be basic modules.
Final modules will be provided later.
-
Deliverable 3: (April 2003)
Documentation of the VOMS client with a view to aiding support issues.
(not
started)
-
Deliverable 4: (Jan 2003)
Maintenance interfaces are needed for the appropriate people and roles to
update/access the VOMS information, integrated with registration interfaces.
a) secretariat to do initial data collection and validation
b) users to federate new identities referring to themselves (need to prove possession of an approved
authenticator)
c) authority delegation interface to grant/delegate authorities.
d) troubleshooting and incident handling
e) revocation of authorizations
(Are we talking about VOMRS client here? CLI is in prototype, web client is not started yet.)
-
Deliverable 5: (April 2003)
Redundancy, and distribution of VOMS system design needs to be done. VOMS will
have to be a high availability service for the collaboration's Grid.
(not started)
-
Deliverable 6: (Jan 2003)
Determine control point for resource allocation prioritization and enforcement.
Determine and implement the accounting/monitoring/reporting needed. Implement
the controls.
(out of
VOX scope)
-
Deliverable 7: (April 2003)
Determine responsibilities, method and interfaces for re-authentication and
re-authorization of long-running jobs (jobs that run longer than the lifetime
of the standard CMS proxy). Review Condor-G proposal. Deploy, debug, and
document if selected.
(out of
VOX scope)
(Cross cuts with VO Package 2) (Provide community authorization service for grid production job execution on Fermilab nodes to marry conformance to the the Fermilab Strong Authentication policy with the authorization mechanisms of the CMS simulation production system. The decision has been taken to use the EDG LCAS software in a modified version of the Globus gatekeeper. This must be used or incorporated into a version of VDT or CMS specific software. Short term work)
???? is this about SAZ and Globus callouts, if so it is done???
-
Deliverable 8: (April 2003)
Develop and document user helpdesk functions.
(not started)
-
Deliverable 1: (June 2003)
Ongoing support in place for the USCMS registration system, including some
fractions of trained DBA and Web support.
I wish we had this now: DBA to evaluate database shema and person familiar with jva servlet and web services
-
Deliverable 2: (June 2003)
A secretariat in place which will be the public face of the USCMS registration
system. Must maintain communication with international CMS and relevant
institutional authorities (including Fermilab) to make sure that user
information is up to date.
??????
-
Deliverable 1: (June 2003)
Ongoing support: Negotiate, monitor and troubleshoot service performance
levels.
(Will fill in more support deliverables later.)
????
-
Deliverable 2: (June 2003)
Final LCAS modules would replace the pilot ones used to facilitate the
installation of the EDG gatekeeper.
I guess this is in place, I do not know if this is final.
-
Deliverable 1: (June 2003)
Ongoing support for KCA on dedicated hardware.
(This is a Fermilab issue. But
we must make sure that the Fermilab support for Kerberos and KCA is wedded to
the CMS needs.)
(out of
scope of VOX)
Deliverable 2:
(June 2003)
USCMS provides a support pipeline to the KCA providers at Fermilab to troubleshoot
CMS user problems with KCA Authentication at Fermilab.
(out of scope of VOX)