• OpenID Provider - Specific user roles can be given the capability of using the built-in OpenID provider, turning their author posts URL into a valid OpenID which can be used to login to other sites. This includes support for OpenID 1.0 and 2.0 as well as Simple Registration 1.0, with hooks to add other OpenID extensions.
• OpenID Delegation - Users authorized to use the built-in provider can optionally choose to delegate their OpenID to another provider instead.
• EAUT Mapper - Support for the draft Email Address to URL Transformation protocol. If you use an email address at the domain of your WordPress blog, you can now use use that email address to login wherever EAUT is supported.
• Extensibility - the plugin now has a number of public functions and hooks that other plugins can use to integrate with or extend the OpenID plugin. These are all documented here.

It’s worth mentioning that pretty much all of the new features require that you also have the XRDS-Simple plugin installed. There are also a number of other changes in regards to simplifying and stabilizing the plugin, than can be read about here.

• Don’t use OpenID at all
• Use the local OpenID provider built in to the plugin
• Delegate to another OpenID

If a the local OpenID provider is used, it also supports transmitting sreg attributes pulled from the user’s WordPress profile and the DiSo Profiles plugin, if it’s installed. The user can update this data before releasing it to the relying party, but those changes aren’t currently stored. In addition, trust decisions are recorded and stored for the user, and can be modified from their config page at any time.

If a user chooses to delegate to another OpenID, they need only provide the delegate OpenID itself. All server configuration and supported extensions from that provider are discovered and published in the local XRDS document. Of course this data will have to be cached and probably updated on some interval, but it makes setting up delegation a breeze.

Server Modes

Remember that every user’s OpenID is their author posts URL. So what about the home URL for the blog itself? Well, the OpenID server can operate in two basic modes: multi-user and blog-owner… perhaps not the best names, but they’ll work for now.

In multi-user, the default configuration, the server supports a feature in OpenID 2.0 called OpenID Provider driven identifier selection. What this means is that ANY user on that blog can enter the home URL as their OpenID, and the OpenID provider itself will make sure that the correct identifier is returned to the relying party. The final identifier will still be something like http://example.com/author/admin/, but the user only needs to enter example.com at a relying party. If you’ve used ever used Yahoo’s OpenID provider, then you’ve probably seen how this works.

I suspect the more common mode will be blog-owner, which is appropriate for personal blogs. Even if there are multiple users in the system, the blog is basically owned by one individual and it makes sense for that individual to use the blog home URL as their OpenID. This mode is activated by selecting a “Blog Owner” on the main plugin configuration page. Once set, this user’s personal OpenID configuration (whether turned off, using the local provider, or delegated to another OpenID) will be used at the blog home URL. Other user’s on the blog could still use their OpenIDs, but they would need to type in the full URL each time… they just lose the convenience of being able to use the blog home URL.

For security, once a blog owner is set, no other user can update the setting. The blog owner can set someone else as the new blog owner (a push mechanism), but no-one can take ownership away (a pull mechanism). Additionally, if a multi-user blog wants to ensure no-one is ever set as the blog owner, they can add the following to their wp-config.php file:

define("OPENID_DISALLOW_OWNER", 1);

What’s left to do

The main outstanding work to be done before release is the user interface. You’ll notice that the user’s configuration screen (where they manage their external OpenIDs, OpenID Provider preference, and Trusted Sites) is a bit confusing if you’re not to familiar with OpenID. The current layout was done simply for convenience while developing the OpenID Provider, and will be overhauled to some degree before the release.

I’m also not too sure about compatibility with older versions of PHP and WordPress. I’ve been developing using PHP 5.2.6, MySQL 5.0.51, and WordPress 2.6.1. I do intend to remain as backwards compatible on these as possible (within reason), but make no guarantees for the current development code. I’ll also be working to make everything compatible with WordPressMU and BuddyPress. For now, I just wanted to get the code out there, and get people playing with it a little bit.

Simplified Database Structure

