Highlights of ISGC 2014

ISGC 2014 is over. Lots of interesting discussions - on the infrastructure end, ASGC developing fanless machine room, interest in (and results on) CEPH and GLUSTER, dCache tutorial, and an hour of code with the DIRAC tutorial.

All countries and regions presented overviews of their work in e-/cyber-Infrastructure.

Interestingly, although this wasn't a HEP conference, practically everyone is doing >0 on LHC, so the LHC really is binding countries and researchers (well, at least physicist and infrastructureists) and e-Infrastructures together (and NRENs). When one day, someone sits down to tally up the benefit and impact of the LHC, this ought to be one of the top ones. The ability to work together and to (mostly) be able to move data to each other, and to trust each other's CAs.

Regarding the DIRAC tutorial, I was there and went through as much as I could ("I am not doing that to my private key")  Something to play with a bit more when I have time - an hour (of code) is not much time; there are always compromises between getting stuff done realistically and cheating in tutorials, but as long as there's something you can take away and play with later. As regards the key shenanigans, DIRAC say they will be working with EGI on SSO, so that's promising. Got the T-shirt, too. "Interware," though?

On the security side, OSG have been interfacing to DigiCert, following the planned termination of the ESNET CA. Once again grids have demands that are not seen in the commercial world, such as the need for bulk certificates (particularly cost effective ones - something a traditional Classic IGTF can do fairly well.) Other security questions (techie acronym alert, until end of paragraph) include how Argus and XACML compare for implementing security policies, and the EMI STS - CERN looking at linking with ADFS. And Malaysia are trialling an online CA based on a FIPS level three token with a Raspberry π.

EGI federated cloud got mentioned quite a few times - KISTI interested in offering IaaS, also Australia interested in joining. Philippines providing resources. EGI have a strategy for engagement. Interesting the extent to which they are driving the of CDMI.

I should mention Shaun gave a talk on "federated" access to data, comparing the protocols - which I missed - the talk, I mean - being in another session, but I understand it was well received and there was a lot of interest.

Software development - interesting experiences from the dCache team and building user communities with (for) DIRAC. How are people taught to develop code? The closing session was by Adam Lyon from Fermilab who talked about the lessons learned - the HEP vision of big data being different from the industry one. And yet HEP needs a culture shift to move away from the not-invented-here.

ISGC really had a great mix of Asian and European countries, as well as the US and Australia. This post was just a quick look through my notes; there'll be much more to pick up and ponder over the coming months. And I haven't even mentioned the actual science stuff ...

Storage thoughts from GRIDPP32

Last week saw me successfully talk about the planned CEPH installation at the RAL Tier1. Here is a list of other thoughts which came up form GRIDPP32:

ATLAS and CMS plans for Run2 of the LHC seems to have an increase in churn rate of data at their Tier2s which will lead to a higher deletion rate being needed. Also will need to look at making sure dark data is discovered and deleted in a more timely manner.

A method for discovering and deleting empty directories which are no longer needed needs to be created. As an example at the Tier1, there are currently 1071 ATLAS users , each of whom can create  up to 131072 sub-directories which can end up being dark directories under ATLAS's new RUCIO namespace convention.

To help with deletion, some of the bulk tools the site admins can use are impressive (but also possible hazardous.) One small typo when deleting may lead to huge unintentional data loss!!!

Data rates shown  by Imperial college  of over 30Gbps WAN traffic are impressive (and makes me want to make a comparison between all UK sites to see  what rates have been recorded via the WLCG monitoring pages.

Wahid Bhimji's  storage talk also got me thinking again that with the rise of the WLCG VO's  FAX/AAA systems and their relative increase in usage; perhaps it is time to re-investigate WAN tuning not only of WN's at sites but also of XROOT proxy servers used by the VOs. In addition, I am still worried about monitoring and controlling the number of xrootd connections per disk server in each of the type's of SE  which we have deployed on the WLCG.

I was also interested to see his work using DAV and its possible usefulness for smaller VOs.
 

dCache workshop at (with) ISGC 2014

Shaun and I took part in the dCache workshop. Starting with a VM with a dCache RPM, the challenge was to set it up with two pools, NFS4, and WebDAV. A second VM got to access the data, mainly via NFS or HTTP(S) - security ranged from IP address to X.509 certificates. The overall impression was that it was pretty easy to get set up and configure the interfaces and get it to do something useful: dCache is not "an SRM" or "an NFS server" but rather storage middleware which provides a wide range of interfaces to storage. One of the things the dCache team is looking into is the cloud interface, via CDMI. This particular interface is not ready (as of March 2014) for production, but it's something we may want to look into and test with the EGI FC's version, Stoxy.

Some thoughts on "normal" HTTP clients and Grid authorisation

In thinking-out-loud mode. Grid clients use certificates: generally this enhances security as you get mutual authentication. So to present authorisation attributes, these either have to be carried with the credential, or queried otherwise via a callout (or cached locally). Access control is generally performed at the resource.

For authorisation attributes we tend to use VOMS,using attribute certificates. These are embedded inside the Globus proxy certificate, which is a temporary client certificate created (signed by) the user certificate, and "decorated" with the authorisation stuff - this makes sense: it separates authentication from authorisation. Globus proxies, however, tend not to work with "standard" HTTP clients, like browsers (which is not HTTP's fault, but a feature of the secure sockets.)

VOMS is nice because you get group membership and can choose to optionally assert rôles. The user selection is often missing in many authorisation schemes which either present all your attributes or none (or give you no choice at all.)

So how would we get grid authorisation working with "standard" HTTP clients?  One way is to do what SARoNGS does: get a temporary certificate and decorate that instead. The client doesn't manage the certificate directly, but grants access to it, like GlobusOnline does, either by giving GO access to your MyProxy server, either by giving it your MyProxy username/password (!), or using OAuth.

If, instead, you want to have your own certificate in the browser (or other user agent), then authorisation could be done in one of two ways: you can have the resource call out to an external authorisation server, saying "I am resource W and I've got user X trying to do action Y on item Z" and the authorisation server must then look up the actual authorisation attributes of user X and take a decision.  XACML could work here, with (in XACMLese) the resource being the PEP, the authorisation server the PDP, and the authorisation database (here, a VOMS database) being the PIP. VOMS also supports a SAML format, allegedly, but if it does, it's rarely seen in the wild.

Or, you could use OAuth directly. If do an HTTP GET on a protected URL, presenting a client certificate, the user agent would be directed to the authorisation server to which it would authenticate using the user certificate. The authorisation server would then need hooks to (a) find the relevant authorisation attributes in VOMS, and (b) take the decision based on the requested URL. The catch is that the OAuth client (the user agent) would need to present a client id to the authorisation server - a shared secret. Also the resource would need a means of validating the Access Token which is generally opaque. Hm. It's easy to see that something much like OAuth could work but it would obviously be better to use an existing protocol.

There are other things one could try, taking a more pure SAML approach, using some of the SAML and web services federation stuff.

Somebody may of course already have done this, but it would be interesting to do some experiments and maybe summarise the state of the art.