Spring latch.
When my family and I recently moved into our new apartment, it was equipped with a front door with two locks: both of them with a spring latch. To get in, we needed to put a key in each and turn both while somehow turning the door handle at the same time. It could take quite a while and was difficult to do alone, not to mention alone with a kid on one arm and a bag of groceries in the other hand. The setup that was incredibly user unfriendly for no obvious reason – certainly not to increase security: Thieves in our neighborhood are generally not very subtle – they just give the door a good kick and don’t care whether they are kicking up two spring latches or a spring latch and a dead bolt. Door and frame are usually old and just break.
Eventually, of course, we replaced one of the spring latch locks with a dead bolt lock coded to the same key and now we can enter our home with the use of two hands only and have one key less in our keychains.
Dead bolt.
Where am I getting with this: Well, my front door was clearly a case of bad user interface design. If I would try and get others to use such a setup, they would laugh at me, but yet, the previous owners lived with it for years. They just got used to the daily hassle and perhaps never even saw it as a such.
I’ve been asking myself for years why the, admittedly few, users of grid computing in the academic sector put up with a user interface design that involves spending hours obtaining credentials that are accepted by grid computing resources and then decrypting these credentials every time they want to use grid tools. I mean, all these credentials do is prove that these people are who they claim to be. They’ve typically already proved this exact thing to a service on the local intranet – and establishing a lasting trust relationship between this service and remote grid resources should not be such a hard thing to automatize. One should think… Single sign-on – wasn’t that one of the things “the grid” was all about some 10 years back? Then why are people still required to login twice: first on their intranet and then on the “grid”? Two keys – one in each hand. Yes, a far fetched analogy I admit, but the point is valid enough: a small improvement in usability can make daily life a lot better. And in the case of grid computing, I claim that more of these small improvements, taking away more small nuisances, could potentially transform this corner of academic computing from unused irrelevance into being a standard tool for the daily work of the majority of researchers.
This brings me to the Terena Certificate Service (TCS), which builds on the relative success of national federated web-based single-sign-on systems in academia like Kalmar2, allowing, in a metaphorical sense, to reduce the number of keys you need to one: you login on your local intranet and that’s it: behind the scenes, there’s an established trust relationship between participating peers of “the grid” and you can just run computing jobs on these peers without further ado. You can read more about TCS on the TCS eScience Portal. If you’re a European university student or employee, chances are that if you click on the login button of that site and then choose your country, you’ll find your university in the appearing list and clicking on it will simply take you to your university intranet login page. After logging in there, you can generate grid credentials with a few mouse clicks in your browser.
So, the TCS provides a functioning bridge between federated web-based, single-sign-on systems and the public-key infrastructure put in place by the grid community over the last decade. All very fine, except, for the grid crowd (however small it may be) it’s not much fun, because your nice new RSA key and X.509 certificate, obtained by logging in to your intranet and clicking a few times in your browser, sit and stay exactly there – in your browser. If you want to use them with your grid tools, you first have to export them manually from your browser to a PKCS12 file and then convert this file into two PEM files with some obscure openssl commands. If you’re on Windows – tough luck, you probably don’t have openssl.
Wouldn’t it be nice to have another button next to the login button, saying, “export credentials to disk”? I’ve discussed this with quite a few sysadmins and service providers and developers in both the federation and X.509 communities and none seem to think such functionality is of much importance. The common answers go something like: 1) “well, these grid guys anyway love their command line, so what’s the problem with typing in a few openssl commands?” or 2) “I’m not going go give a web app full access to my hard disk – are you out of your mind?”
Let me answer both objections:
1) A very common trap, that I also fall in regularly is to overestimate the importance of your own work. Sure, the system is intelligently made and all, but hey, we’re talking about logging in. Don’t expect a user to want to spend more than a few seconds on that.
2) All desktop apps you’ve downloaded and are running have full access to your hard drive – nothing exceptional here. If you’re really paranoid, this particular app should of course come with source code you can scrutinize and compile yourself.
Bottom line: there’s really no excuse for not making life as easy as possible for your users, but the objections are interesting in that they go a long way of explaining why “the grid” never took off.