Version 1.0 of wp-openid added four new database tables and overloaded one of the comment table fields in a weird way. Version 2.0 required only three of those four tables and added one column to the comment table to eliminate the overloaded field. The current development version doesn’t add any columns or overload fields of existing tables, and adds only one new table of its own, which I’m still hoping to eliminate.

The two removed tables were used to store OpenID associations and nonces, both of which are temporary data necessary to make OpenID security actually work. Instead of using these tables, I’ve opted to use an updated version of the OpenID store used in Simon Willison’s mu-open-id plugin which uses the WordPress options table to store this data. I’ve updated his store to use the latest php-openid APIs as well as to reduce the potential for race conditions.

I’ve removed the column from the comments table that was tracking which comments were left using OpenIDs, and am instead storing this in the postmeta table for the post the comment is associated with. It would certainly be preferable to have a commentmeta table, but I like this better than the previous solution.

The one remaining table is the identity table which tracks the identity URLs of each user. I would like to store this in the usermeta table, but because it requires unique keys there’s just not a real clean way to do this and keep the plugin scalable to support large deployments. If this is fixed in 2.7, we could theoretically eliminate any custom database stuff in the plugin, which I’d absolutely love.

Removed PEAR_LOG

For the time being I’ve removed PEAR_LOG and am simply using error_log() for what logging still remains. The problem is that most people weren’t taking advantage of the logs anyway, so they were just taking up space. I’ll likely look at making use of the WP_DEBUG constant to allow more verbose logging when it’s desired. For now this just simplifies things a bit, and eliminates at least one case of library conflict that was reported.

Code Refactoring

Really? More refactoring? Didn’t I just do a lot of this in the last point release? Well yes, but more was needed… MUCH more. Previously, code was roughly divided based on the MVC (model, view, controller) model into store.php, interface.php, and logic.php, respectively. That worked for a while, but got to be pretty confusing as those individual files became a bit unmanageable. Instead, things are now broken into more logical segments… comments, admin panel, logging in through wp-login.php, etc. This seems to be a lot easier to manage and more importantly, easier to extend.

More Hooks

I haven’t sat down to document them all yet, but I’m adding in more hooks for other plugins to add functionality. Want to pull profile data from FOAF instead of sreg? No problem, now you have a hook you can implement. This makes everything in the plugin much more lightweight and “loosely joined” which is always good. All of the existing non-core OpenID functionality (like SREG) is currently using these hooks.

Bug Fixes

Though I’m not always good about replying, I generally do monitor the conversations on the WordPress support forums. I will try and put together a more exhaustive list of what bugs have been addressed, but I will simply say for now that most of the major bugs people have reported there should be absent from the current development branch.

Here Be Dragons!

Let me say first and foremost, don’t use this on a production blog. I always say that when I blog about unreleased code, but this time it’s much more important. There are major database changes in this version… changes which are non-trivial to reverse. There is a very good chance there will be more database changes before the final release, and there will not be an upgrade path from this development version (there will however be an upgrade path from the last stable version… 2.2.x).

What’s New

For now, I’m just going to have two follow-up posts talking about changes in the coming release. I’m sure I’ll overlook something and may have to add a third post, but for now we’re looking at:

• Making the plugin more stable, extensible, and overall simpler
• OpenID Providing and Delegation

Test it Out

The current plugin can be checked out from the DiSo subversion repository; grab the 3.0 branch . In addition, it requires a special branch of the XRDS-Simple plugin to provide all the XRDS publishing stuff. If you have a previous version of wp-openid installed, you must deactivate and reactivate the plugin for the database changes to be applied. Again, keep in mind that these will be somewhat substantial changes to the OpenID portions of the database, so don’t do this on your production blog just yet. Please direct any support questions to the DiSo Mailing List.

• What is your father’s middle name?
• What is the name of your first pet?

