OpenID is a critical piece of “Open Web” infrastructure. The ability to authenticate users without relying on a single gatekeeper entity puts every site on an equal playing field. As a result, community-driven, decentralized networks can enjoy all the same advantages as closed-source, proprietary players, and end users retain more of their autonomy and privacy. All of that sounds well and good, but it is not much use if you don’t enable OpenID on the sites that you maintain. This weekend, why not add support for OpenID logins to your web service? You might be surprised how many LAMP and LAMP-like frameworks have a straightforward solution.
Admittedly, OpenID had its share of problems, particularly in the early days. Before there were ubiquitous OpenID providers, it was confusing for users and seemed indistinguishable from other single-sign-on systems. On top of that, OpenID login widgets suffered from the “NASCAR problem” (confronting users with a cacophony of tiny site-logo buttons with little explanation), the standards process seemed to get bogged down entirely, and other technologies like OAuth started competing for developer attention.
Despite the hurdles in the beginning, the situation has improved considerably in just a few short years. The odds are that if you use an open source content management system (CMS) or web application framework, you can enable OpenID for visitor interaction such as comments and/or for actual persistent user accounts. In the long run, supporting OpenID should reduce your account-management headaches. Let’s survey the latest options.
Systems Offering Native OpenID Support
A few open source CMSes offer native support for acting as an OpenID “consumer,” which is OpenID slang for a site accepting OpenID authentication. Unless otherwise specified, all of these packages support the current, 2.0 version of the OpenID specification.
Drupal was one of — if not the — first. Drupal 5 featured an OpenID extension module, but OpenID was fully integrated with the Drupal 6 release in 2007. The official administration guide documents how to use OpenID for user management.
Plone also includes OpenID consumer support by default, for version 3.0 and later. For security reasons, Plone defaults to placing OpenID users in a low-privilege “Authenticated” virtual group, but site administrators can change this policy site-wide to enable full interaction.
Two open source wiki packages include built-in OpenID consumer functionality. Ikiwiki’s, dating back to 2008, is courtesy of a plugin which is enabled in default installs, though optional. Tiki Wiki‘s OpenID support was introduced with the project’s 2.0 release. It is available in the default install, but must be activated by administrators.
At present, Simple Machines Forum (SMF) is the only dedicated discussion forum system to include built-in OpenID functionality (at least among projects in widespread usage). You may wish to check out the latest version of SMF from Subversion, though; there have been incompatibilities reported between SMF’s implementation and major OpenID providers Google and Yahoo.
Last but certainly not least, the StatusNet microblogging system includes OpenID support, although if you use one of the free, cloud-hosted services emanating from the official status.net domain, it may be temporarily disabled for bug-fixing. If you run your own instance of the software, however, it is a standard administration option.
Systems supporting OpenID via plugins
The next-best thing to native OpenID consumer support is the ability to install an OpenID plugin. In some cases, site administrators can understandably be wary of this option, if the plugin is from a third-party source. Several OpenID plugins developed by individuals have come and gone for popular CMS and blogging packages over the years, and relying on one with a less-than-certain-future could leave you in the lurch when there is an API change in a future release. Such problems are not always the case, though; a quick review of the plugin’s history is generally enough to let you know whether is has long-term dependability.
The WordPress blogging platform, for example, has a well-supported OpenID plugin that supports both OpenID authentication of users, and OpenID authentication for commenters. For API compatibility reasons, it is generally only available for the current generation of WordPress itself, at present 2.8.x.
The popular web discussion forum package phpBB has had a spottier history with its leading OpenID plugin solution, OpenID for phpBB. At present, the plugin is reported to work well with the latest releases of phpBB3, but it does tend to lag behind core phpBB releases in the long run. There are occasionally other MODs developed for phpBB, but few that last.
In the wiki space, both MediaWiki and DokuWiki have OpenID plugins. MediaWiki’s OpenID extension has thorough documentation, including instructions on how to upgrade from previous versions without losing user account data. DokuWiki’s plugin documentation cites some potential compatibility warnings; it is also unique in that it includes the ability for the site administrator to restrict OpenID access to a particular OpenID provider.
The Xoops CMS and XoopsCube application platform can be OpenID-enabled through a third-party module. In both cases, some post-installation work is required to fully integrate OpenID users with the rest of the system, but this process is documented.
An OpenID module is available for the WebGUI CMS as well, which is reportedly slated to be moved into the WebGUI core for a future release. It has been stable for several years.
Finally, the Trac bug-tracking system supports an OpenID plugin, making it perhaps the only bug-reporting package to support such a feature. There are installation and compatibility instructions at the plugin’s page, which among other things note that only Trac 0.11 is currently supported.
OpenID frameworks
Even if your site does not run any of the above-listed packages, not all hope is lost. Most web application frameworks have solid OpenID libraries these days, including Django, Rails, Zend, and many more. Barring that, there are OpenID consumer libraries for all of the common web development languages: PHP, Ruby, Perl, Python, Java, etc.
The best place to look for current information on OpenID support in development libraries is probably the official OpenID wiki. The Libraries page attempts to maintain an up-to-date-list of all active OpenID projects, sorted by framework and by language, and you can check the page history to see that it has a good track record of frequent updates. The wiki also lists license and OpenID version compatibility for each entry.
If all else fails, of course, you can roll your own OpenID authentication solution. Perhaps the lowest-level OpenID solution in development is mod_auth_openid, which adds OpenID authentication directly into Apache itself. It requires SQLite and the external libopkele OpenID function libraries, but you can configure it directly in httpd.conf, including whether or not to store OpenID session information in cookies, as well as optional whitelisted and blacklisted OpenID providers.
Missing pieces
Despite all of the open source packages listed above, there are still several high-profile CMSes and web frameworks with no active OpenID support whatsoever.
Joomla, for example, has neither native support nor an actively developed OpenID extension. The last attempt was “unpublished” with the release of Joomla 1.5 due to API incompatibility.
Bug tracking and software development is also particularly under-served, with Trac alone providing a live OpenID option. The market-leading bugtracker Bugzilla has no OpenID support and none on the horizon. Canonical’s Launchpad — which in its public hosting role serves as an OpenID identity provider — cannot accept OpenID authentication as a consumer.
But why dwell on the negatives? With all the OpenID-supporting options out there, a great many projects already support the open standard, and adding to that can only increase the motivation factor for the projects left out in the cold to join in the fun. Of course, accepting OpenID logins is only one half of the equation. If you run a site of your own, you may want to consider setting up your server as an OpenID identity provider — but that’s another weekend.
