Task Force (TF) meeting of 2004/09/15-17

Participants:
Maria Dimou, Joni Hahkala, David Kelsey (16-17/9 only), Tanya Levshina, Karoly Lorentey, Ian Neilson.

Agenda: Approved in advance via email, it can be found in http://cern.ch/dimou/lcg/registrar/TF/meetings/2004-09-15/agenda .

Wednesday 15/6 am:

Introduction by Ian:
This TF was formed in order to make the User Registration and VO management tools compliant to the Requirements' document and the relevant Proposal presented at the 2004/07/13 Grid Deployment Board (GDB).

This meeting aim was to discuss in detail:

1. ORGanisational DataBase (ORGDB) integration with the VOMS database (db). For the TF's mandate, which only concerns the LHC experiments' VOs, the ORGDB in question is specifically the CERN HR db.
2. VOX/VOMRS and VOMS co-existence and inter-working as well as partition of the relevant development work.
3. Milestones' clarification and concrete action planning.

Savannah tickets' analysis by Maria:
There is a problem to find all the VOMRS/VOMS-related tickets in savannah if there is no such string in the "Summary" field. Maria assembled the relevant tickets in http://cern.ch/dimou/lcg/voms/savannah_entries_on_VOMS_VOMRS.html to facilitate the discussion. She asked the savannah maintainers to enable more flexible searching, because with the current possibilities we risk to miss tickets.

(*** ACTION ***) On Ian's suggestion Maria will create 3 savannah tickets containing all the existing VOMS/VOMRS-related tickets across groups per category (Major, Normal, Enhancements).

Ticket 4699: This is of the category "Major". (*** ACTION ***) Joni should edit the summary to add the "VOMS" string and remove the names of the users, not to disclose, indirectly, the names of the VO members.

Ticket 4700: This is of the category "Normal". (*** ACTION ***) Joni should edit the summary to add the "VOMS" string.

Ticket 4285: This was registered by D.Smith. It is not related to VOMS but to the UI. Please read Maria's comment on the ticket itself.

Ticket 860: Maria closed this ticket with Karoly's anwer. She opened ticket 1185 to describe the task of defining what to store on user's CA information. Please read the tickets for details. (*** ACTION ***) Tanya: VOMRS should also store the user certificate serial number and his/her CA's contact URL.

Ticket 861: This is on LDAP-VOMS synchronisation. By the time these notes are being written, Karoly modified the relevant scripts. (*** ACTION ***) Tanya will pass this ticket's URL and the "How to generate the grid-map file" document to Vijay Sekhri <sekhri@fnal.gov> .

Ticket 908: This is about setting the ACLs appropriately to allow a foreign host to access the VOMS server in order to list the members of a VO and it remains relevant as long as we use the grid-map file. Maria updated the ticket with comment: "Implement the *option* to allow *every* host from a *known* CA to list the VO. This must be an option because some VOs (e.g. biome) have needs for strict restrictions. Tanya recommends no restriction between users and hosts as members of a VO, i.e. the alternative procedure linked from the "How to generate the grid-map file" document . Karoly proposed the usage of "Groups" or "Virtual DNs" to incorporate accepted users.

Ticket 1096: This concerns voms-admin "Enhancements". They will only be relevant to non-LHC VO users because the latter will be using VOMRS, as decided later on during this meeting. Maria updated the ticket to add the paging requirement for both tools as suggested by Tanya.

Ticket 1098: This is classified "Enhancement" and will be done in VOMRS and VOMS. Please see the ticket for details.

Ticket 1132: (*** ACTION ***) Tanya will make the necessary changes so that newly registered VOMRS users don't receive 2 almost identical emails when they pass from status "New" to "Approved" in the VO. By this date, Maria completed her action on making sure VOMRS notification emails will never fall into spam again. She informed the TF by email on the reasons and the solution (whitelisted the string "VOMRS" at the CERN central email gateway level).

Tickets 1133 and 1141: Discussed with Tanya, understood and closed by Maria. The reason was that Maria's certificate had expired. It would be good if the error message were not so misleading. (*** ACTION ***) Tanya should re-open the ticket if such an enhancement can be envisaged by the VOMRS developers.

Ticket 1136: This is about CVS locations for EGEE and LCG software. (*** ACTION ***) Maria should make a CERN afs account for Tanya and do the necessary for her to obtain CVS access.

