inicio mail me! sindicaci;ón

OpenID in RailsCollab

· Filed under Projects

As mentioned in my Cloning ActiveCollab post, i managed to make a reasonably good clone of ActiveCollab using the Ruby on Rails framework.

Recently after watching the rather interesting Google TechTalk on The implications of OpenID, i decided to see if i could add OpenID support to RailsCollab.

OpenID Logo

OpenID is a pretty nifty decentralised single sign-on system. The process of verifying a user’s identity is essentially outsourced to an OpenID identity provider, instead of being left to web developer’s to implement it themselves (and consequently doing a very poor job of it). As a user, i host my identity on any of the numerous OpenID identity providers, preferably one which i can trust. Or if i’m really paranoid, i can just make my own OpenID identity provider.

In relation to RailsCollab, it makes sense to have support for OpenID as a key feature is the ability for client’s to log-on to review progress on a project.

Without OpenID, you’d have to give each of your client’s a username and password, the latter of which you can almost guarantee that someone will forget. And then you need to muck about with setting up an email server so you can send out “Password reset” email’s, unless you want to do it all yourself each time you need to reset it.

With OpenID, you’d just have to give each of your client’s a username and an associated OpenID. There’s no need to much about with password’s, as you’ve outsourced that burden to the OpenID provider. All they need to do to login is type in their OpenID, and their OpenID provider will handle the sign-on process.

Obligatory Screenshot

For anyone crazy enough to actually try RailsCollab with OpenID, you can grab a copy from the Subversion repository on RailsForge. Details are available on the project page.

Posted on August 11, 2007

  • Actually, you don't even need to give them a username. Their OpenID can become the "username identifier". Most OpenID oriented consumers do this. Jyte, Pibb, Zooomr, Ma.gnolia, etc.

    Now, there is a "best practices" recommendation where you should allow any given "user" (in terms of one person) the ability to link multiple OpenIDs, or set a plain 'ole username and password, in case their OpenID Identity Provider is down.

    I personally would rather go with additional factor authentication. Simple (private'ish) profile questions that only come into play when a provider does not resolve.

    That's just me, though.
  • Jason,

    I partly followed the "best practices" concept and just made each user have an OpenID field which is checked against when logging in via OpenID.

    Although i didn't go so far as to allow them to have multiple OpenID's, as considering they could still login with a regular username + password it seemed a bit silly.

    IMO, if one wants to use multiple OpenID providers with a single app, they should just setup their own OpenID page which links to any one of the various providers they want to use.

    Regards,

    James
  • Awesome to hear that you've added support!

    You should also take a look at OAuth... "OpenID for APIs" in a sense... or a kind of generalized FlickrAuth. We've been building this out for the last several months to solve problems that both Ma.gnolia and Twitter have had in either getting OpenID to work on the desktop side (Ma.gnolia Dashboard Widget support for OpenID) or on the API side (Twitter's various mashups that ask for your Twitter username and password).

    Basecamp currently exposes a limitation of OpenID in that it assigns you a username and password to access your protected RSS feeds... instead, Basecamp should grant external applications a token that allows for user-controlled access to their data. OAuth provides the protocol to solve that exact problem.

    http://groups.google.com/group/oauth
blog comments powered by Disqus