Atom and Shibboleth

The Search History and My References feeatures of the Copac Beta Test Interface are stored in a database with an Atom Publishing Protocol (APP) Interface. The idea is to make the database open to use by other people and services and so enable re-purposing of the data.

Authentication poses a problem. We need to authenticate so that we can identify the user and show them their records and not someone elses. We didn’t want people to have to register to use Copac and neither did we want to get into developing a mechanism to handle user registration, etc. So, we have used the JISC supported UK Federation (aka Shibboleth) Access Management system. This allows users to login to Copac using their own instiutional username. Registering separately with Copac is not needed to gain access.

The downside is that Shibboleth is designed to work with web browsers. I don’t know the technacalities of it all, but a login with Shibboleth seems to involve multiple browser redirects, possibly a WAYF asking “Where are you From?” and a web page with a bunch of Javascript that the browser has to interpret that redirects the browser yet again. I’ve tried accessing the Shibboleth protected version of our APP Interface with some APP client software and none of it could get past the authentication — however, it is very hard to diagnose where the problems are.

I also tried the command line program “curl” to access the APP Interface and while it can handle the redirects and the username and password I think it fails when it gets to the page with the Javascript. Which is fair enough, “curl” isn’t a web browser, it is just a program that retrieves urls.

So, can we make do without Shibboleth? Well we can, but the options are either not terribly insecure or not practical. The options I can think of are:

  1. We put a token (eg a unique id) in the url. This effectively makes the users collection of records and search history public if the url is published.
  2. We put the token in a cookie. This is still insecure and subject to cookie highjacking, but is more private as the token isn’t in the url. Many high profile web sites seem to use such an cookie for authentication, and if they do, then I don’t see why we shouldn’t? However, I’m not sure how practical it is to get third party APP clinet software to send the cookie — unless the APP client was written as part of a web browser that already has the cookie.

You can try accessing the Shbboleth protected APP server for yourself at the following url:

  • https://copac.ac.uk/atom/

If you’ve already used the Copac Beta then your Search History and My References collections can be found at the following urls in the form of Atom feeds:

  • https://copac.ac.uk/atom/saved-searches/
  • https://copac.ac.uk/atom/my-references/

Please let us know how you get on! I’ve tried the above urls with Firefox and Safari. Firefox gets through the authentication and displays the Atom feeds and Service Documents. Safari seems to put itself into an infinite loop whilst trying to display the feed (maybe this is something to do with the XML in our Atom feed?)

We’d be very interested to hear your thoughts on the above.

4 thoughts on “Atom and Shibboleth

  1. Just some quick comments – I’ve just tried accessing my own ‘my references’ feed using Chrome – having already logged into COPAC beta via Shibboleth separately.

    This seems to work fine – I can access the feed in my browser. However, if I try to add it to Google Reader it sees it as empty (of course)

    However, I think we need to get down to some use cases on this. Why would I want to access a feed of my own searches/refereces in a feed reader? This seems an unlikely application as I don’t need to be updated on this.

    The first use that comes to mind is the ability to embed the list into other web resources – but for this to happen I’d need to be able to make the feed publicly available – so the idea of a simple dedicated URL appeals in this instance.

    What other use cases are there?

  2. Owen, I think the important thing is that the records/searches are available as an Atom feed – a well know format that is easy to work with and should be easy to re-purpose. So, if for example, I want to take along a set of references to lookup in a library, I can tag them and then pull up a feed of those tagged references on my mobile device when I get there. Similarly, I may want a set of pre-defined searches to take along to a demo/meeting/seminar.

    What we are trying to do is make the data available in ways that are easy to work with so that people can do things with it that we haven’t envisaged. The potential is also there to add data from services other than Copac.

    The ability to make your feeds public will come… (sooner rather than later.)

    Ashley.

  3. I agree completely! I’m really happy that you are providing these as Atom feeds.

    What I meant was that before we can answer the question of how to best ‘protect’ the feeds, we need to understand how they might be used.

    Since my immediate desire is to reuse the feed in some way, then it would be much easier if you followed your suggestion of a unique id in the URL – as then I can make the decision straight away of how I reuse – I can embed in various environments without sharing the details (e.g. in my own blog), or if I want I can tell other people the location.

    So – there’s my vote!

    However, I can understand others might only want to use the marked list within the COPAC environment, and don’t care about reuse, but do care about security – and they are going to have a different answer.

    In terms of the beta, it would be great (IMO) to do it as a unique token in the URL, because then you will see experiments in reuse as well – which is impossible while it is protected with Shib.

  4. JavaScript is not good for this sort of thing. This means making any of the data machine-useable is very hard which means building services or programs that use the information is hard – and it shouldn’t be.

    Also keep in mind that many web browsers, particularly those in mobile phones might not work properly with JavaScript cruft. Imagine you’re somewhere deep in the stacks and you want to look something up – why not do it right then and there instead of going to find a computer?

    Cookies are better but still unwieldy. I agree with Owen that if at all possible tokens in nice stable (RESTful) URLs are the best.