Single Sign On (SSO) has become an issue in a project I am working on, so I thought I’d say a few words on this here, lest I keep repeating myself. For the uninitiated SSO is a method of decentralized access control that enables a user to identify themselves with a common piece of information, and gain access to multiple SSO enabled resources. On top of these systems, trust mechanisms can be built that authorize particular sets of users to access particular set of resources. As is widely discussed elsewhere, identity and trust are two separate issues when it comes to authentication. Trust first requires identity, although the two are often conflated. SSO is advantageous because it helps eliminate password fatigue, the problem of having multiple passwords for different resources. SSO is also potentially more secure, and makes for a better user experience.

There are a number of protocols that can be used to manage SSO. Much of the academic community (particularly JISC, the Joint Information Systems Committee in the UK) seemed to have settled upon Shibboleth to deliver this. Shibboleth offers a number of advantages, but the bottom line is that Shibboleth is an institution-centric approach to identity management in which an organization (like a university or museum) acts as broker and trusted verifier of the authentication data. In this system one organization must agree to accept the word of another, when a foreign user logs in to their system. For institutionally managed resources this works well, but presents serious problems for users working outside any formal institution, or in situations where the content creators are individuals and not institutions. In these instances resource creators need to be in control of who and how others access their work, independent of any organization or institution. This is crucial because this control is central to the incentive mechanism through which creators generate content, especially scholarly content. If you remove a creators right to control how their work is accessed and reused, you break the incentive cycle that led the creator to generate content. At the Natural History Museum (NHM) we are engaged in building systems of scholarly communication (Scratchpads – based on the Drupal CMS) that enable peers to collaborate in the creation of web based digital repositories of biodiversity related data. Users need to be able to control, who, how, and when others access their work during the content production process. For this we need a simple user-centric identity solution that provides access and puts users in control of how their identity is managed and used online. Because our content providers are highly distributed, and often not affiliated with any organization, institution-centric identity management systems like Shibboleth are inappropriate.

OpenID is arguably the leading solution to providing a user-centric approach to identity management. OpenID is similar to Shibboleth in that both provide an identity service for applications such that identity management is left to these services, and not the applications themselves. The difference is that with Shibboleth an institution (typically your home institution) asserts that you are who you say you are. With OpenID this assertion is left to the user. Ultimately it is for the content provider to trust whether a user is who they say they are when gaining access to a resource. Peer-peer collaboration occurs through social trust mechanisms established through personal contact between people, NOT policy managed trust mechanisms established between institutions. OpenID’s user centric approach reflects the process of scholarly communication and collaboration, in a way that Shibboleth does not. For this reason we will be using and promoting OpenID in the tools we create (notably the Scratchpads).

Are there any other reasons why one might support OpenID over Shibboleth?

• OpenID provides a life-long and sustainable solution to the problem of identity management. By comparison, Shibboleth identities only last as long as an individual is affiliated with an organization, or for as long as that organization exists.
• There are already over 120 million Open ID accounts. It is gaining adoption by large organizations like AOL, Symantec, VeriSign, Mozilla, and Novell. Even Microsoft is working on implementing OpenID 2.0 in Windows Vista. Check out Google Trends (OpenID vs. Shibboleth) for some numbers.
• OpenID is ultra easy to support in Drupal (our CMS of choice for the Scratchpads we are developing at the NHM), via the OpenID module. Also OpenID will be native to Drupal 6, meaning that it will be one less module for us to support, and will seamlessly hook in to the other user related modules we are using (e.g. Legal).
• Setting up an OpenID server was a breeze (about 10 minutes work) meaning that we can act as an OpenID Provider for our community of users. This potentially allows us to seamlessly offer extra services to those directly registered with us.
• Related projects like the Encyclopedia of Life (EOL) will require user-centric identity management solutions. OpenID will be perfect for EOL, and it is important that our work at the NHM (such as the Scratchpads) integrates with these larger biodiversity related projects.
• We can transparently integrate OpenID with other user-centric identity management solutions via services like those of whobar.

How can OpenID (or any SSO) be more secure than having lots of different passwords?

Services with OpenID enabled never know the users password or login credentials. When a user attempts to gain access to an OpenID enabled service (like this website), they are redirected to their OpenID provider. This happens because OpenID’s are usually URL’s. The OpenID provider must authenticates their credentials and redirects the user back to the original OpenID enabled service to allow the user access. Anyone can become an OpenID provider and consequently no single provider contains everybody’s credentials

Are there any problems with OpenID?

OpenID may prove vulnerable to phishing attacks in which a user is tricked into providing their login credentials through a malicious service (e.g. a fake website) that redirects the users to a site masquerading as the users real OpenID provider. The OpenID 2.0 specification is attempting to deal with this.

More Information

• There is an excellent article by Andy Powell and David Recordon on OpenID, which includes some discussion comparing OpenID with Shibboleth.
• Sxip have some open source tools to handle identity. As mentioned above, whobar looks particularly interesting in the context of handling multiple SSO protocols.
• Otherwise checkout the OpenID website.