Why the lack of OpenID-enabled Rails apps?

OpenID has been quickly gaining momentum this year, with Microsoft’s future role as an identity provider, and AOL’s sudden, wonderful announcement that all 60+ million AOL/AIM users now have an identity provider.

But where are the OpenID-enabled web applications to log into? What we have so far is nice, but it’s not the kind of riches we’re seeing on the provider side of the OpenID equation.

With Rails being the platform of choice for many new & emerging web sites, you’d expect to see OpenID support here first. So really the question is — Why don’t we see more Rails apps with OpenID support?

  • Most OpenID-enabled sites still need to support password authentication. There are some good choices today for creating a new Rails app that only supports OpenID login (the ruby-openid gem’s generator is good for that), but it’ll be some time before all users are comfortable with OpenID. So sites need to be able to add OpenID support alongside password login — and that’s a non-trivial challenge today (see bookmarks for one example, but it’s not yet solid).
  • Competing authentication plug-ins. For OpenID, there are two major competing plugins: JanRain’s generator that is included in the ruby-openid gem, and Eastmedia’s generator (used in the bookmarks example). And to combine with password authentication, there’s a more confusing jumble of choices. If you’re running Rails 1.2, restful_authentication is currently the strongest choice for password login because of its cleanliness, tests, and feature support for remembered logins (cookies) and optional email activation, etc (<1.2, acts_as_authenticated is strongest). And on the OpenID side, Eastmedia's generator is better configured to mashup with other login systems, but it still requires a substantial amount of customization, and it suffers from lack of tests and some out of sync code.
  • The right user interface hasn’t been settled on. Should we present password & openid login on the same page? A set of choices with fancy UI (tabs)? Should account creation be automatic for OpenID? Should OpenID SRE nickname and email be assumed to be configured?
  • The right internal structure involves some difficult tradeoffs. Just at the top level — should different authentication methods all store their data in a unified user model? Should the application’s login and OpenID’s nickname be treated as equivalent? If so, how to handle uniqueness? etc. etc.
  • Disagreements on the wisdom of drop-in authentication. The best hope for making this all more approachable is better plugin support, including authentication plugins that play well together so a single application can support multiple authentication mechanisms. But there has been some disagreement among the community — some would argue that authentication of this type is too tied to unique aspects of the application and too important from a security point of view to be realistic as a dynamic plugin or works-out-of-the-box generator. But without out-of-the-box ease (like what aaa or restful_authentication provides for password authentication), combined OpenID+password authentication will trail in adoption.
  • In short, the killer OpenID plugin has yet to be written. For an excellent spec for what is needed and an incomplete implementation, see Hark.

OpenID is poised to take off. Support from an army of up-and-coming Rails sites could be the turning point.

Are there other tools that make this more approachable for Rails developers?

Microsoft: Windows-OpenID interoperability

Working at Microsoft, it was frustrating to see “not invented here” and “we have to own it” attitudes often dominate when it came to interoperability and standards. Not only did this cause immediate harm to the consumer, but it was also self-defeating — it has unavoidably done great damage to Microsoft’s long-term position in the industry. Hopefully this will change, and is changing.

At the RSA Conference today, BillG made a keynote announcement that future versions of Windows Identity solutions will interoperate with OpenID. Work on the details is just beginning now.

A key part of Microsoft’s identity solutions is the new CardSpace (previously called InfoCard), which is included within Windows Vista, and is available as an optional add-on for both Windows XP SP2 and Windows 2003 Server SP1 (tied to the .NET 3.0 runtime). CardSpace provides software for the user, and a set of APIs for web servers and services, which helps users manage and take control of their identity and and desired level of privacy for those services. Once OpenID is working with CardSpace, you could think of it as just another OpenID provider with some advanced identity management and authentication features.

This is still ultimately an “embrace and extend” strategy for Microsoft. But that is much healthier for everyone than no interoperability at all. OpenID will gain support on the majority platform, and a useful new authentication service (CardSpace) for those users. And Microsoft gains a feature that actually works with the rest of the ecosystem to keep people on Windows. And it’s optional in both directions — CardSpace does not need OpenID to work, and OpenID will continue to work with many other providers, on the Windows platform or not.

Good news.

Read more at Scott Kveton’s blog (CEO of JanRain)

JanRain will never require users of our libraries or services to use Windows CardSpace ™. We offer support for this technology as another option for users much like using our Safe SignIn and Personal Icon technologies on MyOpenID.com. We’ll also continue to support the OpenID efforts going on with Mozilla and Firefox.

And the announcement and news from Kim Cameron at Microsoft.

For us, its clear that OpenID is a really great technology for doing public identities – the simplicity is stunning. I really like your work. OpenID is clearly an important part of the identity metasystem. We really hope to see the synergy keep expanding.

Priorities for adding OpenID support

Eventually, nearly all web apps will likely support OpenID in some form. But — here in the early days — what web applications are most in need of OpenID?

