OpenID - Open Source Single-SignOn

Nurgled writes "Danga Interactive, who created LiveJournal and memcached, is working on a new decentralized single-signon system called OpenID. Similar in principle to Six Apart's TypeKey or MSN Passport, OpenID will allow you to assert a single identity to any OpenID-supporting site. The difference here is that there is no central authenticating server: anyone can run one, and Danga's reference implementations will be open-source. The site you are authenticating with never sees your username or password, just a one-time token. You can read the initial announcement on LiveJournal, though some details have changed since that post, so be sure to read the information on the official site."

Wrong category?

[Anonymous Coward]

Why is this in Hardware? Shouldn't it be... IT?

Cool

[Anonymous Coward]

Now if my bank, my broker, and my webmail all did this I would be one happy person. But this sounds like this would do the same thing as stored numbers on the phone did to me I forgot almost everyones number.

will this work?

[millahtime]

so, if it's open it's good but if it's M$ it's evil with regards to single sign-on? Aren't there a lot of other considerations with regard to security and single sign-on. Such as one login gets you into banck accounts, and pretty much everything else.

If you really want this use something liek keychain (on a mac) but in general one password to control them all isn't such a good idea.

NEEDED

[Anonymous Coward]

I am not disputing the value of anonymity, but ID services that are open and free are need. Otherwise these services will gravitate towards Yahoo, Google, MSN etc. Make you choice, free or them.

Re:Certain Information

[alecks]

So if I ran one, would I have everyones authentication information?

No. Just a token. SHeesh.. i didn't even RTFA

Re:Certain Information

[sydney094]

The decentralized nature of this is the problem. It is impossible to securely authenticate a person using an untrusted server.

If you ran one, you'd have only your authentication information stored on your server. Then, to authenticate to a remote server, you'd point that server to your server. The remote server would ask your server who you are, and then authenticate you (log you in). The biggest thing is that the remote server has to trust that what your server tells it is correct.

This may have a place in the blog world, where you're mainly looking for an easy way to keep your user profile the same across many blogs, but certainly not anywhere where you'd have sensitive data.

Another point, this is supposed to be authentication and not authorization. But actually, this isn't really authentication either... The difference between the two is really the question the server is asking. In authentication, the question is "are you who you say you are?". In authorization the question is "do I have the rights to perform a task?". With OpenID, the question is "who are you?". There is no verification to see if you are who you say you are (from the remote server's perspective, since there is no trust between servers), so you aren't actually authenticated.

It would be up to your server to determine what rights an open-id authenticated user would have.

Re:Certain Information

[Nytewynd]

You could still use cookies based on the sign on. Instead of getting the sign-on data from the user typing it, you would be getting it from the token and perhaps looking it up on the backend. It makes it easier for the user, and is about the same amount of programming for you. You can still set and delete cookies accordingly.

Decentralized servers are no less secure than if you had a database table of your user authentication information for your application. With SSO, you actually don't need to know the password since it has already been handled. All you need back is the user ID and that they have been authenticated. If you choose to set one of these servers up, it isn't like people are going to start using your server to store their Online Banking information. They will be using your server only to access sites that you run.

On the flip side, if you choose to latch onto someone else's server for authentication, all you will be doing is specifying that you allow anyone authenticated by that server to access your site. You wouldn't even have as much knowledge of those users as you would if you ran your own security.

For the most part SSO is only really usefull within a small environment. Very rarely do I see a need to allow people to access more than one application with the same sign on. Something like passport is nice for the general user, but why would I want the overhead of something like that for my own applications? I'd rather have more control over things. That sort of makes this new product interesting to me, but on the other hand, most of my applications have distinct user sets anyway.

Re:Hosting Servers

[Turn-X Alphonse]

you forget something.

Slashdot maybe large but live journal's user base (myself included) is also very large. Most of them are idiots (AKA teen girls) so they would instantly start using it and think it was a great idea to only need to sign onto one site ever.

If "average whiney girl mark 3" thinks it's a good idea she will tell her friends and it'll spread like wild fire through the mass market. The geeks can't control this only choose if we listen to the cries or get snowed under with them if this happens.