(*** ACTION ***) Tanya will enter in the savannah group lcgoperation the bugs she has observed. Example: Simultaneous "commit" of changes via the User Interface and the VOMS db API causes the db tables to go out of sync. This is, most probably not a database problem but an application problem of voms-admin.

(*** ACTION ***) Karoly will make sure that bug fixes of the savannah group lcgoperation will be made available in the development branch as well (JRA1) and vice-versa, i.e.bug fixes for tickets in the savannah group JRA1mdw will be fed into the EGEE and LCG development/deployment CVS.

(*** ACTION ***) Joni will register in the savannah/JRA1mdw category the task (classify = Major) to allow VO names of more than 6 characters to be accepted. This is not a problem for LHC experiment VOs but it will be for several EGEE ones. VO=NA4test is already defined and it is one of them. The solution should be found between Joni, Vincenzo, Karoly and Akos.

(*** ACTION ***) Create a new savannah ticket on VO nicknames and multiple DNs. By the time these notes are written Ian created Ticket 4861.

Wednesday 15/9 pm and Thursday 16/9 am:

Discussion on ORGDB link:
There was a long discussion on Expiration Dates, the necessity for the VO manager to enable the acceptance of the user in the VO (Tanya found this redundant), the mechanisms to matchMember in ORGDB and the amount of information that needs to be stored until the VO manager enables the user. We also discussed data appropriate for auditing, without actually keeping sensitive Personal User data in logs that may be viewed by unauthorised users. We referred many times to the Requirements' document and the relevant Proposal presented at the 2004/07/13 GDB in order to conclude on our implementation choices, summarised later on in these notes.

(*** ACTION ***) Karoly to email the following questions to Wim van Leersum (ORGDB expert) and make the answers available to the TF:

• The number of and the significance of the Participation_End_Date field. We have conflicting answers from the LHC Experiment secretariats and the CERN Users' Office (see Questionnaire answers).
• Is there a Contract_End_Date? What is its connection with the Participation_End_Date?
• If >1 records in ORGDB contain the same email address, presumably belonging to the same person, will this user have >1 ORGDB_IDs?
• What is the indication on a record that someone is still a valid member of ORGDB?
• How can one update his/her birthdate in ORGDB?

(*** ACTION ***) Karoly, with his Oracle login, search in ORGDB and relay results to the TF:

• ORGDB members without Participation_End_Date.
• ORGDB members with Participation_End_Date in less than 6 months. This will give us an idea on how many notifications to re-register we expect to be launched once the new mechanism is in operation.
• Are there records in ORGDB with an empty birthdate field?
• Do the External (EXTN) users have their birthdate in their record?

The answers on the above will help us decide whether we should use the Contract_End_Date or Participation_End_Date to calculate the initial value of the VODB_Expiry_Date or not. They may also result to a recommendation to CERN IT Management on information quality improvement for CERN HR db. (*** ACTION ***) Maria.

Even if the user remains for years in ORGDB, the VODB_Expiry_Date will be reached every year according to the requirements. A user notification will be issued X days in advance (X tailorable by the VO manager in a configuration file). When users disappear from ORGDB they should automatically expire in VODB (cron job will check ORGDB changes) and a user notification will be issued.

The ORGDB view with the necessary and sufficient Personal User data, according to the Requirements' definitions may need to be tailored according to experiments' rules (*** ACTION ***) Karoly and Maria to investigate and inform the TF.

Thursday 16/9 pm:

VOMRS demo:
Tanya showed the user interface to the participants. (*** ACTION ***) Maria who is a registered member will make available to the TF a list of features.

