Federated Access to Storage EGI CF 2012 Luke Howard, Daniel Kouril, Michal Prochazka

Project Moonshot

Moonshot technologies Moonshot builds on the eduroam technologies EAP (RFC 3748): strong mutual authentication RADIUS (RFC 2865): federation between domains To this, Moonshot adds SAML, for rich authorisation semantics Integration using operating system security APIs SSPI: Windows GSS-API (RFC 2078): Other operating systems SASL (RFC 4422): Windows and other operating systems 3

Deployment requirements Many organisations are nearly Moonshot-ready today A connection to eduroam A RADIUS server (any modern RADIUS product should support pre- production testing today). There is also an experimental capability to integrate FreeRADIUS with the Shibboleth IdP Moonshot client and server plug-in Linux: packaging available for Debian & RHEL; Scientific Linux soon Windows: native support using prototype plugin Mac: Packaging complete for Snow Leopard and Lion Moonshot Identity Selector to facilitate the selection of an identity to use, for GUI environments (Windows, Mac & Linux) 4

Architecture 5 SSH clientSSH serverRADIUS server (2) SSH negotiation(4) RADIUS (3) Authentication (1) Credentialing (5) Attributes (6) SSH session OpenSSH used as example of application; many others also apply

Application support Most modern applications use at least one of the security APIs supported by Moonshot Correctly written applications will ‘just work’ without modification or recompilation Less correctly written applications may require minor modifications Project Moonshot is testing applications and sending patches upstream 6

PuTTY  OpenSSH 7

8 IE  Apache

9 Outlook 2010  Exchange 2010

Examples of other tested scenarios OpenSSH client  OpenSSH server (GSS) OpenLDAP client  OpenLDAP server (SASL) OpenLDAP client (GSS)  Windows Active Directory (SSPI) Firefox  Apache (GSS) Internet Explorer  IIS (SSPI) MyProxy client  MyProxy server (SASL) Adium  Jabberd (SASL) Console authentication using PAM/GSS on Linux and SSPI on Windows 10

Standardisation The architecture is currently being standardised within the IETF’s ‘Abfab’ working group. See for documentshttps://datatracker.ietf.org/wg/abfab The key documents are draft-ietf-abfab-arch describing the high-level architecturedraft-ietf-abfab-arch draft-ietf-abfab-gss-eap describing the core “GSS EAP” technologydraft-ietf-abfab-gss-eap draft-ietf-abfab-aaa-saml describing the use of SAMLdraft-ietf-abfab-aaa-saml

Get involved! The project is Janet-led initiative, with contributions from GÉANT and others Case studies can be found at describes installing, configuring and using Moonshot. An installable Live DVD (Debian-based) is available, in addition to Debian, CENTOS and Scientific Linux packages is our community mailing list We also have a Jabber room at

Technology pilot 1.To test the suitability of the Moonshot technology for deployment, focusing on e-Research use cases 1.To identity what further work is needed to support the wider community’s use of the technology 2.To plan, implement or support this additional work 13

Current status Pilot sites connected to Janet’s eduroam infrastructure Software ready for pre-production testing only Production-quality environment due imminently IETF standardisation approaching completion - the core documents approaching Last Call status so likely to be complete by H On-going discussions with OS and application vendors 14

Future plans Project Moonshot 15

The next six months The primary activities will be Continuation of existing Technology Pilot Improvement and refinement of core software Out-reach to other stakeholders Development the final element needed for a production-ready service Completion of standardisation 16

Conclusions Moonshot provides a standardised next-generation identity & trust technology Moonshot builds on widely deployed technologies and infrastructure Moonshot provides a cross-platform implementation ready for pre- production testing Moonshot will provide the trust & identity platform for Janet’s services 17

Federated Access to NFS

NFSv4 Distributed file system – Successor of version 1-3, IETF standards – Several implementations available Security implemented using GSS-API – User-space daemons and kernel Authentication of – Mounts (machine) – Access to data (user)

Moonshot in NFSv4 Adaptations to NFSv4 daemons – Both client and server had to be changed – Worked around the Kerberos dependency Kernel code still requires „Kerberos“ – Moonshot adaptations pretends Kerberos – User space tools specify Kerberos Stability of code not sufficient – Caching of GSS contexts causes troubles

Pilot NFSv4 Deployment EGI Radius server – Accepts any IGTF certificate, including RFC proxies – Returns (canonized) DN as the username NFSv4 server – Via the EGI Radius it accepts any user with IGTF credential – No automated username mapping at the moment NFSv4 clients – Source code available from github – Moonshot-proxy-init to create proxy certs

Possible Scenarios Gridified remote file system – Users with IGTF credentials can share data – Single identity domain Federated remote file system – Users with eduroam credentials can share data – Possibly multiple identity domains Scenarios could be combined – Ideally utilizing additional attributes for authZ

Q & A Project Moonshot 23