Gallery

One sign-on to rule them all

Posted on 18 Jun 2009 at 11:12

What's the problem with implementing single sign-on for websites? Communications professional Simon Brock has the answer.

To make all this work you're going to need the following components: a module that plugs into your web server to implement cookie validation against the central authentication server; a system on the authentication server that accepts usernames and passwords, which it then checks; and lastly, if this is truly going to be single sign-on, these products must work with every web browser (which shouldn't be a problem), but you need them to work with more than one web server too.

Three approaches to web SSO

Having laid out what you need from a web-based SSO solution, it's worth noting how many solutions there are - in the open-source arena there are at least ten, and probably the same again of commercial or proprietary solutions linked to one operating system or another. A common theme that runs through these various solutions is the idea of a "campus solution". Four of these systems were created to solve the SSO problem for American university campuses, under the auspices of the "Internet 2" project, but there are projects from other areas too - for example, you should be able to find an interesting project by American estate agents. I'm going to take a look at three separate solutions: a simple pragmatic solution called mod_auth_pubtkt, a more featured solution called CoSign, and a very complex system called Shibboleth.

The simplest system I've seen is mod_auth_pubtkt, which can be found at https://neon1.net/mod_auth_pubtkt, a fairly new project that's based on a previous similar software system. The project provides only an Apache web server module and a simple script to generate the authentication tickets, and in principle it can be linked to any existing authentication system, although you're going to have to do that for yourself. Judging by its documentation, this system implements everything we want and is a good base on which to build more sophisticated systems. The second system I looked at was CoSign (http://www.umich.edu/~umweb/software/cosign) developed by the University of Michigan. CoSign is a far more complete system than mod_auth_pubtkt, which provides modules for Apache, IIS and a Java implementation that can be included as part of Java applications. There are also modules that will work with the Drupal CMS. CoSign comes with more components than mod_auth_pubtkt, including a small website to implement login and modules that connect to an LDAP server, as well as one that permits guest users to be registered. And finally, there's Shibboleth (http://shibboleth.internet2.edu), which is by far the most completely featured solution I looked at, and one that integrates with a collection of other apps and systems.

When we tried to get these systems off the ground, Shibboleth was by far the hardest work: it's one of those systems you need to install to work out how not to install it, then uninstall and install it again to make sure you've installed it properly. We did get Shibboleth working eventually, but it was very taxing and felt like a very complex solution. CoSign, on the other hand, was easy to get going and we were left feeling that any further integration we might need to do would probably be time well spent. Mod_auth_pubtkt felt like very much a DIY solution - we got it working, but it required more tweaking than we really wanted to do. You may have guessed that the one we decided to use was CoSign, which worked well and did what we needed it to.