I'm just looking for different opinions. Do you consider OpenID a good "Single Sign On" solution?
The way it works seems to be a little bit confusing for an average user and there could be problems related to "putting all your eggs in the same basket".
Anyway, have anyone tried to implement his own OpenId solution within the context of an Intranet where there are many different applications (Wordpress, Elgg, Media Wiki, ..)??
I consider it could be a great solution to solve the "Digital Identity" problem but I don't know if it will work with the "login once and surf the Intranet" problem.
Opinions?
Actually, in the case of StackOverflow, a separate account would have saved me a lot of trouble. I decided to use my WordPress.com OpenID, since that's where I'm hosting my blog, but it turned out that WordPress.com have serious problems with their OpenID service, and most of the time I am not able to log on to StackOverflow at all. Of course, I can use a different OpenID provider to log on with, but then I will have a different identity on the site.
I guess you could say WordPress.com is to blame for this, but the problem reimains the same. By using OpenID you are depending on another site's service to function. Any problems on the third party's site will in effect also disable your site.
As an alternative solution i tried signing in with my Yahoo OpenID, but then I got some random string as the user name, and as DrPizza already pointed out, I would have to edit my personal details anyway.
OpenID is a nice idea, but it's still not something I would rely on with the current state of things.
At least in the intranet scenario, I think Active Directory (or similar) is still one of the best options.
There is one tiny problem with OpenID.
Seamlessly logging in with OpenID requires automatic (unverified) redirection between domains.
That makes the OpenID server a 3rd party. This can cause cookies for the OpenID server to be rejected if you turn off 3rd party cookies and your browser strictly follows the Unverifiable Transactions rule in 3.3.6 of RFC2965.
An example of this is Opera. If you turn off 3rd party cookies (by setting the global to "Accept only cookies from the site I visit"), you can't log in with OpenID because the server script you submit to automatically (without your interaction to approve it) redirects you to the OpenID server and the OpenID server does the same to get you back.
But, you get lucky in Firefox, IE and Safari with their corresponding blocking of 3rd party cookies because they violate RFC2965 in multiple situations.
Having to use OpenID in this case does a disservice to more compliant clients.
As a workaround, in Opera, besides accepting all cookeis, you can goto tools -> preferences -> advanced -> Network and turn off Automatic Redirection. Then, you'll be able to verify and click each link you're redirected to and the cookies won't be rejected because the transactions are verified.
It should also work if you keep Automatic Redirection on and both servers generate a page with a link for you to click on so you can verify the transaction. But, there can't be any automatic redirects anywhere.
Logging in with just a username and password where you're only dealing with first party cookies would be much better in this case.
OpenID is still cool though and I guess Opera just needs an option to allow unverifiable transactions between SO and your OpenID server so that you can use "Accept only cookies from the site I visit" here.
Yep, in any case, Active Directory is behind the curtains of the OpenId Server Provider.
In order to develop a SSO solution within an Intranet there are commercial options such as Access Manager (former IChain)+Active Directory but I dont know if theres an open solution apart from "Own OpenId Server"+"Something cool yet to develop"+LDAP.
OpenID implementations require a lot of effort and thought to be successful, and even then, you can be thwarted by bad identity providers (for example Yahoo). OpenID can work very well if you've worked out the user experience issues, but a bad implementation is just horribly difficult for most users to work out. In my opinion, the biggest problem with OpenID is that people tried to solve the issue with user awareness. They would have been better off simply giving a list of OpenID providers, and having the users click the one they wanted to use. This sometimes requires knowledge of how a provider has implemented OpenID if they don't support version 2.0 of the spec, but gives a much better overall experience for the end user.
I have to say that I absolutely agree with the statements on it being too difficult for the "average" Internet user. I think that OpenID could still be considered "new", even though the original proposal was back in 2005. More high traffic sites are taking it up as just an option for creating an account, rather than requiring users to have an OpenID present.
In my opinion, as long as normal username/password account creation is offered alongside OpenID, average Internet users will naturally begin to try and eventually stick with using OpenID.
The authentication issues apply just as much to OpenID as registering on any website. You put your trust in the website with your password (assuming you do not use a password storage program) so that shouldn't be used against OpenID.
All that aside, the standardization of account creation is absolutely cream gravy to a web developer. I'd just love to not even have to worry about the normal creation process, and rather just drop in an OpenID library and reference it to the database.