An Authentication Gateway for Integrated Grid and Cloud Access

1. An Authentication Gateway for Integrated Grid and Cloud Access Davide Salomoni, Vincenzo Ciaschini INFN-CNAF CHEP 2010, Taipei 18-22 October, 2010

2. Content Introduction to the project Architectural details Use case: grid access for cloud users Use case: cloud access for grid users Conclusion

3. Introduction • The INFN Tier-1 at CNAF (Bologna, Italy) integrates access to its resources through Grid and Cloud Interfaces • Via the INFN Worker Nodes on Demand Service (WNoDeS) – see next slide. • However, user access is markedly different, and must be harmonized. • The Authentication Gateway described here is part of the WNoDeS access layer and its goal is to provide a uniform layer for access to resources.

4. WNoDeS • WNoDeS quick facts: • Running in production at the INFN Tier-1 for the past 12 months. • Being installed at the INFN LNL National Laboratory. • Currently running 2,000 on-demand VMs at the INFN Tier-1. • Fully integrated into the 7,000 cores Tier-1 farm. • Integrated local, grid, cloud access plus instantiation of Virtual Interactive Pools, all out of a common resource set. • Supporting several key features like VLAN partitioning, integration with shared storage, multi-core VMs, network throttling. • Web-site: http:web.infn.it/wnodes • E-mail: wnodes@lists.infn.it

5. Authentication Mechanisms • Different user communities have wildly different mechanisms in place for user authentication • Some use certificates! • Some use Kerberos! • Some use Shibboleth! • Some use username/password! • Some do not have authentication at all! (e.g. anonymous access to resources)

6. Authentication Mechanisms • One would want to merge this plethora of choices and provide a (quasi-)transparent user experience. • Possibly regardless also of the distributed computing technology being used (e.g. Grid vs. Cloud Computing) • Grids (and some Clouds) require certificates. • How about internally translating everything into X.509 certificates?

7. An Authentication Gateway • If X.509 certificates are already used, pass-through. • At least for IGTF CAs • If Kerberos or Shibboleth are used, kCA and SLCS solve the issue. • If username/password is used, then an IdP needs to be setup, and then we fall into the previous case.

8. Architectural Layout

9. Some Implementation Details • Design choice: • Re-use existing components, write a slim common layer to hide access to the specific online CA being used. • Project status: • kCA and Shibboleth IdP up and running with an internal online CA • Only valid within INFN at this time • The kCA should contact the online CA used by glSLCS  a patch to kCA is needed, timeframe Dec 2010 • IGTF certification of the online CA  working on this, timeframe Summer/Fall 2011 • Shibboleth test IdP to be eventually replaced by the IdP of the Italian Federation of Universities and Research Institutes (IDEM)

10. Use Case #1: Cloud Users Accessing Grid Resources (1) • A federateduserwantstoaccessGridresources • Usually, he would only have a kind of federated access, e.g. Kerberos or Shibboleth • He needs to obtain a certificate • He needs to register into a VO • This VO may not exist yet, in which case it must be set up • Sites need to allow the new user (and possibly, the new VO)

11. Use Case #1: Cloud Users Accessing Grid Resources (2) • The Authentication Gateway provides the user an X.509 short-lived certificate – but he still needs to be a member of a VO. • The gateway then registers the user into a dedicated VO. • DN persistency is guaranteed across credential re-creation. • Sites then need to accept the additional VO. • It is also possible to only accept subgroups of the VO. • One could have a catch-all VO, or set-up multiple VOs if the need arises (operational / business considerations apply) • Users have gained access to Grid resources (i.e. VOMS proxies) with minimal changes to the sites. • Apply this to job submission portals, and/or to Cloud web portals.

12. Use Case #2: Grid Users Accessing Cloud Resources (1) • Really an application of the X.509 pass-through case • The same services used in Grid computing for authentication and authorization are also used by the WNoDeS Cloud layer. • VOMS for Virtual Organization membership, gLite ARGUS for authorization policies • This allows us to automatically support existing Grid certificates and Virtual Organizations • Existing grid users are able to access Cloud resources, using just their Grid credentials.

13. Use Case #2: Grid Users Accessing Cloud Resources (2) • User contacts the WNoDeS Cloud Web Interface (W-CWI), being authorized through a browser-installed X.509 certificate. • A request is made by the user to create Cloud resources assigned (billed) to VO XYZ. • W-CWI contacts the VOMS server for VO XYZ and validates user’s credentials • If successful, W-CWI contacts ARGUS to validate access policies • Might be e.g. per-VO, per-role, whitelist-based. • If autentication and authorization are both OK, resource is granted.

14. Conclusions • Through the Authentication Gateway weaimto integrate: • multiple authenticationmethods; • accessto diverse resourceinterfaces (e.g., Grids and Clouds) • Prototype ready, production deploymentexpected in 2011 • CloudusersaccessingGridresources.Benefits: • Easy accessofgridresourcesbycloud/federatedusers. • Exploitationofpreviousinvestments in distributedGridinfrastructures. • GridusersaccessingCloudresources.Benefits: • Easy accessofcloudresourcesbyexistingGridusers. • GridVOs can create ad-hocrulesforusersallowedtoinstantiate and consumeCloudresources.

15. More on WNoDeS • At CHEP 2010: • A.Italiano, WNoDeS, a tool for integrated Grid/Cloud access and computing farm virtualization (PS29:Computing Fabrics and Networking Technologies, 19/10/2010) • C.Grandi, Virtual pools for interactive analysis and software development through an integrated Cloud environment (PS13:Distributed Processing and Analysis, 19/10/2010) • Online: • Web: http://web.infn.it/wnodes • E-mail: wnodes@lists.infn.it