Why not just use SAML?

[ProgressiveCynic]

This problem is best solved using standards, not by supplying a new software platform. SAML, Shibboleth, and Liberty have all been around quite a while, fill this need quite nicely and a number of different implementations of each protocol exist, including FOSS and commercial options. Features like pseudonyms and selective information sharing are already there. Why do we need another way to do this?

distributed != decentralized

[PureFiction]

Yadis is correctly described as distributed single sign on, not decentralized single sign on. Everyone still has their dedicated central identity server, it's just that requests from other sites can be delegated to your server instead of requiring only one for everybody.

distributed != decentralized!

Why are they calling this identity?

[Daedala]

I like this quite a bit. However, I think it's suffering from the same problem most people have with the term identity on the Internet -- binding.

"Identity," formally, means who you are -- the unique person with your identity. I'm not going to write my real name here, but that's my identity. No one else is me: my identity is bound to me, even if there are people with the same name.

"Identity," colloquially, means "that person I know." You may not know me by my name. You know me by "daedala." That's my handle. I always post here as daedala, so that's my consistent presense on slashdot (and my journal, and my email, and most other places I post...).

It's pretty difficult to establish a unique identity, bound to an individual, on the Internet. People screw this up all the time. It's not nearly as difficult to establish a consistent handle. From my review of this system, what it's doing is the latter.

So really, they should be calling it OpenHandle.

Re:Hosting Servers

[soupdevil]

But Slashdot readers are more likely to manage their own sites which would be candidates for using Open ID, which makes Slashdot potentially more valuable.

Re:Certain Information

[Elwood P Dowd]

That doesn't make any sense at all. The point of OpenID is that you can say "I'm Brad Fitz from Livejournal" and it would check with Livejournal. Isn't that exactly authentication?

Sure, you could lie about being Brad Fitz by saying "I'm Brad Fitz from Deadjournal" but then... those are two separate identities.

Identity can be decentralized, authenticity can't

[Omniver]

Authentication (username - password/tokencode/biometric/whatever) is generally the first step to establish a digital identity. This reqires some trusted source to be able to judge if the credentials are sufficient to establish the identity.

From my quick reading, OpenID doesn't try to do this and leaves this up to the "identity provider" which can be a centralized service or even my own home system. OpenID is more concerned with mapping whatever identity the user chooses to use consistently across the sites they visit.

This makes sense for sites that care more about consistenty mapping a user to an ID, but don't really care who the user is (like Slashdot), but makes absolutely no sense for any site that actually needs to know something about its users (banking, commercial, etc.) Until such time that there is a commercially trusted source of identity (yah right), sites that perform any type of regulated or high-risk activity will have the responsibility of identifying their own users or federating with other entities that they trust backed with legal/liability agreements.

IMO: This is doomed to blogspace and sites where liability is not an issue. If you're serious about SSO, look to SAML.

Re:Hosting Servers

[Nos.]

And this is the important point. For some reason, users of web services don't typically demand features like consumers do in other markets, at least not to the same degree. New features usually are first designed by site/owners/programmers/designers/masters/etc and then copied by countless other sites.

So, having a large population of readers that also maintain or run sites see and believe in an open system like this is probably more important than the user base knowing about it. Lets face it, if everyone on /. started incorporating this technology into their sites and mentioned it on other sites that are maybe more targetted, this could take off faster than anyone expected. Imagine if slashcode, post/php-nuke (and all the other OSS CMS systems), etc started putting in modules for this. Microsoft passport would become nothing but a memory very quickly.

Re:Single signiture sign-on

[cr4p]

What I want is a system where I go to a site requiring a login and it asks my browser to sign some data with my private key. During the account creation I send the server my public key and that's that -- no need for a password and the login could be done automatically using cookies or something. Then there is no need for a single sign-on provider and nobody can globally revoke my account at all sites.

Interesting...That sounds a lot like what client-side SSL certificates can already do in most web browsers that support SSL. I haven't heard of any sites making much use of client-side SSL certificates, though.

