Auth/AuthZ features needed for WLCG

Some papers by Maria Dimou (VOMS manager 2003-2009) on features WLCG absolutely needed. This text assumes that the notion of Virtual Organisation (VO) and the nature of VOMS Group_Role and VOMS Group are known.

1. CHEP 2009 paper on the VOMRS-to-VOMS-Admin migration. See points 4.1 and 5.1.2 about VO Registration approval, reniewal, Institute representation, approval into a Group/Role.

2. VOMRS-to-VOMS-Admin migration effort index. The minutes of these events show when, how, why things were done. This might be important to avoid:

• loss of functionality
• behaviour change

3. See here the list of non-LHC VOs that GGUS (the Grid ticketing system) supports (about 44 VOs). They are all based on VOMS today, so a migration to anything else (probably via EGI coordination) should ensure no loss of functionality.
4. Consult the LHC Experiments’ VO managers regularly. They should be the ones to support the effort and their own users. See here some documents of such regular consultations:

• VOMS Challenges
• Check the VOMS Workshops in this index. There was always a meeting developers-deployers-VO_Managers, every few months. This is important.

5. Before VOMS-Admin and before VOMRS, authentication was LDAP-based. See here notes from the era of LCG Registrar.

6. What about the Middleware? Everything related, at least, to Data Management and Monitoring will have to become aware of the new Auth/AuthZ tools and workflows. See slide 21 in this presentation to make a realistic plan.

7. List of sine qua non features. They contain savannah tickets links which still work. They were all migrated in JIRA, so you can find them there as well.
   See examples here taken from Maria’s 2009 notes of the Working Group. Consult the ticket for full description:

   A. Security-related items:

   1.Multiple certificate support
   2.Authorisation-aware web UI
   3.VO membership expiration bound to AUP version
   4.Allow user to request his/her inclusion in a VO Group/Role
   5.Keep user Registration Data in the VOMS database
   6.Show VOMS Group_Role description on the UI
   7.Show Group description on the UI
   8.Implement member institutional expiration - this was considered very important and taken from the LHC DB alias CERN HR DB
   9.Extend member status - mostly by the VO manager. Could cover cases of users with expired certs

   B. Items on functionality required by VO managers:

   1. Enable the VO manager to execute more-than-1 transactions at the time
   2. Sortable and selectable info on the web UI
   3. Configurable online help
   4. Event subscription for optional email notifications
   5. Dynamic list of collected personal informationn
   6. Ability to attach VOMS Group_Role to VOMS Group
   7. VOMS Group_Role membership access (Open/Restricted)
   8. VOMS Group membership access (Open/Restricted)
   9. Do not allow candidate user to re-apply to the VO if rejected/denied
   10. offer the user possibility to select Representative .

   C. Interface to an external Information source, e.g. Organisational DB:

   1. During registration
   2. During validation

Please feel free to browse through my notes for any other info you may need.