The changes required in VOMRS to cope with the LCG Requirements (Tanya's notes incorporated) are:

• To be delivered in February (items ##4,7,8,9,10 must be done anyway in order to comply to the relevant requirement).:
  1. Implement a registration procedure that will be using the ORGDB link to find the appropriate match for the candidate member. The user's ORGDB record should carry the specific experiment that corresponds to the VO he/she is applying. If he/she is found "Expired" because he/she moved to work for another experiment, a friendly notification should inform him/her that they should probably register with that other VO.
  2. Implement an additional web interface and Web services that allow the VO manager to select the most suitable match in case of multiple entries in ORGDB.
  3. Implement a Validation procedure that will be using the ORGDB interface to regularly check every VO member's data and affiliation to the VO.
  4. Implement e-mail verification before going through the matchMember with ORGDB.
  5. Modify the Registration form so the appearence of the Institute and Institute Representative fields could be configurable (they will be taken from ORGDB for the LCG VOMRS).
  6. Mark clearly on the form which fields should be filled by the user.
  7. Make the approval by the VO manager mandatory for adding a member to a VO. Today's VOMRS completes VODB registration after IR's approval.
  8. Allow the VO manager to approve or deny any additional DN/CA added by the user.
  9. Implement the VODB_Expiry_Date, issue an email notification to the member on that and add "Expired" status to the list of available statuses.
  10. Add a "reason" field to any status, it should be filled by the VO manager for every status modification.
• To be delivered after February:
  1. Associate "Group Role" and "Role" with each DN & CA and not just with members.
  2. Allow a member to select his/her Group and Role and the VO manager (Group Owner/Manager) to approve or deny the selection.
  3. Sign all e-mails form VOMRS with the certificate where the VODB runs, e.g. alice-vo-registrar.cern.ch.

A VOMRS Registration flow, prepared by Tanya can be found here.

Friday 17/9:

Karoly and Tanya had a private meeting to discuss technical implementation details. Then Tanya drew a detailed walk-through the user registration procedure where the multiple iterations of matchMember in ORGDB were discussed in detail.

The number of discrepancies in the candidate's personal data between the VOMRS form contents and his/her ORGDB record were debated at length. It will be at the discretion of the VO manager to accept name spelling discrepancies but the email should be identical as it is about the only information that uniquely identifies the user.

The number of failed-to-match attempts that can be tolerated before the user is 'banned' (and for how long) was also discussed and decided to leave it at the discretion of the VO manager, i.e. make it configurable, log everything and send the trace to the VO manager. The users remain in "Applicant" status until the reach a successful match.

Certificate delegation will not be allowed. The VO manager will approve an entry if the DN appears to belong to the requestor.

(*** ACTION ***) Tanya expressed worries that US-CMS users won't accept to type their birthdate, even if it is only DDMM (no year) and even if it is not logged in clear, simply a string saying that it was provided. She also said they might be reluctant to register in CERN HR db, even if this is LHC experiment policy. She should give the TF feedback from discussions on this matter with her community.

(*** ACTION ***) Someone (Maria?) should give the VO managers and resource administrators a recommendation on usage of Groups (Group Roles) and Roles. The VOMS-admin "Capabilities" attribute will not be used.

(*** ACTION ***) Maria create savannah ticket for VOMS admin and VOMRS to set Return-email-address to the one of the VO manager for user notifications that can't reach the recipients.

(*** ACTION ***) TF to re-discuss the Usage Rules re-acceptance prompt in more detail.

Decision summary (Tanya's notes incorporated):

1. Users will use the VOMRS web form as a registration tool for all LHC experiment VOs. Their Personal User data will be linked from ORGDB via a VOMS-admin API (to be developed by Karoly) for VO manager's evaluation and approval/denial of the candidate user.
2. There will be one VODB per LHC experiment. The issue of VOMS db replicas has to be re-discussed in more detail. However, it is clear that no Personal User data will reside anywhere else but in ORGDB and it won't be replicated to the sites.
3. Non-LHC VOs, e.g. dteam, sixt, biome, na4test etc will be using the VOMS-admin interface, as their user community doesn't have to be in the CERN HR db.
4. VOMS admin software will be supported by Karoly Lorentey and all reported bugs will be fixed. (*** ACTION ***) LCG deployment management has to plan for maintenance continuity after Karoly's departure from CERN).
5. EDG trust manager will be supported by Joni Hahkala and all reported bugs will be fixed. (*** ACTION ***) LCG/EGEE management has to plan for maintenance continuity after Joni's departure from CERN).
6. VOMRS will be installed at CERN and Maria will perform all the necessary testing of the software.
7. Ian Bird officially confirmed the LCG commitment to use VOMRS. It is now up to the FNAL management to approve the necessary resources for the required development and further support.
8. (*** ACTION ***) Ian should investigate with the LCG Deployment management whether resources could be found elsewhere in the community to assist Tanya in the VOMRS development work.

Maria Dimou, IT/GD, Grid Infrastructure Services