views:

152

answers:

4

I wrote an application recently, which relies on OpenID for authentication. A lot of web applications these days are moving to OpenID, insofar that they already have userid/password authentication scheme, and OpenID is just an add-on. Since my application is a new one, I decided that it makes no sense to program separate authentication mechanism based on userid/password, when I can rely on OpenID for all the authentication altogether.

But sure as hell, once I presented the application to a customer, she asked "well, how do we create user accounts, and reset their passwords"? Conceptually, she didn't want to make the users create their own OpenID if they don't already have one.

I kind-of had a pre-made response to that, which was: "You can always run your own OpenID server". I guess I didn't put too much thought into this answer though, since many implementations of OpenID server are pretty raw and need a lot of work before they could be run in production.

So, my question is: does anyone here have an experience of running private OpenID server purely for authenticating of her own users. Here are the features I'm looking for it to support out of the box:

  • Ability to bulk-load user accounts
  • Self-served password resets through verification email
  • Administrative features (lock/unlock/disable accounts, troubleshoot, etc)
  • Presentable look
+2  A: 

This doesn't directly answer their question, but how many folks are on the internet and don't have an account with Yahoo, Flickr, AIM, WordPress, Myspace, Google, or MSN? They're all OpenID providers.

I'd argue that for the tiny % of the 'net population who uses none of those services, just point them to Vidoop or MyOpenID and let them get an account with someone who already has a secure infrastructure.

ahockley
Irrelevant. What percentage of the net population KNOWS they have an OpenID account at yahoo, flickr, aim, wordpress, etc? You have opt-in to OpenID at Yahoo. This is not as transparent as you imply.
jmucchiello
Using an OpenID implementation such as RPX makes it easy for folks to log in. To mangle an old metaphor, I'd argue that teaching them to fish (and that they have an OpenID) is better than just giving them another one-site username/password.
ahockley
+1  A: 

This was my thought initially... But the application is for non-internet-geek type of users, so the expectation is that they may or may not have any of above mentioned accounts.

Another thing is: MyOpenID gives a neat, nice URL for you, when Yahoo (for example) doesn't. Even if you know that a person has a yahoo account, you can't just use username.yahoo.com. Google is same thing - you must first use your google account to activate a blogspot account, and then you have an OpenID, which may or many not correlate to your gogle id. So, if you have a list of users and even if you know they are all on google or yahoo - even then you can't make assumptions about their OpenID url

galets
A: 

I'm using OpenID in my own applications but if I was to go to a customer and they raised the issue about having the passwords and stuff, I'd probably just tell them that the providers would handle that for them. If they didn't like that idea, I'd charge them the extra hours that it would take to setup the membership system. That way you get to charge more and you have a happy customer. I don't think the general public will grok OpenId for some years to come.

rball
A: 

there are ready to use frameworks. you only need to put them together. this can be fast done.

you didn't wrote about your platform, but if you like to use php then a look at "zend framework" or "php openid"

Bernd Ott