Questions which, if answered truthfully, are incredibly easy to guess with just a modicum of research. But if you make something up, then you’re likely to forget what answer you gave. It is widely agreed that these kinds of questions do not provide any real security, and there are a number of tricks people recommend for creating more secure answers. I have my own solution, so that’s not really the point of this post. This post is about what happened when I logged onto the Delta website today. After logging in with my four digit PIN (no, I’m not kidding… their website only supports four digit passwords), I was prompted to setup security questions for my account. My account which I’ve had since 2001, where I’ve deliberately chosen not to setup the optional security questions. However this time, I was notified that if I don’t setup security questions by September 17th, then I will lose access to my account. Delta has decided to make security questions mandatory now for all of their SkyMiles customers. That wouldn’t be so bad if it weren’t for what happens when you forget your security questions:

What happens if I can’t remember my security questions or answers?
If you forget the answers to the security questions, and you exceed the maximum allowable attempts to answer your security questions, your PIN will be emailed to the address stored in your SkyMiles profile. If you don’t have an email address on file then you can reset your PIN online provided you remember your personal information.

They simply email the PIN to you (in plain text) anyway! I’m not sure what kind of “personal information” you would have to provide if you don’t have an email address on your account, but it can’t be much more than address and phone number.

So I’m left wondering why on earth they are now forcing security questions down their customers’ throats. It would be one thing if they didn’t already have an automated password retrieval process, and this was an effort to cut support costs associated with forgotten passwords, but that’s not the case. It might also be acceptable if they recognized the danger of simply emailing passwords around in plain text, and so enforced this based on the incorrect belief that it’s more secure. But again, that is also not the case. All they’ve managed to do is to provide someone with yet another way to potentially gain unauthorized access to my account. If they really wanted to beef up security, how about allowing for more than a four digit PIN. If you really want to make things more secure, allow me to sign in using my OpenID which supports multi-factor authentication.

Of course I know this is not a unique problem by any means. Delta is not the only, nor the worst, offender. And I’m not really sure why someone would want to break into my Delta account anyway… there’s really nothing in there of any value. I know it was probably some schmuck at Delta with a three letter title and no clue about online security who forced the delta.com team to implement this. I know all this… it’s just really aggravating.

• POST replay for comments - this should fix all the compatibility issues with other comment related plugins like reCaptcha.
• MUCH better memory usage - like no longer needlessly building a 2MB object on every page load!
• support for Email Address to URL Transformation - now you can use an email address anywhere you normally use an OpenID
• fixed OpenID Spoofing vulnerability - users’ profile URLs must match one of their OpenIDs
• using hooks for gathering user data - other plugins can now hook in and gather user info from FOAF, hCard, whatever
• If OpenID authentication fails for whatever reason, the user is given the opportunity to submit their comment without OpenID
• lots of little fixes, code refactoring and cleanup, and a lot of UI tweaks

Download at http://wordpress.org/extend/plugins/openid/.

I tested pretty thoroughly on WordPress 2.2 through 2.6 using PHP5. I’m fairly certain I didn’t break PHP4, but let me know if you find any problems.

With this out the door, I’ll be jumping right into my feature list for the next major release — adding a native OpenID Server and delegation capabilities. At that point, it should be able to handle all of your OpenID related needs.

Posting comments

OpenID is integrated into comment posting by intercepting a comment submission to see if it includes a valid OpenID. If it does, the user is sent to their OpenID provider to authenticate, and upon their return the comment is submitted. Previously, the wp-openid plugin itself performed the comment submission, basically by copying the logic found in wp-comments-post.php. This introduced a number of problems, especially when using any other plugins that modify the comment submission process such as reCaptcha. Violating DRY is bad, but necessary at times. Breaking other plugins is really bad and had to be fixed.

The current solution I’m using is to capture the comment submission POST, do the OpenID dance, and then replay the POST (modified if necessary). If the OpenID dance results in the commenter being authenticated as a valid WordPress user, then the comment POST is modified to look like they were logged in all along. If the OpenID dance results in user attributes (via attribute exchange, sreg, hcard, foaf, whatever), then those values override what was included in the original comment form. If OpenID authentication fails for whatever reason, the idea is to give the user the option to submit the post without OpenID. This part isn’t finish yet, but will be before the release. Currently, if OpenID authentication fails, then the comment is very likely lost unless you use other means to save the comment. And of course, if any other plugins include additional data in the original comment POST, it will be included in the replayed POST.

