Notes from the 2003-10-29 meeting on VOMS
and follow-up actions

Participants: Ian Bird, Chih-Chiang Chang, Maria Dimou, Akos Frohner, Maarten Litmaath, Ian Neilson, Di Qinq, Zdenek Sekera, Marco Serra, Markus Schulz.
DRAFT for comments!! Edited by Maria Dimou with input from Akos Frohner, clarifications from Ian Neilson and comments from the participants.

Summary of VOMS deployment status as of 2003-11-12:

The LDAP-based registration of users who adhere to the LCG usage rules (Guidelines) and their admission in a Virtual Organisation (VO) cannot be replaced today with a VOMS-only procedure because:

• The VOMS (web) interface for users to submit requests to the VO administrators is not yet available.
• The information that a user has to fill-in when requesting to join a VO is not yet decided. DN,CN,CA, CA URI and Email are the only fields foreseen so far, together with the user's Groups and Roles. Additional information we register today , such as the Institute and the PhoneNumber may be needed but not, currently, foreseen. (Information on the 2003-11-07 meeting with the VO managers and notes from the VOX web interface demo).
• The procedure ensuring a user's compliance to the Guidelines before acceptance in the VO is not yet clear. The LCG security group discussed the issue on 2003-11-03 but postponed the decision to the VOMS Workshop starting on 2003-12-15.
• We are already in the phase 0 migration scenario, i.e. importing data from LDAP into VOMS (which now runs on tbed0152.cern.ch). Periodic synchronisation LDAP-VOMS (cron job) is active (every 6 hours).
• Even if we want to proceed to the phase 1 migration scenario, i.e.generating the gridmap file from VOMS, time doesn't permit today to give priority to this on the Certification Testbed. The discussion on a possible date can only start after LCG-2 (20,Nov.2003).
• VOMS' enhanced functionality in terms of fine-grain categorisation of users in Groups and Roles cannot be exploited due to the lack of an encapsulating Service that manages ACL permissions and masks the limitations of the Unix file system. As this was not foreseen by the project, we will end-up using VOMS due to its better administration interface but we will gain nothing in terms of managing permissions in the filesystem, as long as we use the gridmap file.
• A true use case with data from the LCG environment (i.e. with detailed knowledge of the way experiments name their directories and arrange access permissions) is necessary in order to write down the potential contents of LCMAPS (exact mapping mechanism of VOMS Roles to Unix groups).
• LCG has to decide on development priorities between the EDG WP4 proposed gridftp patch and Job Repository (More).

2003-11-07 meeting with the VO managers

Chih-Chiang Chang (VOMS installation), Joel Closier (LHCb VO), Maria Dimou (DTEAM VO), Akos Frohner (VOMS developer), Ian Neilson (DTEAM VO) and Andrea Sciaba (CMS VO) discussed first impressions from the test installation and management interface.
Concerning the issue of populating VOMS Groups, it was decided that the VO manager decides on the Group names but each Group may be administered by different people.
By default only the VO manager can create a Group or sub-Group but (s)he can set ACLs appropriately to change permissions.
The meeting decided that there should be a default user expiration date.(Akos' notes).

2003-11-07 VOX demo

Chih-Chiang Chang, Maria Dimou, Akos Frohner and Ian Neilson were invited to a VOX demo by Greg Graham (FNAL).
Overall, one may say that VOX is a pre-VOMS interface for registration only. It is richer than VOMS in terms of amount of information one can enter about the user. Several VOX fields, e.g. citizenship, will never be part of VOMS. Others, e.g. Rights, Status donot exist today and, probably, won't, in the future, either. The function of a user's Supervisor is called in VOX Representative.
It is noticeable that the VO manager can easily add/remove fields from the user interface and the database schema and can even decide which ones to classify as mandatory.
VOX contains the notion of "Role" which is different to the one of VOMS, as it relates to the process of registration (e.g. "applicant" when asking to register or "LRP", (Local Resource Provider) when approving a user's acceptance to the VO).
VOX contains the list of sites supporting a given VO. Every site publishes in VOMS the list of fields they consider mandatory in order to accept a user registration. It is supposed that a successful registration can occur when the union of all required information is provided. It is not known whether this assumption is actually correct and, actually, implemented.

Before VOMS:

VOMS administration:

More on guidelines' acceptance by all VO members:

(1) If not everyone has signed acceptance to the guidelines, then one VO must be introduced for the guidelines and every user has to acquire two credentials with the command voms-proxy-init: One from the guidelines and one from his/her real VO's VOMS server. The existence of _both_ credentials would be checked at the resource (i.e. LCAS/LCMAPS, edg-java-security etc.) (Ian Bird, Akos' preference, most probably the one we'll adopt. It matches today's 'registrar' and [VOname] data in LDAP).

(2) If everyone has signed acceptance to the guidelines, then the VOMS server has to ensure this policy by checking the membership of every new user in the guidelines' VOMS server and doing synchronization later every hour (David Groep's preference).

Number of VOMS Roles limitation

Suppose a user was registered in VOMS with x valid Roles and he presents his/her credentials to the resource fulfilling y out of those x. The process has to run using a user account that must be present in /etc/group as a member of all the local Unix groups that correspond to his/her present y VOMS roles, and only those. This means that a user account under which a job runs may belong to any valid combination of groups in /etc/group, which makes their maintenance difficult to manage.

More on VOMS-Group/Unix-group:

The mapping of VOMS credentials (VO, Group, Role) to Unix groups:

The life of a job with VOMS:

VOMS notes with useful documentation references.