Apps where identity is important — you want to track several pieces of data back to a known identity, or allow an identity to come back and update their own data. Combine that with web apps where many users contribute, but might only come back irregularly, and you have the sweet spot. Prime examples would be wikis, forums, and blogs.

I had an interesting Skype-to-Europe call with Frank, who is working on some OpenID stuff for Mephisto, about how this relates to that project.

Blogs have two distinct sets of users: the blog owners, and those posting comments. Mephisto does not have a single, unified “user” to manage both. Blog owners log in to post and administer the blog, while comments just store the name, email, and ip of the commenter directly in the comment table — there is no login per-se.

So there’s a bit of a mismatch right now: Mephisto doesn’t really have the architecture in place (e.g. login for submitting comments) where OpenID support would be most useful. This leads to things like Justin’s OpenID consumer plug-in port to mephisto — it calls the OpenID libraries, but then mearly dumps the user’s email & name (from SRE) into the comment. You can’t re-login and go back to find and modify one of your prior comments, because Mephisto isn’t really using OpenID to know it’s “you” yet. So it only saves you some typing, and not much at that.

But adding OpenID support for admin login, while nice, wouldn’t be where the greatest need is.

This creates an issue for the upcoming screencast, since it needs to focus on OpenID without getting into more complex distractions (like fleshing out new blog comment functionality). That, and also Mephisto’s authors are trying to avoid adding any complexity to the trunk right now. The focus is on stabilizing, since you pretty much need to be on trunk to have it work out of the box (0.7.3 is getting quite old, and doesn’t work without some small updates from trunk). Mephisto needs some more time to bake before adding OpenID will be completely smooth.

What all this adds up to, is Mephisto is not a good match for the screencast. But I’ve got a set of smaller Rails-based app or app porting ideas which would. Hopefully they’ll be both interesting on their own, and very clear examples of Rails implementations where OpenID is most useful.

Latest news on Mephisto and OpenID

Mephisto is still developing, but seems to be coming into its own as a blog engine of choice for Rails.

Since Mephisto does not yet have OpenID support in its trunk, this seemed like a good project as the running example for my peepcode screencast on OpenID.

There is some very active ongoing work, though, that if I go forward with Mephisto I will certainly build on. Here’s the latest I know of.

First, is Justin at transphorm’s Mephisto port of the OpenID Consumer plug-in for Rails. Normally, outside of Mephisto, the OpenID Consumer plug-in could be be used in conjunction with a authentication generator like ActsAsAuthenticated. Justin’s port is nearly fully baked, but does require hand editing several significant areas.

Second is Frank’s work at nullsense, which builds on Justin’s port and works to turn it into a full Mephisto plugin. This work isn’t yet released (and, when it is, may require some changes in Mephisto trunk), but it looks like a full Mephisto plug-in for OpenID is imminent.

For myself, where I want to show adding OpenID to Rails from the ground up, this raises some question of doing the screencast with Mephisto or with a project where there is no existing OpenID activity that i know of.

Also, if Mephisto remains the direction, there’s the question of whether OpenID should be a standard feature in Mephisto trunk, or kept separate as a plug-in.

If anyone has thoughts, let me know!

OpenID, Rails, and Peepcode

OpenID LogoOpenID is an exciting, up-and-coming technology which will make website registration and login simpler (Finally! Fewer passwords to remember!)

I’m hopeful that, over the next year, you’ll see a flood of web apps add support for it.

But today there are only a few dozen web apps that have that support. Support in web frameworks like Ruby on Rails is here or coming soon, but word hasn’t reached the masses yet.

To play some small part in filling that need, I’ll be helping to create a screencast which walks the viewer through adding support for OpenID to an existing Rails app. As this work is done, I’ll post here with some of the information and questions that come up, along with a little on the general process of creating a screencast. Subscribe if you’re interesting in reading this series of posts, and you can also see some of the resources I use at my openid tagged pages (del.icio.us).

The screencast will be posted on peepcode.com, Geoffrey Grossenbach’s repository of professional, high-value screencasts on a specific topics. I’ve admired Geoffrey’s work and various projects for a long time, and am looking forward to working on one of his efforts.

Please let me know if you have any feedback — a question or topic you’d like covered, for example.

Here’s the tentative topics:

5m Getting an OpenID for ourselves
10m Installing the Mephisto Rails-based blog engine
5m Plugging an OpenID login into Rails
10m Creating our OpenID-unique tests
10m Analyzing and migrating our models
10m Merging our views and controller logic
5m The final product

Here are some examples of the early questions I need to answer:

  • How much should I summarize topics already hit by Simon’s introductory screencast for non-technical OpenID users?
  • For the example project, add OpenID support to Mephisto (blog) or Junebug (wiki)?
  • Will I need any major dependencies beyond ruby-openid (and its login generator)?
  • Will there be time in the screencast (targeted at 40 mins) to make a standard plug-in?
  • What are the top 3-5 gotchas that cause people to loose time when embarking on OpenID themselves?