Скачать презентацию Federated Access to Storage Luke Howard Daniel Kouril Скачать презентацию Federated Access to Storage Luke Howard Daniel Kouril

662c4693f3ec67d05af806868ef529c1.ppt

  • Количество слайдов: 23

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

Project Moonshot Project Moonshot

3 Moonshot technologies Moonshot builds on the eduroam technologies • EAP (RFC 3748): strong 3 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

4 Deployment requirements Many organisations are nearly Moonshot-ready today • A connection to eduroam 4 Deployment requirements Many organisations are nearly Moonshot-ready today • A connection to eduroam • A RADIUS server (any modern RADIUS product should support preproduction testing today). There is also an experimental capability to integrate Free. RADIUS with the Shibboleth Id. P • 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)

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

6 Application support Most modern applications use at least one of the security APIs 6 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

Pu. TTY Open. SSH 7 Pu. TTY Open. SSH 7

IE Apache 8 IE Apache 8

Outlook 2010 Exchange 2010 9 Outlook 2010 Exchange 2010 9

10 Examples of other tested scenarios • Open. SSH client Open. SSH server (GSS) 10 Examples of other tested scenarios • Open. SSH client Open. SSH server (GSS) • Open. LDAP client Open. LDAP server (SASL) • Open. LDAP client (GSS) Windows Active Directory (SSPI) • Firefox Apache (GSS) • Internet Explorer IIS (SSPI) • My. Proxy client My. Proxy server (SASL) • Adium Jabberd (SASL) • Console authentication using PAM/GSS on Linux and SSPI on Windows

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

Get involved! The project is Janet-led initiative, with contributions from GÉANT and others • Get involved! The project is Janet-led initiative, with contributions from GÉANT and others • Case studies can be found at http: //www. project-moonshot. org/casestudies • http: //www. project-moonshot. org/using describes installing, configuring and using Moonshot. An installable Live DVD (Debian-based) is available, in addition to Debian, CENTOS and Scientific Linux packages • https: //www. jiscmail. ac. uk/MOONSHOT-COMMUNITY is our community mailing list • We also have a Jabber room at moonshot@groupchat. nordu. net

13 Technology pilot 1. To test the suitability of the Moonshot technology for deployment, 13 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

14 Current status • Pilot sites connected to Janet’s eduroam infrastructure • Software ready 14 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 2 2012. • On-going discussions with OS and application vendors

Project Moonshot Future plans 15 Project Moonshot Future plans 15

16 The next six months The primary activities will be • Continuation of existing 16 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

17 Conclusions Moonshot provides a standardised next-generation identity & trust technology Moonshot builds on 17 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 preproduction testing Moonshot will provide the trust & identity platform for Janet’s services

Federated Access to NFS Federated Access to NFS

NFSv 4 • Distributed file system – Successor of version 1 -3, IETF standards NFSv 4 • 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 NFSv 4 • Adaptations to NFSv 4 daemons – Both client and Moonshot in NFSv 4 • Adaptations to NFSv 4 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 NFSv 4 Deployment • EGI Radius server – Accepts any IGTF certificate, including Pilot NFSv 4 Deployment • EGI Radius server – Accepts any IGTF certificate, including RFC proxies – Returns (canonized) DN as the username • NFSv 4 server – Via the EGI Radius it accepts any user with IGTF credential – No automated username mapping at the moment • NFSv 4 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 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 auth. Z

Project Moonshot Q&A 23 Project Moonshot Q&A 23