Just a quick note to say that the latest release of EasyDeposit now supports Shibboleth authentication. Or to be precise, it supports any form of authentication where the user’s details are passed via HTTP headers / environment variables. This includes other SSO (Single Sign-On) systems such as CoSign.
To use, select the ‘ssologin’ step as the first step. Edit the settings to state which headers to look at, and it should all work. Of course you’ll need to configure your web server and single sign-on system to protect your EasyDeposit installation directory.
It was nice to see the announcement recently from the MAMS (Meta Access Management System) project at Macquarie University in Australia that they have implemented Shibboleth authentication for DSpace 1.5. It makes use of the stackable authentication system, and is therefore very nicely integrated with the DSpace architecture.
I’ve been playing with Shibboleth a bit recently, trying to get Blackboard on Windows to work with it. Apparently it works on Unix, but no one knows about Windows. To cut a long story short, I got it almost working. Shibooleth will get our local identity provider to perform the authentication, but unfortunately the IIS Shibboleth ISAPI filter sets the username in the HTTP_REMOTE_USER header, rather than the REMOTE_USER header. Blackboard isn’t configurable enough to look in either. So an enhancement request has been submitted!
Anyway, I was thinking it would be nice to convert our DSpace instance to use Shibboleth authentication rather than than LDAP. The great power of Shibboleth will be when all our systems use it, and we only have to log in to the IdP once. But I hit a snag in my thoughts…
I’ve just told a professor in our university that he could use our SWORD interface to remotely deposit some data that he is creating on a geographically remote server. This means he can periodically automatically archive the data in order to abide by the terms and conditions of the AHRC grant that is funding his work. How would SWORD work with Shibboleth? SWORD works with HTTP basic, and it would be hard to delegate this in the background to Shibboleth. So does that mean I can’t use Shibboleth?
But then I remembered the modular structure of DSpace. Each module (such as the user interface, the OAI-PMH interface, the SWORD interface) is deployed to the application server separately. Each module can therefore have its own configuration. Normally they would share a single configuration, but I could use different configurations for each one. The normal user interface can use Shibboleth for authentication, and the SWORD interface can keep using LDAP,or what might be even better would be to use the local in-built password system in DSpace so that the professor doesn’t have to embed his university username and password in a script.
So to conclude – we can use Shibboleth with DSpace whilst still having a working SWORD interface. Nice!