Posted on July 5th, 2012 by Paul Stainthorp
A whole contingent from Lincoln—Andrew Beeken, Trevor Jones, Elif Varol and I—are at the Cambridge University Clinical School at Addenbrooke’s Hospital in Cambridge, for a mashed library event – Mashcat.
Mashcat is “a mashed library event focussing on cataloguing data. For cataloguers, developers and anyone else with an interest in how library catalogue data can be created, manipulated, used and re-used by computers and software”. It’s being sponsored by DevCSI.
We’re presenting about the CLOCK project to a room full of cataloguers. No pressure. The slides are online at: http://lncn.eu/hknp
Posted on November 17th, 2011 by Paul Stainthorp
I’ve had a useful meeting with my new boss to agree my priorities for the next 12 months of development work in the Library. Here are my top 4, in order of importance.
- Discovery selection & implementation;
- JISC Orbital project (0.3FTE) – based mainly in CERD until March 2013;
- Possible JISC-funded Jerome follow-on work;
- Development of the Lincoln Repository – working closely with the Library Institutional Repository Officer (BJ), the Research & Enterprise Office + the subject librarians on the following areas:
- Metadata workflow and service development
- Building a “Research Showcase”
- CRIS-like development, bibliometrics, and supporting the REF
- Developing staff profiles on the University’s website
- Helpdesk integration (…possibly)
The following are projects—part of the current Library I.T. strategy—that I’ll contribute to but probably won’t lead, and/or work that’s going on in the background that I need to stay abreast of:
- Reading list development (project);
- Authentication (project);
- Participation in various JISC working groups as well as UKCoRR and LISN;
- Working with the Acquisitions team on new team rôles/areas of work;
- Monitoring and guiding e-resource management (ERM), authentication, and responding to user problems (this area of work will be looked after day-to-day by the Library (E-resources) Assistant (EV), supported by other staff, as part of the cover for my JISC project work);
- Supporting the subject librarian for technology in a review of the Library’s presence on the University Portal;
- Supporting the subject librarians in promoting and supporting the use of RefWorks 2.0;
- Supporting the HELS in administering copyright/digitisation services and the use of Blackboard.
- Initiating a new CALM user group.
- Co-ordinating LIG (the Library Innovation Group).
- Participating in the work of LNCD.
G’won then: what have I forgotten about?
Posted on August 3rd, 2011 by Paul Stainthorp
We apologise for the late arrival of this blog post.
On the 22nd of July I was at the University of Nottingham for an RSP (Repositories Support Project) event, Repositories and CRIS: working smartly together. A few of us from the UKCoRR committee were there, giving UKCoRR’s new Twitter account some hammer. My colleagues, David Young from the University Research Office and Elif Varol from the Library, also went.
Here are some very brief notes on the various presentations and activities – all of the slides are on the RSP’s website.
- Simon Kerridge of ARMA (on the research administration, the CERIF standard, and the EXRI project). This has already led to some movement on the idea of a JISCMail ‘super list’ to allow information to be shared easily between members of ARMA and UKCoRR. All the talk of CERIF and REF requirements has also prompted us (Lincoln people) into action – a separate blog post about this will follow.
- RePOSIT presentations and breakout discussion – this was great fun. Like being back at the RSP Winter School again. Repository work and advocacy makes far more sense and the panic easiest quelled when I talk to other repository managers around a table.
- After lunch: more on euroCRIS from Mark Cox of King’s College London. Loads to look at, including the R4R (Readiness 4 REF) plugin for EPrints, and MICE (Measuring Impact under CERIF).
- The University of Glasgow’s “alternative approach”, involving some hardcore use of EPrints. This is the model Lincoln is following and it’s great to see it working so successfully for Glasgow. See their Research Outcomes work and Will Nixon & colleagues’ Enlighten blog. Also related: EPrints: A Hybrid CRIS/Repository.
- Finally, a whistlestop tour of EPrints version 3.3 and some of its new features, including one-click installation of plugins from the EPrints “Bazaar”. Looks very cool.
At this point: run for bus.
Posted on May 18th, 2011 by Paul Stainthorp
(Alternative title: why I’m going bald.)
Managing the authentication of university students and staff to electronic library resources is an awful, awful pain and I wish it would all just disappear. There, I’ve said it.
My line manager (Deputy Librarian: Academic & Technical Services, Lys Ann Reiners) is very keen for me to involve as many Library staff as possible in managing our authentication régime. For most aspects of my job, I’m more than happy to spread the love around (I don’t agree with keeping knowledge—or extra work—to myself), but when it comes to authentication, I feel guilty even asking my colleagues for help, in case I expose them to some kind of toxic authentication ju-ju death rays.
I realise that I can’t shy away from explaining things merely because they’re confusing and depressing. We can only make sense of authentication for our users once I’ve stopped putting my fingers in my ears and hoping it’ll all just go away. We have already made a start on documenting the mess, but it was these [Nicole Harris] two [Dave Pattern] recent blog posts which have spurred me into writing this, in the spirit of catharsis:
Authentication to e-resources at the University of Lincoln
A trilogy. A tragedy. A travesty.
1. IP authentication (for on-campus users)
- Some (but not all) of the 150+ e-resource publishers/providers with which we have a relationship have the University’s IP ranges on file. This allows people using on-campus computers to seamlessly access restricted content (e.g. full text) from those providers’ sites.
- But we have no real procedure for keeping those IP ranges up to date – i.e., of informing providers of any changes. I’ve asked my colleague (Library (E-resources) Assistant) Elif Varol to do something about this.
- In particular, we now have single ‘apparent’ external IP addresses associated 1:1 with each University building. This should mean we can [a] simplify the information we give to providers, and [b] associate usage with particular buildings.
- So far, so simple. But the fact that on-campus authentication is so seamless (as far as our users are concerned – they needn’t even know it’s there!) does cause a problem when those same users try and access the same resource from off campus and don’t get the same seamless access.
- Also, University ICT services occasionally look worried when I tell them about IP authentication. They just aren’t comfortable that I pass on details of our IP ranges to third parties.
- For resources where only IP-based authentication is available, in order to provide off-campus access we make use of a CGIProxy-based application which we call ‘LibResProxy’ (see part 3, below), with mixed success.
2. [Open]Athens and “Shibboleth” (but not really)
- We are members of the UK Access Management Federation. Our nominated, outsourced Identity Provider (IdP) is Eduserv, to whom we pay an annual subscription. This means we can use their product, OpenAthens (often just referred to as “Athens”), to provide local authentication (via University Portal login using network\accountID) to both ‘traditional’ Athens-protected resources and to resources which have abandoned Athens in favour of true federated access (which lots of people refer to as “Shibboleth“, even though that’s not really the correct terminology). The Eduserv software we’re running on the Portal is called ‘AthensDA’; we probably ought to upgrade this to a newer version called ‘OpenAthensLA 2.0‘, but we haven’t really discussed it yet.
- As far as the user is concerned, this means we can create a link to an e-resource which will work both on- and off-campus. These URLs are generally in the form: http://auth.athensams.net/setorg.php?id=LINCUNI&ath_returl=XXXXXXX, where the first part of the URL sets an Athens ‘preferred organisation’ cookie, associating the user’s computer with the University of Lincoln, and “XXXXXXX” is the percent-encoded URL of either: [a] the defined Athens authentication point for resources that use the ‘old’, traditional Athens protocol (these have to be activated first—”cascaded to permission sets” in Eduserv terminology—by an administrator); or [b] a WAYFless URL for a resource which uses the ‘new’ federated access. The format of this last category of WAYFless URLs are unpredictable and very difficult to build, and for some resources can’t be created at all, leaving the user with no choice but to navigate a horrible “Where Are You From?” form where they have to select their institution from a list before they’re allowed to log in.
- What the user sees when they click on this link is a blue-and-orange login page with a link to ‘Go to the University of Lincoln login page »‘. Clicking on that link displays a pop-up http login box (unless they are on campus using IE, in which case they’re logged in automatically), in which the user must enter some variation of network\accountID and their University network password. This is highly variable, depending on the user’s operating system and browser.
- This is fine for situations where we can control exactly where the user is going and what links they are clicking on, and where we have a chance to set the Athens cookie: this happy state of affairs applies to the University Portal, and almost nowhere else; certainly not to the open web and users coming via Google Scholar.
- Problems: and they are legion:
- We’ve not been systematic about migrating resources from the ‘old’ Athens login to the ‘new’ federated access. (We deliberately didn’t want to stop using ‘old’ Athens links to resources if they were working. If it ain’t broke…) For the user, there’s no difference between the two, hence the lack of urgency – for the Library, it’s become rather confused and difficult to manage.
- If, for whatever reason, the user doesn’t end up with (or loses) the Athens cookie which sets their preferred organisation, then they don’t see the link to ’Go to the University of Lincoln login page »‘, and instead have to follow the rigmarole of setting their preferred institution again. Needless to say, most students and staff are entirely mystified by this arcane process.
- Related to point 2: a students or member of staff who has a relationship with more than one UK institution (e.g. two universities/colleges, or a university and the NHS) tend to run into problems, because you can’t easily have two Athens ‘preferred organisation’ cookies set at the same time on the same machine. I know, I know: it doesn’t sound very “federated”, does it?
- Sometimes… it …Just. Doesn’t. Work. (Because of pop-up blockers, trusted sites, peculiarities of various versions of Windows, bugs in Google Chrome, leaves on the line, etc.) When this happens—when we can’t solve the problem—and when the user is getting very frustrated, I have to grit my teeth and generate a separate, “classic“ hum————— Athens username and password for that user. This gets around the access problem in the short term, but tends only to increase confusion in the longer term.
- Finally, and most frustratingly: all of this is completely blown out of the water if the user encounters a resource (a journal article, say) on the open web: via Google, or even via our own Electronic Journals A-to-Z. They don’t automatically see the OpenAthens login point, so they have to hunt down a link to “login to Athens here” (or similar). Each provider deals with this differently, so a user can’t necessarily apply what they’ve learnt from one resource to any other. Some providers (‘SPs’ in access-speak) allow libraries to construct complex ‘masked’ deep-linking authentication URLs. These make it easier for us to automate the login process from the A-to-Z to an individual journal. Others just don’t work that way – so we write help guides instead. Eduserv have a web page about creating deep links for authentication.
- If you’re not utterly, hopelessly confused by all of the above, then I bow down to your machine-like intelligence.
3. The grab-bag approach: everything else
- For e-resources that don’t work with OpenAthens, we have a number of tricks of last resort. Some of these tricks have been built for us by Tim Simmonds of the Online Services Team (ICT). When they work, they’re brilliant. But we have no control over whether they’ll work or not with a particular resource. They tend to use the Portal-esque network\accountID and password as login, which is at least consistent with OpenAthens.
- This includes our form capture tool, which we use to create ‘faked’ URLs for resources that have their own username and password (in effect, it pastes the login details into an HTML login form on the user’s behalf and hides the authentication from public view). The popular business database Factiva works like this.
- Last of all – if all else fails, we give a username and password out to the student and tell them to get on with it. We change these passwords once a year as a security measure.
We can’t go on living like this. In a future blog post, I’m going to map out a possible way forward for authentication. It’ll probably involve thinking about some of the plans my colleagues in ICT have for single-sign on and OAuth, and what those plans mean in a library context.