I was recently invited to speak at the JANET Networkshop conference about HPC Midlands' involvement in the JANET(UK) Pilot of Project Moonshot. In this post I'll explain a little bit more about how Moonshot works, how we are using it, and why it is relevant to our industrial collaborations.



If you've not come across it before, Moonshot aims to apply many of the principles of the eduroam networking initiative to arbitrary Internet services. Most of my readers will probably already be aware of eduroam, which is all about giving folk from academia Internet access when visiting each others' institutions. Moonshot extends this to cover using your organization's normal IT credentials to log in to other third party services like websites, email systems and file servers - wherever they are and whoever runs them. You still need permission, though :-)

You can view a copy of the slides from my talk below, or click through to my SlideShare site for these and other presentations that I have given.

Why Federate?

IT departments are often accused of failing to plan for collaborative working beyond organizational boundaries, and putting in systems that only truly work for other members of the same organization. A classic case in point here would be the difficulty of arranging meetings and viewing diaries of project partners from other organizations, and the market opportunity that this has created for third party services like Doodle.

To consider why we might want to do this, consider the slide below from the Rolls Royce presentation at the recent HPC Midlands launch event on their University Technology Centre programme. As I said in my Networkshop talk, you can be sure that there are numerous Rolls Royce employees who have IT accounts from multiple institutions because of their work with the broader research community. In this context Moonshot potentially lets us significantly reduce the friction associated with the IT side of academic/industrial strategic partnerships.

(Image credit: Leigh Lapworth and Gary Page)

What this diagram also highlights is the breadth and depth of the partnership that is already in place between this one (albeit world leading) firm, and Universities both in the UK and elsewhere. There is clearly a case to be made here for some sort of JANET connectivity for key industrial strategic partners like Rolls Royce, and I hope that we will see a trial along these lines come out of the e-Infrastructure work that JANET(UK) are currently undertaking.

I have highlighted this issue here in the past in the context of our HPC Midlands customer E.ON, 15 minutes drive away from us by car, or several countries away via the Internet. The distinction between the two is contrasted in the diagram below. I will note here as I did in the Networkshop talk that the geographical traceroute shown on the right of the diagram has placed some of the key Internet points of presence in unlikely places, including the middle of the Irish Sea, but it remains the case that corporate Internet connectivity for our E.ON HPC Midlands users (10 miles away, remember) is via their German offices.

Whilst for one academic/industrial partnership we could jump into a car and transfer files using an external hard drive (if they fit!), it quickly becomes obvious that this approach is unlikely to scale well to more than a handful of users. Nevertheless, we need to take a reality check and remind ourselves that this is how people are currently working together on real projects, wasting a huge amount of time and holding up the underlying science and engineering work.

The Technical Bit

So how do you log into a service run by some other organization using your normal IT credentials? In the Moonshot scenario, your "client" program (such as an ssh client) uses something called the Generic Security Services Application Programming Interface (GSS-API) and the Extensible Authentication Protocol (EAP) to send your IT credentials back to your home organization, which validates you and optionally sends back some further information about you or (say) your service entitlement. This is summed up quite neatly, if a little cryptically, in the diagram below:

(Image credit: Josh Howlett)

A key point to note about Moonshot is that your credentials are passed down an encrypted connection between your computer and your organization's authentication server, so any third party services that you are using will never see your password.

You may at this point be recalling painful experiences getting up and running with WPA Enterprise wireless networking, or IEEE 802.1X authentication on wired networks. Moonshot should be significantly simpler because it mandates a single "EAP method" (known as EAP-TTLS) for transmitting the encrypted credentials. This compares very favourably with the plethora of permutations of authentication mechanism in common use for wireless networking.

It's also helpful that the Moonshot team has produced pre-packaged Moonshot-enabled versions of key software packages, so you can get up and running pretty quickly. We used the CentOS 6 Linux RPMs from yum.dev.ja.net, which provide patched versions of FreeRADIUS, OpenSSH, the Shibboleth native Service Provider, the GSS Server daemon and supporting libraries etc. These mostly installed into /opt/moonshot, leaving normal system software and configurations alone - with the notable exception of the Moonshot enabled version of FreeRADIUS, which expected to find its configuration in /etc/raddb by default. This could trivially be overridden with the "-d" command line flag, through.

Vendor respins of popular Linux distributions are common to find in the HPC space, as these allow the vendor to integrate and fully test/support non-standard Linux add-ons such as the Lustre filesystem and Infiniband driver support. Our own HPC supplier, Bull Information Systems, does just this, and as a consequence we found that a couple of the Moonshot RPMs were confused about their dependencies. If this is a problem for you, you may wish to simply grab the Moonshot Live DVD image from the project website, which you can spin up on a convenient virtual machine, or fetch the source from the Moonshot Git repository.

And how does it work in practice? Here is the Moonshot enabled version of the ssh client program up and running in test mode, which we achieved shortly before the Networkshop conference:

hera12# /opt/moonshot/bin/ssh -p 2222 -l "" 127.0.0.1
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
[comth@hera12 ~]$

This may be a somewhat underwhelming demonstration, but it proves that Moonshot enabled ssh, sshd, gss-server, radiusd and shibd are all talking to each other. Next we have to integrate Moonshot with our existing infrastructure so that we can start authenticating users from our various University and industrial sites. Key in this is the Trust Router work by the IETF's Application Bridging for Federated Access Beyond web (ABFAB) working group.

The Wrap-Up

It's great that the academic sector has come together around open standards like the Security Assertion Markup Language (SAML), which is now used in a large number of authentication and authorization software packages - notably the Shibboleth software. What we haven't managed to do is translate the good work on federating authentication (e.g. the UK Access Management Federation) beyond the sector itself and its close partners such as publishers. e-Infrastructure services with a significant industrial component like HPC Midlands are a helpful reminder of this.

Will (or how will) we persuade our industrial collaborators that Moonshot is worth investing in? I think the answer is that we won't, at least in the first instance - instead we will offer them a "Moonshot Adapter" service. This will have a control panel that they can use to manage their users' access to Moonshot enabled systems and services, and Moonshot's integration with their infrastructure will be limited to a firewall hole for the LDAP or Kerberos protocols. We have quite a few hurdles to clear before this is on the cards, though, so do check back for further updates!