Last weekend, we looked at how to enable your Web site to accept OpenID logins. But accepting OpenID authentication is only half of the issue — if you care about online privacy and identity, the chances are that you will want to control your own OpenID. Fortunately, setting up your site to serve as an OpenID provider is not that difficult — and makes a great weekend project.
Given how many commercial and free public services already act as OpenID providers, some might wonder why you would want to serve as your own identity provider. For many individuals, it is just a desire to define one’s own identity. A domain that you own has more individuality than google.com/profiles/somelongalphanumericstring, and if the URL you use as your OpenID is a blog or personal site, wherever it appears online will direct people back to the content that you want them to see and associate with you. Others (particularly in the Linux and free software realm) may begrudgingly have an OpenID from a proprietary service, but don’t want to publicly seem affiliated to it, or don’t trust its long-term stability and/or non-evilness.
Beyond the individual, though, if your site is a Web service, community group, or project, you may wish to configure your server to provide OpenIDs for your users simply to give them the opportunity to use your branding as their primary identity. Your business may want to provide OpenIDs for its employees, so that they can interact with customers and clients online without using their private, home IDs.
Finally, there is no rule that says you must or even should stick to only one OpenID yourself. It might make sense for an Ubuntu packager to use his or her Launchpad OpenID on all open source sites and forums, but self-provided OpenID to promote and tie in to the family’s lucrative kitten-grooming business. Choice is good.
Delegation
By far, the simplest way to take control of your own OpenID is with the OpenID specification’s delegation support. Any particular OpenID is, itself, a URI. With a commercial service, you are stuck with whatever URI the provider dictates to you, such as http://www.flickr.com/photos/willis for Flickr. On your own server, however, you can select any URI that you control to function as your OpenID.
With OpenID delegation, rather than running a full implementation of the OpenID provider service at the URI you choose, you can include special header links that associate the URI with some other “upstream” OpenID. Whenever you sign in to an OpenID-accepting site, the OpenID consumer will trace back the header links to the delegated OpenID provider, and ask you to authenticate there.
Once you are authenticated, though, you are signed in to the OpenID consumer site under the URI that you control. In other words, the OpenID delegation process is all behind the scenes as far as the public is concerned. You could start off delegating your OpenID to your Google Account, then switch it to Yahoo on a whim, and no one will know.
The HTML syntax is simple, but it does differ between sites that use OpenID 1.1 and OpenID 2.0. The old version of the protocol required two <link> elements: one to point to the delegated upstream server, and one that specified which upstream URI was your OpenID. For example:
<link rel="openid.server" href="http://www.theupstreamopenidserver.com/opserver" /> <link rel="openid.delegate" href="http://accounts.theupstreamopenidserver.com/jimrockfish" />
The OpenID 2.0 syntax uses different rel attributes, but is basically the same two <link>s:
<link rel="openid2.provider" href="http://www.theupstreamopenidserver.com/opserver" /> <link rel="openid2.local_id" href="http://accounts.theupstreamopenidserver.com/jimrockfish" />
If you simply want to create a static page to serve as your OpenID, all you need to do is place the four <link> elements in the document <head>, and you will be set for both generations of OpenID-consuming sites. The rest of the page contents are entirely unaffected. Just remember that the OpenID is specific to a particular URI, say blog.jimrockford.com; make sure you don’t generate the <link> elements on every page at the domain.
The truth is, the hardest part about delegation is tracking down the correct server/provider and delegate/local_id URIs for your upstream OpenID provider. Most don’t make them easy to find, since so few customers seem to care.
A good Internet search session will get you far, but if you are impatient, the most common services are well-known. Stack Overflow discusses delegating to Google’s public profiles (which only recently started accepting delegation) and to Yahoo’s OpenID service. Stas Su»ôcov has a succinct account of Launchpad.net’s proper syntax on his blog, and Daniel J. Pritchett’s blog covers delegating to LiveJournal. Make sure you read all of the comments on these discussions, as the URIs do change every now and then.
Prepackaged Solutions
If your site runs a CMS (and you therefore cannot tweak pages’ <head> sections without breaking things), or if you simply faint at the site of straight HTML, you may prefer to install a delegation plugin or extension to do all of the heavy lifting for you.
WordPress users can find several OpenID-related plugins, although, as always, freshness and compatibility are of concern. The simplest up-to-date option is OpenID Delegation, originally written by Eran Sandler and updated for OpenID 2.0 by Rich Laager.
Will Daniels has similarly adapted and enhanced abandoned code from a much older Joomla extension to work with the OpenID 2.0 syntax. His version is called System – OpenID Delegation.
Drupal users have it the easiest of all; no special plugin is required. You can simply follow the OpenID delegation how-to for instructions on adding a block containing the right <link> elements. There is a separately maintained module called OpenID URL available too, if that suits you better.
The advantage of using a plugin or module is that it can give you a simpler interface for switching to a different OpenID delegate if you first choice enters bankruptcy protection or goes sour and starts suing open source projects. On the down side, if the author stops updating the code, you could get tripped up by version incompatibility and be stuck editing the HTML by hand anyway.
Forget Delegation and Carve Out Your Own Identity
As convenient as it is for many people, delegation is not the only option. You can run your own OpenID provider, too, meaning that you maintains all of the user accounts and handle the entire authentication process. It might be overkill for individuals, but for projects and businesses, having a centralized system is easier to maintain and to troubleshoot.
There are not as many plugin and extension solutions that implement an entire OpenID identity-provider service, but there are a few. The WordPress OpenID plugin mentioned last week as a consumer can also act as a provider, with an OpenID for each user account. DjangoID is a multi-user OpenID provider for the Django framework, and there is a Python plugin for the PyBlosxom blogging platform.
Beyond the plugins, there are several standalone OpenID provider systems written in various languages. On the lightweight end of the spectrum, SimpleID is a PHP-based OpenID provider aimed at working for small sites. The Ruby application local-openid is similarly designed for single-user environments.
Moving up in size, Prairie and Community-ID are both multi-user OpenID providers written in PHP. Packetizer’s OpenID Server is a multi-user standalone system written in Perl. SamƒÅdhi is written in Python, and designed to run on the TurboGears framework. There are several Java-based provider packages, all of which seem to target large-scale deployments. WSO2 Identity Solution and Crowd are two of the better known.
Finally, as was the last word on OpenID consumers last week, if you just cannot find a ready made identity provider for your platform of choice, you can implement your own using one of the many OpenID libraries. Here again, the best place to start a new search for code is at the OpenID project’s official wiki. In addition to the Libraries page referred to in the previous weekend project, consult the Run your own identity server page, which has some overlap, but also several distinct projects. As always, caveat wiki-er; several lower-level OpenID frameworks that were popular a few years ago are still widely referenced, but abandonware.
Identity Heft
Whether you delegate from a static HTML bio page, run a flexible plugin on your blog, or administer a complete OpenID providing solution, your identity is now your own. But to really take advantage of that power, don’t simply use your domain’s base URI as your OpenID and confront visitors with an enigmatic empty page informing them that Apache was installed successfully. Instead, give the public some content — just do it in an OpenID-friendly way. Rather than linking to your Facebook profile, mark up public information about yourself in hCard format. Rather than an old-fashioned blogroll, use XFN. Maybe even add a basic profile with Webfinger, or simply tell everyone what you are doing with your Linux box next weekend.
