Task Force meeting of 2004-06-14

Participants:
Maria Dimou, Joni Hahkala, David Kelsey, Tanya Levshina (on the phone from FNAL), Ian Neilson.

1. Reminder of our Mandate and evaluation of its present status:

• 1a. Goal: "Meet the robust registration process as now proposed in the Requirements" document.
  Discuss what is the part of the required information, as defined in the above document that should reside in the VODB, hence validated and maintained by the VO manager and which part of the information may (be required to) reside in the ORGDB, the maintainers of which retain the obligation to provide high quality data.
• 1b. Goal: "Investigate the use of existing sources of information."
  Ian and Maria report on consolidated results of the Questionnaire to the experiments. At the time of the meeting, we only have the ALICE answer. Latest information will always be in our directory http://cern.ch/dimou/lcg/registrar/TF
• 1c. Goal: "Achieve all possible compatibility between the requirements and existing proposed solutions."
  Given the incomplete status of 1b (answers still pending and conclusions not yet finalised) this item can't be discussed exhaustively in this phase. However, we could make a plan for future meetings and deliverables where Tanya and Joni will share with us their technical insight on how VOMS and VOMRS could link to the ORGDB, depending on the outcome of 1b.

2. Decide on the content of our Proposal for the 13 July GDB. Suggestion: limit this proposal to 1a and 1b and request a date for our outcome on the 1c goal.

3. A.O.B.

Discussion on 1a:

The basic assumption is that, as long as we discuss the LCG Grid specifically, then ORGDB is the CERN HR db due to the rule that LHC collaborators have to register in there. The terms Registration Data, Personal user data etc are used below as defined in the Requirements' document. We started the discussion on what information is part of VODB and what should only reside in ORGDB by presenting and analysing the pros and cons of the following views:

1a.a. Explained by Ian: VODB only contains the user's DN and the indication/flag showing whether he/she is in "Suspended Status". The VODB record of the user is necessary because of the basic requirement that registration should be 'user-driven', meaning they have to record their acceptance of the Usage Rules. No Personal user data will be present in the VODB. They will all be linked dynamically from the ORGDB record of the user via his/her ORGDB_ID which will be stored in VODB. Private user information additional to his/her Personal user data, e.g. salary, children etc will not be accessible at all. Basically the VODB will contain Authorisation (AuthZ) information. The Authentication (AuthN) information will only reside in ORGDB but they will not be fed automatically in VODB. It will be the VO manager who will have to take action in order to enable the candidate entries.. Users who are absent from ORGDB will have to be prompted to register there first. The registration steps will have to be explained on a documentation web page in a way that users don't try to fill the VODB form before they fill the ORGDB one. E.g. Step 2 on page http://lcg-registrar.cern.ch should become something like: "Check if you are registered in the CERN HR db and, if not, go through the Registration process" and the other points on VO registration should follow. Access to Registration Data for authorised public, e.g. site administrators. will be possible via queries to the VODB. No direct access to ORGDB will be allowed.

1a.b. Explained by Tanya: VODB can contain all of the AuthN and AuthZ information of the user, if he/she is not present in ORGDB, or even more information about the user than the limited set of Registration Data as defined in the Requirements' document, for maximum extensibility and flexibility. Each VO manager would freely decide which information source to use. Personal user data privacy is ensured by the VOMRS design which foresees a limited set of authorised people allowed to read this information. In this way, the only interface the user will know will be the one of VODB and his/her data will be fed-in ORGDB automatically if he/she doesn't already have a record.

1a.c. Explained by Dave: The GDB will probably require maximum flexibility by means of accepting users without verification by the VO manager if they are present in ORGDB, i.e. their initial requirement that gave birth to this Task Force, but also allowing for new users (not in ORGDB) to register with the VO without a prior ORGDB registration. This will also solve the problem of:
- those who want to be part of a VO even if their Institute doesn't participate in it or
- those who want to be in multiple VOs for testing purposes, affiliation not justified by their ORGDB record.

Discussion on 1b:

Given the limited response we had from the experiments at the time of our meeting (ALICE only) the discussion was centrered around:

1b.a. Which data exactly will the user have to fill in the web form of the VODB candidate request tool. Dave felt that it is worth requiring all of the defined Registration data, an additional way to double-check that the user is, indeed, the one he/she claims to be. Multiple possible spellings of the same name remain a challenge for the parsing of the data and the matching with the relevant ORGDB entry (if it exists). The CERN ID number, which appears on the access card to the CERN site, could be a candidate matching field for evaluation because of its uniqueness. This information will not be accessible for reading by the sites or other authorised users.

1b.b. External (EXTN) as explained by the experts of the PIE interface to the CERN HR db are a problem because they will be numerous in the LCG user community and they don't undergo robust validation in today's registration procedures.
(*** ACTION ***We need to demonstrate this to the GDB).
In fact, if AuthN data have to be taken from ORGDB, then all EXTN users will have to be required to register with ORGDB to avoid maintaining information up-to-date in 2 databases. Dave suggested that we (*** ACTION ***)count the number of members in today's (LDAP) VOs who are not in ORGDB.

Discussion on 1c:

This discussion could not be conclusive, as explained in the agenda, due to the pending issues for clarification concerning the usability of ORGDB information. Some concerns were expressed by Tanya about the availability of ORGDB APIs easily usable by VOMS and VOMRS developers for database linking. As we had understood we will get access to a database table view, we should understand better what information can be made available to use and in which form.
(*** ACTION ***: Tanya will write the question for ORGDB administrators and Ian/Maria will forward it through).

Discussion on 2:

We have to streamline our common position further at the next meeting of the Task Force, however, the current feeling is that the GDB will be offered the proposal in favour of ORGDB usage under the conditions:

1. All VODB candidates, including EXTN users, register in ORGDB before applying to the VO.
2. All re-newable users whose Participation_End_Date is reached in ORGDB will be unable to run their Grid jobs because they will be suspended automatically from VODB, unless they take the required actions to renew their ORGDB registration.
3. DN verification is still the responsibility of the VO manager. Admission of a user in the VO will not be automatic just because he/she belongs to ORGDB. Enabling the user's VODB registration remains at the discretion of the VO manager.

3. Any Other Business A.O.B.:

Next telephone meeting will be on June 28th at 16hrs CET, where we should have results from the *** ACTIONS *** mentioned above. Some discussion on possible action by the VO manager on "Inactive users" was not conclusive and should continue then. We should prepare our reporting to the Security Group meeting of July 1st.

Maria Dimou, IT/GD, Grid Infrastructure Services