Still left to do

Because all of the OpenID responses are being sent to /openid_consumer, it’s not quite as simple to display friendly messages to the end user. I’m may try to find a way to display error messages similar to how they look today (for example, login errors are displayed on the wp-login.php page, etc). Otherwise, I’ll just have a somewhat generic error pages that is specific to OpenID errors, and then include links back to whatever the user was doing.

Need Testers

Right now, I’m in need of people to test this new version of the plugin to find any cases I may have overlooked. Like I said, the message display is in need of work, but everything is at least functional as best as I can tell. If you’re interested in testing, checkout a copy of the latest code from the Diso Repository and give it a shot. If you have an older version installed, you will most certainly need to disable it first, then re-enable after installing the new version. Otherwise, WordPress won’t handle the /openid_consumer endpoint properly. If you have any questions or comments, you can leave a comment here or on the Diso Mailing List. As always, I would strongly discourage you from using this on your production WordPress installation (notice I’m not using it here).

I’ve been working in the Identity Management space for a few years now. I started getting involved with the Shibboleth project while at the University of Memphis. After a year and a half, I moved to California and took a job at USC working in their middleware group. I’ve spent the last two years there helping to develop and manage various parts of the Identity Management cloud including the LDAP directories, meta-directory processes, and their Shibboleth environment. In October 2006 I formally joined the core Shibboleth development team, focusing on the Shibboleth 2.0 Identity Provider.

Meanwhile, I have also been toying with OpenID for a couple of years. In early 2007 or so, I sort of took over development of Alan Castonguay’s OpenID plugin for WordPress. I started with a couple of new features, then worked to add support for the latest OpenID protocol, lots of code refactoring, etc. I got to know characters like Chris Messina, Scott Kveton, and a host of others. I continued making updates to the WordPress plugin as I had time, but it never felt like enough. Don’t get me wrong, I certainly enjoyed the work I was doing at USC and with Shibboleth… I just would have liked to have had more time for everything else as well. Every now and then Chris or Scott would prod me about going to work at Google or somewhere to spend more time on OpenID and related technologies, but I wasn’t ready to leave my work at USC.

Late last year, Chris Messina and Steve Ivy announced the DiSo Project, initially based on my updated wp-openid plugin. Within the first week after it was announced, I sat down with Chris and Steve and we decided it would be best to officially move the wp-openid plugin under the DiSo umbrella to allow for tighter integration with the other planned work. Then a lot happened this last February in the social networking space — Google announced the Social Graph API and SGFoo really got people talking more about enriching the OpenID endpoint (among other things). Things were beginning to move pretty fast, and I felt like if I didn’t jump in now then I’d end up watching all the great new developments from the sidelines. I spent the next few months interviewing with a number of companies active in this space and made a couple of trips to San Francisco to talk with them in person.

In the end, a dinner conversation with Luke Sontag had me sold. I was quite familiar with Vidoop and their OpenID provider, knew they had a great development team, but had always been a little skeptical of the company. After Luke gave me a better picture of their overall vision and where technologies like DiSo fit into that picture, I knew that these guys really “get it”. They understand the importance of what DiSo is trying to do, and more importantly they are willing to do their part in making it a reality. I love Vidoop’s OpenID implementation and have been using it since before I took this job, but that’s not why I did. I took the job because the team at Vidoop know their shit, they know the kinds of problems we’re up against, and they are ready to take a shot at developing some real solutions. Well that and I really can’t wait to get started working with Chris a lot more. :)

Compare this to other times I call in to various companies, go ahead and enter my account number at the automated prompt, only to be asked for the exact same information all over again when I actually get to an operator. What’s wrong with these people?!

(Though I still have my share of complaints with them in other areas…) Just another thing I <3 about Bank of America.

Testers should be able to leave an authenticated comment on this page using any OpenID 1.1 or 2.0 provider. We are aware of a bug that prevents interop with Vox OpenIDs in certain cases. Please do limit OSIS testing to this blog post. If you run into trouble, you can contact me directly, or the DiSo Project List. Happy testing! :)