Development Seed

Blog

Simple Sign-On with OpenID

Create a single sign-on experience based on Drupal's OpenID stack

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.

Look at what sign-on looks like

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. 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!

Open Atrium as Hub

Is there any reason that we could/should not use Open Atrium as the hub in a setup like this? We would really like to preserve the ‘Add user’ feature of OA while still allowing for a single synchronized account across several sites.

That’s in fact possible and

That’s in fact possible and we’re working on using OA as a hub, we will release the code soon.

What’s not possible is using OA as a relying party as OA allows non-admins to create users which breaks the OSSO model described here that assumes all users being created first on the hub.

Thats great! However I am

Thats great! However I am really trying to find a way to login using a google apps account and trying to lock in to only one google apps account and I am finding it very difficult perhaps I need to understand the OpenID and how its a bit different from Federated Login for Google Apps.

The approach presented here

The approach presented here is completely hermetic. So you cannot use another OpenID Provider for SSO than the SSO enabled Drupal provider described here.

You may be looking for a service like RPX by JanRain.

user registration/login

Hello, I just discovered MN and taking it for a ride on a live site. I have quite a number of questions, first of which is how can I let users register since I cannot find any register/login block on the front page of the site.

Then too I am wondering if it runs on Drupal, can I just install and use my modules as I would with Drupal?

T

For login use the icon with

For login use the icon with the head on the bottom right: http://skitch.com/alexbarth/n44gx/home-managing-news

Then too I am wondering if it runs on Drupal, can I just install and use my modules as I would with Drupal?

Yes. Managing News is just an install profile that's built on Drupal.

What about third party auth like facebook, and twitter?

Would this stuff work with facebook, and twitter auth?

For example, lets say on hub you setup twitter signin, and facebook login. And then on the client site you wanted users to be able to “post to twitter”, and “post to facebook”, would the push stuff also sync up that extra user data.

Right now you couldn’t hook

Right now you couldn’t hook up this stack as-is to Facebook, Twitter or Google. But with pieces of it, you could.

On this note, I’d love to see more and more of the involved technologies go towards established standards (e. g. replace the KeyAuth based message authentication with OAuth). This would make it again easier to talk to existing authentication services.

BTW, you may be interested in Stella’s post on authentication methods used by Google: http://civicactions.com/blog/2010/mar/02/overview_google_authentication_...

Is the theme that’s shown in

Is the theme that’s shown in the video somewhere available for download? It looks very good and polished. Thanks for the video, it was educational.

The theme is available on

The theme is available on github: http://github.com/lxbarth/hubnet

Or if you are willing to share tables

If you are willing to share tables that big stack of modules that could more easily be done with one of the many single sign on modules (bakery, multisite login, single sign-on, etc.) + some table sharing.

BTW http://www.sanduskyregister.com/ gives me nothing but: Could not connect: Too many connections

Sharing user tables

Dalin -

We specifically wanted to avoid sharing any tables for better flexibility in deployment, but we also wanted to avoid a mechanism to exchange cookies.

For security considerations, we wanted to rely on an industry standard to do the heavy lifting when it comes to authentication.

As a larger goal behind this work is a platform independent SSO approach. Granted, this is not where the demo is at this point, but it is the direction we are heading.

Sandusky Register seems to be up again. On that note, Sandusky hasn't deployed any of the above technology yet.

wonderful

another gift from the dev seed master craftsman. thanks so much.

one remnaining UX gotcha is imprving the experience when you land on a new Relying Party site like blog and you are already logged into The Hub, Do you silently log the user into The Blog in this case? What if the user has never been to the The Blog before? Does that matter?

Thanks Moshe, In a first

Thanks Moshe,

In a first iteration, we’ve silently logged in users into relying parties. This is entirely possible as in an SSO scenario we can assume that a user is fine with having an account on all site properties of the trusted web when acquiring one account.

A silent log in would be logging in a user on a Relying Party (The Blog) only by click of a “sign in/sign up” button on that Relying Party or directly via a Javascript triggered action on page load. In both cases a user would be logged in directly into a site without interacting with the Hub at all. Of course, there would be a redirect from the Relying Party to the Hub and back involved but it wouldn’t be noticeable to the user.

We found that silent log ins may work for some cases, but in scenarios where the interconnection between web properties is not as clear as the sun it’s preferable to have the user involved. Therefore we opted for a user confirmation before every log in action. This confirmation is using the OpenID standard, by the way.