1. VO management: Progress since Chicago Workshop Vincenzo Ciaschini vincenzo.ciaschini@cnaf.infn.it 23/5/2002 CNAF – Bologna

2. Summary ● Ready – Web-based VO registration ● Current Work – Multiple VOs – User info protection ● Proposal – CAS

3. grid-mapfile generation mkgridmap Grid-mapfile VO Directory CN=Mario Rossi o=xyz, dc=edg, dc=org CN=Franz ElmerCN=John Smith Authentication Certificate ou=People ou=tb1 ou=Admin local users Ban list Web based submission scripts

4. Web-based VO registration (1) ● Secure web form to submit subscription requests (https://grid-vo.cnaf.infn.it/subscribe.php) – Users identified by their X509 certificate (mandatory) ● Certificate informations used transparently for request (e.g. DN) ● Other informations from user input (e.g. phone number) ● Check of existence in LDAP tree (to be implemented) ● Confirmation by VO managers – Mail alert sent to managers – Secure web form to update LDAP tree (only insert procedure implemented up to now)

5. Web-based VO registration (2) ● Limitations – Only INFN CA certificates accepted, but trivially extendible ● Maybe some little modifications needed to take in account different certificates formats ● Future developments – Web interface for VO's management (June 2002) – Web interface for users to modify pending requests, to view status etc.. (???)

6. Multiple VOs ½ ● Users can specify with which VO they choose to submit jobs with: – grid-proxy-init -vo,for hand-generated proxies, or – export VO=, for programs who automatically call grid-proxy-init – grid-proxy-init -novo to ignore the VO variable.

7. Multiple VOs 2/2 ● Compatibility: – Patched version of libglobus_ssl_utils must be installed on every farm that wants to accept the new proxies, and on the RB and possibly II. – Old proxies are accepted by the new system, the reverse doesn't hold.

8. User info protection ● CE no longer publish the whole grid-mapfile, but only the accepted VOs. ● CEs must authenticate with VO LDAP servers using TLS. ● As a consequence, the RB can no longer be sure that the CE it selects for a job effectively authorizes the user to which the job belongs.

9. CAS 1/4 ● Considerations: – Users may need to access more than one CAS server at the same time. – ACLs should stay with the resource, not with the roles. – CAS should contain only (user, group, role, acl) information. – CAS certificates should identify the user holding them ● Needed by local sites (ban specific users) ● Mapping to unix UID/GID – Proof of user consent is needed.

10. CAS 2/4 ● Proposal. – The user submits a request to CAS – CAS returns a quintuple (signed) ● User ID ● CAS ID ● (group, role, acl)* ● Timestamp – Repeat the above steps for each CAS

11. CAS 3/4 ● Proposal (continued): – The user generates the proxy putting the CAS info into extensions. – An appropriately written LCAS plugin extracts and verifies information from the extensions. ● Advantages – Compatibility with current system – Easily integrates info from two or more CAS servers

12. CAS 4/4 ● At the moment under investigation for both requirements and algorithms ● Better name ? (VOMS -- VO Membership System?) ● Inputs?