OpenID: Decentralised Single Sign-on for the Web
OpenID [1][2] is a single sign-on system for the Internet which puts people in charge. OpenID is a user-centric technology which allows a person to have control over how their Identity is both managed and used online. By being decentralised there is no single server with which every OpenID-enabled service and every user must register. Rather, people make their own choice of OpenID Provider, the service that manages their OpenID.
One key function which OpenID supports is the ability for a person to have ‘single sign-on’ across multiple OpenID-enabled services. Having provided their OpenID to the Relying Party they want to access, users are then redirected to their OpenID Provider in order to check their credentials. This means that sites which implement OpenID do not ever know the user’s actual password (or other credentials). The benefit to users is increased security, particularly by employing a strong approach such as a one-time-password to login to their Provider, and a much simpler login experience on the Web. Note that although true single sign-on is achievable using OpenID it is not a requirement and there may be reasons why an individual will want to retain multiple online identities (i.e. multiple OpenIDs) for their different online activities.
OpenID grew primarily out of the blogging community where there was a requirement for people to take the identity used to write their own blog and use it when commenting on other people’s blogs. OpenID was originally deployed to 9 million users on LiveJournal.com; it has since seen steadily increasing adoption across the Internet. It is particularly interesting to look at its rate of adoption over the past few months. Not only have the number of OpenID-enabled users grown to around 90 million (estimated from various OpenID 1.1 Providers, with the majority of users coming from AOL) but the number of places where OpenID can be used is growing at an increased rate.
Figure 1: OpenID Relying Party adoption as seen by JanRain’s MyOpenID.com
Although OpenID started with the blogging community, it is beginning to see adoption in technologies like the Ruby on Rails framework, the Zend PHP framework, and the Django Python framework. In addition, services such as Technorati, WordPress.com, 37Signals, and Digg.com (in progress) have added support for OpenID. Large service providers and enterprises such as AOL, Symantec, VeriSign, Mozilla, Novell, Microsoft, and Reebok have also begun working with OpenID in various products and services.
In the majority of cases, an OpenID is a URL, which means that the Relying Party can easily use it to determine the location of the OpenID Provider without recourse to some kind of directory service (such as the Where Are You From (WAYF) service used in Shibboleth [3]). Additionally, the formulation of the OpenID as a URL has the added advantage that information about the owner of the identity can be made available to interested parties. URLs are also fairly easy to remember and can be book-marked for later use in services such as del.icio.us [4]. An example of this can be seen at the OpenID-enabled site Doxory.com [5], a service that tries to discover any friends you have listed via FOAF (Friend of a Friend) [6] at your OpenID URL. For example, if you log into Doxory using a LiveJournal.com OpenID, Doxory automatically shows you which of your LiveJournal friends are already using the service. The combination of OpenID and Microformats [7] such as hCard also makes it possible to discover public contact information about the owner of an OpenID. Thus OpenID begins to provide the core pieces of infrastructure required for truly portable and user-owned social networks.
OpenID is a relatively simple standard that does a relatively simple job - single sign-on in a distributed and free environment. It does not try to provide trust or distributed authorisation solutions but is an enabling technology on which these sorts of services can be built. For example, it supports the transfer of attributes (information about the owner of the OpenID) upon which decisions about trust and authorisation can be based. This also means that users are able to easily share information such as their email address, nickname, or zip code when logging into OpenID-enabled sites, if they choose to do so. It therefore provides the benefit of more accurate information, as users do not need to re-type it every time they sign-up with a new service.
That’s the theory anyway. Let’s take a closer look at how it works in practice.
An Example
As an example, consider registering with and logging into a Web 2.0 social service called Ziki [8]. The OpenID used in these examples is http://andypowell.myopenid.com/, which is often shortened to ‘andypowell.myopenid.com’ for convenience. This OpenID was obtained by registering with the MyOpenID service [9]. There are now many OpenID Providers to choose from, though people often use the OpenID provided by their blog hosting service. Note that the process of creating an OpenID is not shown here.
The Ziki home page has an option for signing up for a new Ziki account. See Figure 2.
Figure 2: Creating a new Ziki account
Selecting the ‘Create your Ziki now’ button takes the user to the registration page which indicates that the service supports OpenID as a registration mechanism. The usual convention is to present the OpenID logo next to any OpenID-enabled login boxes, though at the time of writing Ziki does not seem to have done so.
Figure 3: Ziki sign-up options
Putting in the OpenID and selecting the ‘Sign-up with OpenID’ button takes users to their chosen OpenID Provider. To help protect users from phishing attacks [10], it is recommended that the Provider’s login page is bookmarked and used whenever a new browser session is launched. Many providers, including MyOpenID, have the notion of a ‘Safe Sign-in Page’ which is displayed instead of the login form when coming from Relying Parties (Ziki in this case). As we discuss later, using other more secure authentication methods, rather than a password, can greatly help to reduce these sorts of attacks. Once users are authenticated to their Provider, they will be shown some additional information about the Relying Party that is being logged into. Notice that the password is only supplied to the OpenID Provider, not directly to the Ziki service. Information is also provided on which attributes about the user are going to be passed back to Ziki. The option of authenticating for this session only, forever, or not at all, is offered. In this case the choice is made to ‘Allow Forever’. See Figures 4 and 5.
Figure 4: MyOpenID password
Figure 5: MyOpenID authentication options
At this point the user is passed back to the Ziki site where they can complete the registration process. Typically this will include supplying additional site-specific registration information, over and above the information that was supplied as attributes by the OpenID Provider. It may also include an email confirmation step. See Figures 6 and 7.
Figure 6: Completing the Ziki registration process
Note that work currently being done on the OpenID Attribute Exchange specification means that in the future all the required information will be able to be requested from the person at their Provider.
Finally, the button to create an account is selected.
Figure 7: Ziki account activation
Now imagine that users then log out of Ziki and sometime later opt to log back in. They go to the login page and choose to use the OpenID authentication option, putting their OpenID into the box provided.
Figure 8: Ziki login options
Selecting the ‘Login’ button takes the user back to their OpenID Identity Provider, where the password or other credentials can be confirmed. However, because the “Allow Forever” option was previously chosen for the Ziki service, this step is completely invisible. It takes place behind the scenes. As far as the user is concerned they are passed directly to their Ziki home page and already logged in.
Figure 9: Logged in to the Ziki service
A similar process can be followed for every OpenID-enabled service that the user wishes to use.
Lists of services that support OpenID are beginning to appear, for example, see The OpenID Directory [11], but it is still fairly early days in the development of OpenID. While they are certainly growing in number, not many of the high profile Web 2.0 services support it yet; we hope this will change in due course.
OpenID and e-Learning
So, what is the relevance of OpenID to e-learning? Proponents of Learning 2.0 [12] and Personal Learning Environments (PLEs) argue that we are going to see far greater use of ‘informal’ Web 2.0 services as part of the delivery of learning in our ‘formal’ learning institutions (schools, colleges, universities, etc.). If we accept this argument, then the use of OpenID is likely to become increasingly important to our learners. It can also be argued that the rhetoric of ‘single sign-on’ does not carry much weight if what we really mean is one username/password pair for our formal learning services and a second pair for ‘external’ services. As a community, we need to set ourselves the target of enabling true single sign-on to services delivered both inside and outside our institutions. Doing so almost inevitably means adopting solutions that come from outside our own sector.
Secondly, it also seems fairly clear that our learners are likely to want an online identity (or several online identities) that span the different phases of their education and that span the individual institutions within any particular phase. Why should we expect our learners to adopt a different online identity simply because they have moved from school to college or from college to university? Indeed, why would learners want their online identity to change because they have left formal education and moved into the longer-lasting and more flexible environment of lifelong learning? Why should learners have to adopt different online identities just because the modules on their chosen course happen to be delivered by several institutions? Much the same arguments can be made about researchers, as well as for employees and individuals.
In the future, it may be the case that our institutions remain as Identity Providers (i.e. as the providers of usernames and passwords) in the way they are now. But it also seems increasingly likely that our students will begin turning up at schools, colleges and universities with perfectly good online identities (in much the same way that they now turn up with perfectly good email addresses) and that our educational institutions will have to begin functioning as Relying Parties (i.e. as the recipients of externally authenticated users). In short, students are part of the wider online community and their educational identity (persona) is only one facet of their lives.
OpenID and Shibboleth
Within the UK education community there is fairly widespread commitment through JISC [13] and Becta [14] to a Shibboleth-based approach [3] to access and identity management, realised primarily through the development of the UK Access Management Federation for Education and Research [15]. Shibboleth leaves identity management within the remit of the institutions (though they may choose to outsource the provision of the service to a third party [16]). It therefore does not meet all the potential requirements for user-centric, lifelong identity management outlined in the discussion above.
However, one of the key requirements for institutions adopting Shibboleth is to clean up their internal directory service provision and to take a strategic view of the management of their users’ online identities. In adopting Shibboleth, institutions are likely to put the internal ‘identity’ infrastructure in place that will make it relatively easy for them to become OpenID Providers and Relying Parties. Although it is clear that a transition to fully open identity technologies such as OpenID will not happen overnight, institutions must start looking at how identity is managed and how that process can be enhanced the better to support the changing world of online learning.
Open Issues
Like any standard in the area of access and identity management, OpenID is not without some open issues - nor without its critics.
As mentioned above, one potential problem lies in the area commonly known as phishing. In a phishing attack, a service provider presents a login box on their Web pages that takes users to a page that looks like that of their OpenID Provider, but which is in fact a service hosted by someone else. Such a service could gather the passwords of unsuspecting OpenID account holders.
There have been some lightweight attempts to circumvent this problem, in part relying on user education about such dangers, the use of HTTPS rather than plain HTTP to communicate with the Provider and user-specific watermarks or other images embedded into the Identity Provider page. More recently, some OpenID Providers have offered support for browser certificates to get around the phishing problem [17][18]. In addition, the recently launched MyVidoop.com [19] service is designed to help further resolve the phishing issue with OpenID, changing how users authenticate online by removing traditional passwords. VeriSign has also demonstrated a Firefox extension, to be released at the Internet Identity Workshop in May 2007 [20], which looks to help solve these issues from within the browser itself. VeriSign’s OpenID Seatbelt plugin [21] is designed both to make OpenID more convenient by automatically filling in a user’s OpenID URL, providing information as to whether the user is logged into his or her Provider or is on the correct page to do so, and looks at the OpenID interactions to help fight phishing proactively. However, at the time of writing, it remains an issue in need of a complete solution.
Implementation Options
Various toolkits and libraries are available to help with OpenID implementation, for both Identity Providers and Relying Parties, in a huge variety of programming languages. More detail about this can be found on the OpenID wiki [22].
Conclusions
OpenID is a technology around which there is a growing interest. Recent commitments to OpenID by AOL, Microsoft, and many other Web 2.0 services place it very firmly in the centre of online identity and access management discussions. It seems highly likely to have a significant impact on the services that learners and researchers will use in the future.
It is unfortunate that, at the time of writing, there is not greater adoption of OpenID by some of the better known Web 2.0 services. However, as time passes it seems clear that we are likely to see its adoption by more and more of them. We also encourage readers of this article to reach out to services online that you’d like to see OpenID enabled.
For UK educational institutions, OpenID is likely to become one of several access and identity management standards that they need to support. Therefore, strategic planning in the area of access and identity management needs to take account of the requirement to support multiple standards, and changes to those standards, for some time to come.
References
- OpenID http://openid.net/
- Wikipedia: OpenID http://en.wikipedia.org/wiki/OpenID
- Shibboleth http://shibboleth.internet2.edu/
- del.icio.us http://del.icio.us/
- Doxory.com http://doxory.com/
- The Friend of a Friend (FOAF) project http://www.foaf-project.org/
- Microformats http://microformats.org/
- Ziki http://www.ziki.com/
- MyOpenID https://www.myopenid.com/
- Wikipedia: Phishing http://en.wikipedia.org/wiki/Phishing
- The OpenID Directory http://openiddirectory.com/
- Wikipedia: Learning 2.0 http://en.wikipedia.org/wiki/Learning_2.0
- JISC http://www.jisc.ac.uk/
- Becta http://www.becta.org.uk/
- UK Access Management Federation for Education and Research http://www.ukfederation.org.uk/
- When outsourcing makes sense. Posting by Andy Powell to eFoundations, 15 November 2006
http://efoundations.typepad.com/efoundations/2006/11/when_outsourcin.html - myOpenID release & redesign
http://kveton.com/blog/2007/04/17/myopenid-release-redesign/ - And then there were none - Zero Passwords with Client Certificates
http://janrain.com/blog/2007/04/20/and-then-there-were-none-zero-passwords-with-client-certificates/ - MyVidoop.com https://myvidoop.com/
- Internet Identity Workshop, 14-16 May 2007
http://iiw.windley.com/wiki/Workshop_2007 - OpenID at Web 2.0 Expo
http://www.readwriteweb.com/archives/openid_at_web_20_expo.php - OpenID Wiki - Libraries
http://openid.net/wiki/index.php/Libraries