From Akos.Frohner@cern.ch Mon Nov 10 16:37:13 2003 Date: Mon, 10 Nov 2003 16:09:14 +0100 From: FROHNER Akos To: Joel Closier , Ian Neilson , Maria Dimou , daniele.mura@ca.infn.it, Alessandro.DeSalvo@roma1.infn.it, Andrea Sciaba , CHANG Chih-Chiang Cc: Karoly Lorentey Subject: Re: VO Registration Procedures -- again Dear All, Here are my notes from the meeting on Friday: Participants: Joel, Ian, Maria, Andrea, Chih and Ákos. 1. Have a look at the VOMS web interface. Couple of you had problems testing the interfaces, because you started using new certs, while only the old one was registered. These were fixed by Chih, but it brought up the topic of a "superuser", who can override the ACL settings and restore the system from wierd situations. There is no such "superuser" exists in VOMS remotely, but from the local machine (i.e. on the host, where VOMS runs) one can use the service bypassing the ACL checks. Joel was satisfied with this solution, so we won't have to modify the current authorization model. (even this bypass mode can be turned off in a configuration file --- it is on, by default, for such cases like this) One remark: every admin is a member of the VO (i.e. no external people will have administrative rights in a VO) 2. Basic request handling http://cern.ch/szamcsi/edg/vo-management-2003-11.ppt http://cern.ch/szamcsi/edg/vo-management-2003-11.pdf Ákos explained the basic request handling flow of VOMS (partially implemented), which is like in a mailing list manager system. You can have a look at it in the second slide of the presentation. It is about adding a new user (or registering in a VO, from the user's point of view) and there will be similar flows for - removing a user from the VO - adding/removing user to/from group/role/capability - creating/deleting a group/role/capability Ákos mentioned some alternative flows, where no administrative approval is needed (i.e. "automatic" VO without admin). Such a workflow could be also useful for implementing the "user wants to leave the VO, which doesn't need approval" case as well. 3. Notification: separate vs. implicit list The plans for the administrator notifications in VOMS and the current practice doesn't match: currently every VO has its email list, where the admins are added/removed. Every request goes to this list, not to the administrators directly. VOMS plans to send notifications to the persons, who can actually make some change, i.e. the persons, who are in the ACL list of the VO. The advantage of this approach is that the implicit mailing list is always in sync with the ACLs. If we would want to send notifications to the external (current) generic VO-admin mailing list, then we would have to solve the synchronization of the ACLs and the lismembers: for example when a new admin is added to the mailing list, then he should also be added to the ACL of VOMS, so he can actually do something, when a new request arrives. Joel and Ákos supports the idea of this "implicit list" and others didn't disagree either. 4. Registration offices Ákos shortly explained the hyerarchical structure of registration offices from the plans of USCMS/VOX (see later). The idea of having this distributed registration process was supported by all VO admins, but it was not clear if it is necessary right now to have tool support as well. Andrea told us that he has about one request per week, which he can easily handle "by hand", via personal emails and phone calls. [Ákos: I would say we shall have a look at the VOX documents, but VOMS will not have support for this soon.] However, LCG requires a supervisor name as well at registration, so it might be a good idea to send a notification to this supervisor as well and also wait for his approval, before the request is forwarded to the VO admin for approval. 5. Expiration of users Will VOs delete users or force expiration in some form? Ian told that expiration is a good idea (he is also the CERN CA admin :-), so the users should re-register in every one or two year. This re-registration should go through the same workflow as the original registration, but with the existing user data as a starting point. (i.e. need for confirmation of email and approval from VO admin) It was also suggested that we should couple the lifetime of the user to the lifetime of her/his certificate. [Ákos: The only problematic part with this is that VOMS doesn't store the user certificate.] Andrea suggested a per-group lifetime, to be able to implement short lifetime groups: a user could be assigned to a high priority group, but her/his memership would automatically expire in two weeks. 6. VOX More information on the VOX project and about their requirements and procedures can be found at the following places: http://www.uscms.org/s%26c/VO/ http://www.uscms.org/s&c/VO/design/designdoc.html They have a demo/prototype ready, which shows the basic web forms. As far as I know this package is not yet publicly available in packaged or installed form. Cheers, Ákos