Re:Certain Information

[Elwood P Dowd]

Right. And you do that with Slashdot, just like you have in the past.

This, distributed authentication, lets other sites agree that you are Nicholas Harmon from Slashdot.

What have I missed?

Re:Certain Information

[iabervon]

There isn't any trust between servers, but a server knows that any identity at a particular server trusts that server, and therefore that the remote server is sufficient to authenticate that identity. If I claim to be [e-mail], and slashdot.org agrees, that should be enough for anybody. Of course, some other site is unlikely to care if I'm [e-mail] or not, unless, during an interaction with the site, I tell it to authorize [e-mail] as me, because I (the user in the interaction) trust slashdot to identify me.

For example, if I post a comment on groklaw as [e-mail], I could edit it with the same identity but other people wouldn't be able to convince groklaw that they were me, even without any particular trust between sites. If I trust my own server to identify me, and I trust Amazon to have my credit card info, and I tell Amazon that I trust my server to identify me (before I give it my credit card info), it doesn't need to trust my server itself.

This system has issues

[Anonymous Coward]

Admittely, I need to read up on this, and it's definitly an interesting idea to have a single login but I think there are some behind the scenes issues that need to be worked out.

Yes.

This system intends to provide provable same identity across multiple websites. However, it has some drawbacks.

* This is billed as a single-sign-in approach. There are technically superior approaches to single-sign-in, such as the Password Manager in Firefox. The PM approach does not leak your "real" identity to everyone. While Firefox does not (I think) support centralized storage of PM data, it's certainly possible for it to do so or use a system like this. The real benefits of this are that you can prove that your identity in two places is the same thing in a standardized fashion, so that we know that ltorvalds on slashdot really is Linus Torvalds.

* No support for progressive release of information. I don't want to tell every website (let's use www.trollnet.org as an example) that I'm "Michael Hotwitz", because they don't need to know that. All they need to know is that I'm User 3452351, and I want to be able to sign in using my single password. No information is leaked this way (other than what a cookie would already give them, that I'm the same user that visited their site before). If, at some point in the future, I decide that I want that website to know that User 3452351 is also [e-mail], the much famed GNAA poster, so that I can revel in the appreciation of my troll buddies on www.trollnet.org, I can tell them so. A simple form of this would be identity merging, where I simply prove that my two identities are the same, and they become "merged". A slightly more sophisticated approach would be to allow proving that an identity on two particular sites is the same, without "merging" the two, so that site A knows that ID1 == ID2, and site B knows that ID2 == ID3, but neither necessarily knows that ID1 == ID3.

* The auto-fill-in web page approach recommended by the OpenID people is a bad idea. If I make a form that I can convince a user to submit, and stick the auto-filled-in field at the bottom of a web page, I can harvest unique, cross-all-websites identities for each user.

* This system relies on DNS for the Availability security property. While, with root cert caching, someone attacking DNS can't fake your ID, if someone else gets your domain because it expires, you lose your identity. I've seen domains come and go, but I still use the same GPG key. Also, this puts Verisign back in the driver's seat for controlling identity management, and frankly, I and most techies trust Verisign to Not Be Evil about as far as we can throw them.

The main advantage of this system is that it doesn't take any client-side support to roll out.

I'd rather see someone write an Identity Manager extension for Firefox and a plugin for IE, a program that uses GPG as a backend and can sign a few standardized messages, like "You can trust this other ID to also be me" and "I'm compromised". No identity leakage inherent to the system, can have IDs stored on a server if you want but you don't have to, Verisign isn't involved in the system, no availability attacks on IDs through DNS registration expiry or DNS spoofing services. You could play each new MMORPG with a persona that enjoys the reputation that you've accrued in the past -- as being a helpful person. People who abuse systems and are no fun to play with don't build up a reputation and are easy to identify.

I just can't figure out why people are so damn eager to tie ID and trust systems to DNS -- one of the places that there really are some solid objections to DNS. It's like people have DNS hardwired into their brain these days.