Small pieces loosely joined is one of the defining paradigms of the web and in many cases we recommend investing in two or three smaller websites rather than a single big one. Smaller sites are cheaper to build and maintain and by keeping sites independent you give yourself maximum flexibility for future decisions.

A big piece that has been missing in making loosely coupled sites work well is a solution for scattered identities. Imagine the following scenario. In a set of five independent websites you would like to have users sign in once and be able to access any of these sites. Further you would like to have a central location where you can see user activity on all of the five sites. And of course you’d like to allow users to update information like their email address centrally and have the next notification from any of the five sites go to the new address.

This is exactly the challenge that one of our clients — Sandusky Register — faced with several loosely joined Drupal sites. After a survey of available single sign-on solutions, we decided to go with an OpenID based approach since we needed to support different domains, wanted to avoid sharing user tables and did not want to add complex system requirements for browser clients or the server.

Making using OpenID really simple

The great advantage of this scenario is that we know which five sites need to play nicely together and all of them are Drupal sites under the client’s control. This premise allows us to add an additional site as a designated OpenID provider that we call “Hub” and make all five sites point to the Hub as their default identity provider. The resulting user experience is somewhat similar to what we are used to from Google or Yahoo. When users click ‘sign up’ on a site, they are kicked over to the Hub to authenticate and then transferred back and automatically logged in to the original site. Check out the screencast:

A demo of OpenID simple sign-on can be downloaded from github in the form of two Drupal install profiles. (UPDATE: Newer code is on github at two URLs here and here.) The two modules that are at the core of the simple sign-on experience are OpenID SSO and OpenID Provider SSO. If you take a quick look at the source, you will see that they are quite simple — both modules simplify only slightly the behavior of the OpenID and OpenID Provider module (props to walkah for both modules at this point!).

Synchronizing user accounts

A very prominent problem when federating user accounts is managing changing account properties. The simplest example is changing a user’s email address. In this demo, we synchronize user accounts with the help of a PubSubHubbub based publish/subscribe mechanism. Every time a user creates an account on a site an automatic subscription is issued to the Hub and any future changes to a user account on the Hub are syndicated to subscribers via PubSubHubbub. We use a light ping approach and message authentication to protect user information. The modules involved in account synchronization are:

• PuSH Hub — a simple on-board PubsubHubbub hub
• Feeds — handles PubSubHubbub subscriptions
• PuSH User — issues notifications via PuSH hub when account properties change, provides a feed describing a user account.
• Sync User — the counter part of PuSH User on the receiving side.
• Drupal Queue — for delayed updates in case of network problems
• KeyAuth — for message authentication

Some of these modules are linked to their copy in the demo profile. As we mature this stack, some of these modules will go into their own github repositories in our Development Seed account and finally to Drupal.org.

Bundling user activity

This feature smoothes out the user experience by providing a single space where a user’s activity across all sites can be seen. In this demo we used the Views RSS, Feeds and Data modules to aggregate user activity on the hub.

Looking around

The demo presented here is certainly not the final chapter in building consistent user experiences across site properties, and even this approach still requires some refinements. There is much movement in federating user identities these days. Recently Twitter launched an OAuth based ‘sign-in with Twitter’, OpenID itself is pushing for simplifying the user experience, and protocols like Activity Streams or Salmon are gaining more prominence with their inclusion in the Google Buzz API canon. Within the Drupal community, Hugo Wetterberg’s OAuth Login Provider is probably one of the upcoming modules I am most excited about. The field is vast. I’d love to hear about other technologies that you feel are worth mentioning in this context!