Build a Better Burger

Build a Better Burger was one of those games that was advertised relentlessly during my childhood, like Buckaroo and Mousetrap. I didn’t know anyone who owned it – i think that parents probably disapproved of the fast food theme. I think the idea was that you chose a fastfood menu and then had to quickly try and construct the burger as it appeared on the menu from component parts (meat, lettuce, tomato, gherkins) – whilst the menu turned round and round on a central spinning thingamy. Highly sophisticated stuff – but it was the 80s.

As we move towards the end of our work with the major academic publishers and focus on smaller publishers and other software platforms, I wonder what we can do to ‘build a better burger’ within our infrastructure. All of the big themes in software development over recent years have all been designed to build that burger through recognising the importance of component software, loosely coupled services, web services, cloud computing. The reality with all of the systems that we have worked with is a lot more depressing. The norm is still monolithic services that have been around for a considerable number of years and that have been built up and added to with each new release. This means that decoupling services is nigh on an impossibility.

On the face of it, federated access offers an attractive thing – stop doing the identity and access management within your platform and let someone else worry about it, just plug-in some software. For most systems, the real truth is that what something like identity and access management is built in to the system, it is extremely difficult to extract them.

The recent JISC FAR project highlights some of these problems from a repositories perspective. The final project report notes the following:

It is difficult to work out how hard it will be to add FAM support (beyond simply replacing the authentication system) to a complex application such as a repository product. Beyond access to the source code, which is clearly essential, some properties of a software project which make the process simpler include:

• The existing use of groups for authorisation by the application;
• A recognition by the software design of the existence of implicit authentication;
• Simple installation on a shared webserver using https for secured access;
• Pluggable or at least simple architectures for authentication;
• Comprehensive documentation covering authentication and authorisation for programmers and administrators;
• No requirement that groups/roles etc. need to be listed in configuration or require code modifications to make the repository recognise them (i.e. it is possible to create on the fly groups of users in the repository from attribute values);
• Use of authentication/authorisation management standards such as XACML.

From the list of repository products considered by the FAR Project, DSpace satisfies all but the last, Fedora satisfies all, and EPrints satisfies only the first.

Have we convinced ourselves that we live in a world of web services and cloud computing when the reality is very different? An argument I am frequently faced with when I am trying to convince new projects to implement federated access is that ‘this is only the prototype / early design, we will implement that later’. The real truth is that once you go down the route of a platform specific authentication system, it is going to be difficult and expensive to change that later.

I think that any JISC project that has any aspirations to becoming a service must design to implement federated access from the word go. By this I mean of course the ability to accept access management via the UK federation, but also how best to serve other types of federated access and identity such as credentials from OpenID, Protect Network, Information Cards etc.

The argument is strong for good software design right now. The expense of retrofitting is something that the Services Team will find difficult to support over the upcoming leaner years, and it would be nice to aspire to meet some of the software criteria we talk about so often and actually build that better burger.