Slashdot Mirror
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."
So this is a distributed ID system, that is open source. I'm not sure that this is a good idea, but am willing to try. Hell, anything beats Passport. I think that if Slashdot adopted this (OSDN), it would attain critical mass.
--sig fault--
I coincidently not long ago wrote a paper (ggogle cache) on how to implement RSA-based signle sign-on (using Python/mod_python). Using public key signatures seems like the most obvious way of implementing SSO. I'm surprised OpenID is using DSA though - AFAIK RSA (now that it's patent free) is a superior, more trusted and flexible algorithm.
I'm not a cryptographer by any means, but IIRC DSA was put together by NSA as an algorithm that was "crippled" to only do signatures, but not encryption, and there was some controversy because at first NSA wouldn't admit to being the designer, instead NIST was pretending to be one, and then later someone discovered a way to somehow leak bits and it is still a mystery whether this was intentional on the part of NSA or not.
Does it mean I have release my password per GPL and anyone is allowed to modify and distribute it for free?
Why is this in Hardware? Shouldn't it be... IT?
while it certainly would be nice to login to one spot and be logged into all my favorite websites, as a webmaster I use different information based on what part of my site the person is logging into. Their username/password might be the same for both pages but a cookie might be set on one that isn't on the other and doesn't need to be on the other or could be harmful if done.
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.
Also the decentralized nature of the servers has me worried/confused. So if I ran one, would I have everyones authentication information?
-Teiresias
I'll authenticate with each and every site I visit...
Take MS Passport for example. I log on to MSN webmessenger. I chat with some friends, then I close it down. 3 hours later I decide to log on to MSDN to grab a file, I need to log in with a different account since my messenger account doesn't have the access... fine... I do that... then a few hours later when I go to webmessenger again, I'm auto-logged on with my MSDN credentials.
The only option I have is to force all passport sites to stop caching my username/password and make me type it in everytime, thus defeating the purpose entirely.
This sort of password system is open to all sorts of problems, and not just of spoofing, or somehow being hacked and having people impersonate you... I'm more worried about logging on to some place with the wrong credentials...
---
Programming is like sex... Make one mistake and support it the rest of your life.
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.
Evolution or ID?
if anyone can set up a server authenticate does that mean they can access my information? or track my movements? i am thinking of abuses.
always mosh clockwise
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.
You could still have an 'id provider' that could sign the data on your behalf if you are on a internet cafe for instance, but it would not be required by design. So in 'kiosk mode' the browser could just forward signiture requests to the authority after you logged into it (which could even be your home computer).
This should be pretty easy to do as a firefox plug-in.
I worked as an outside vendor with an internal part of novell (few 100people maybe) that built a beautiful SSO system - linux based and accessed novell software components better then the novell software. The solution was supposed to be for ASP's (application service providers - something from the bubble days) and allow them to link products from multiple vendors together so not only could it manage websites, but other network applications (even if they are hosted on someone else's network the other side of the continent like my companies). It wasn't an open product, and the day before we were to go live (even had a contract that would have made it profitable from day 1) Novell Laid Off 10,000 people across the company to save money (the bubble was just starting to burst). Among that 10K were my poor SSO friends, and of course 6 months of work on my part was wasted too.
The rock, the vulture, and the chain
Given the amount of Microsoft, Apple, Google, and other big-name-company stories that, otherwise inexplicably, have been termed "news", and "stuff that matters", yes.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
http://lid.netmesh.org/ - I've heard good things about LID, and it supports SSO.
There is no feasible way of identifying a unique person presently. Fortunately, few entities care (one is the IRS, which wants to prevent individuals from splitting their income and lowering their tax brackets; another is law enforcement, which doesn't want people to be able to start over with a new identity).
For most things, the only thing that matters is that the site can determine that some entity that claims to have been there before is back. Identity
is about telling that things are the same, not about telling that things are different.
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?
Delivering militantly anti-commercial music to all two people who care!
See what happens when you don't read the article, you end up not understanding what it's about and then you make stupid comments.
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!
That's a common misconception. We have no problem with people making money from your password. It's the attempt by some to restrict freedom and keep your password all to themselves that we are against.
We would support, for instance:
Your password wants to be Free. We urge you to set aside the bondage in which your password is held and join with us for a better community.
[Gnoll mode: OFF]sigs, as if you care.
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.
What I say does not represent the views of my employers, my friends, my cats, or myself.
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.
I don't think RSA is overall more trusted than DSA, and I certainly don't see a way in which it's more flexible for this application. It was designed only to do signatures, but that's fine, since only signatures are needed here.
When you say "leaking bits", you're probably thinking of subliminal channels, and you're referring to some rather out-of-date information in Applied Cryptography. It's now established that all secure signature schemes have subliminal channels; they have to be probabalistic for the security proofs to work, and that's enough to give a "low-bandwidth" channel for anyone who doesn't know the signing key, or a "high-bandwidth" chanel for those who do.
DSA is a perfectly good choice here.
Xenu loves you!
For whatever reason (could someone wager a guess?) SAML has not been widely adopted (and don't try to argue this point). Maybe this will rectify whatever deficiency SAML has? Or maybe the project is just to create a widely-usable SAML authentication authority?
Because if you log onto a foreign web site, it says, "Ah, this person is giving me an id which is stored on another server. Let me ask that other server if this person is known to them". If the other server knows this, it returns a token so now you know that the other server authenticated. (You can then associate things with this token for when the user next visits your server).
So basically, if you're logging onto the web site where you are registered, it simply makes a local call to a local database. if you provide an ID registered at another server, instead of the webserver looking in its local database of IDs, it asks the remote server if it knows the user. That way the user doesn't have to register with your site, too.
Oolite: Elite-like game. For Mac, Linux and Windows
I mean, I shouldn't be surprised, but I am. It seems liek 90% of the people commenting didn't RTFA, or didn't have their brains installed at the time. This isn't a secure banking system - it is, as one person pointed out, probably better described as OpenHandle. You sign in ONCE, and from that site, you tell it which other sites can authenticate from your identity site. Then, these sites know who you are. They don't get your password, or anything, they just get a temporary key to verify that you're you. Any site can fake it, that's not the point. The point is that you have participating sites where you would want to now have to sign in every time you want to comment. It helps prevent lock-in to blogs etc - imagine, for example, you sign in to slashdot, and then you can use the same handle without having to create accounts and sign in at other blogging services. THAT's the idea. It's not a trust net, or a passport-like system, it's just so that sites that want to play by the rules can provide people with a convenient way to identify themselves. That's ALL.
Why don't we just use a single password entered by the user (once per session or once per browser..depending how it's saved) to generate tokens unique to each site a user browses to. Pass those tokens to the site automaticlly as part of the http headers. No need to ever send any login data through a third-party. No need for any complexity on the part of the end-user or website designers. Just a small bit of extra code added to the browser and webserver (optionally). Firefox and Apache could do this easily enough.
Heck you could have the browser send these unique user and password tokens automaticlly whenever the website asks for http auth. Nothing would even need to change on the server side. Just a small change to the browser. The chances of two users both having the same username and password aren't that high unless they pick something really easy to guess anyway like a name and password they see in a movie.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
We have this already, it is called digital certificates. I get one digital certificate that identifies me and I use it on multiple sites. Now if more sites just supported authentication by digital certificate, a process supported on all web servers already then we would be done. Why do so few webmasters understand digital cerficates? Do we expect them to understand this any better?
I RTFA'd and OpenID relies on a single host as an authenticator, just like Passport. Sure, you can have many single host authenticators with OpenID (whereas there can only be one with Passport), but at the end of the day, your credentials are only as strong as the security of that one box. Remember all the problems that Microsoft had with authenticating and authorizing Hotmail users? Single hosts make inadequate authenticators. The CorSSO folks fix that problem using threshold cryptography - in CorSSO, an attacker has to compromise a group of different hosts all at the same time to usurp someone's identity, which can be made much harder than compromising a single host in OpenID.
From the sound of this, you log in to one site (your homesite) with your real username and password, and after that it uses digital signatures and a list of trusted sites to prove to that site that you are the owner of the URL.
I see several problems with this, one of them being specifically that it doesn't require a password everywhere you login. I know the point of single sign-on is to have one username and password for everything. However, think about your average user: when prompted with a dialog box asking "Would you like to trust this site?" or "Would you like to install our malicious software?", they have an uncanny habit of clicking "Yes" without thinking. I think this will become a problem as well--people authorizing any site just because it asks, and not realizing what it means in the end. Requiring password entry and making the requesting site very clear would make it much easier for users to know what they are doing.
Tired of free iPod sigs? Subscribe to my blacklist
I do wish the authors success but OpenID is simply another protocol for asserting identity information. What is fundamentally missing, especially in OSS, is a mechanism for implementing identity. In truth implementing identity is something that is also missing in the plethora of commercial products which are seeking to provide solutions in this space.
Globus/GRID, Shibboleth, PubCookie, LID and a legion of others are already implementing mechanisms for making assertions about an identity. The fundamental problem with implementing any of these technologies are the back-end systems for implementing and protecting identity and a manageable system for tracking differential acesss (authorization) at a high level of granularity.
The Open-Source community is currently lacking any respectable effort in this arena. All the basic pieces are there with LDAP, Kerberos, SAML and a host of other technologies. What is required is a coherent framework which implements all these technologies in a manageable package of infra-structure. It will be where the real war for control of information delivery gets won or lost for OSS technologies over the remainder of the decade.
As I noted in the first paragraph what is fundamentally lacking across the spectrum, commercial or otherwise, is a fundamental definition of identity. Its interesting to see that a couple of other posters have noted this as well. Our Hurderos Project is trying to address that with an OSS solution in an attempt to turn the tide of everyone inventing their own solution.
Getting that type of basic infra-structure laid down is key to unlocking an entirely new generation of application and information delivery architectures. It is also fundamental to addressing the intrinsic problem with federated or distributed identity systems which is the very real and very thorny problem of target sites asserting authorization over remotely authenticated identities.
In the brave new world of highly distributed information delivery systems with a mobile consumption (client) base the only important thing is 'who you are and what do you have access rights to'. He who controls that will control everything.
LID -- Light-Weight Digital Identity -- is an entirely decentralized digital identity system that uses URLs as identifiers. Yes, you can host your own. It's so simple, the average Slashdot hacker can probably implement from scratch in an afternoon, and it supports SSO, VCard-based contact management, FOAF-based social networking, authenticated messaging and many other applications.
http://lid.netmesh.org/
Disclaimer: I'm one of the people who came up with it. I also talk about it and other systems on my blog at http://netmesh.info/jernst.
I'd like to see an authentication system that used OpenPGP keys.
e.g. I go to the bank with my photo ID and my OpenPGP key fingerprint and say "this is my key".
When I want to autenticate with the bank, they use my public key (which they can get from a key server) to encrypt a secret and send it to me. I demonstrate I have the private key and know the pass phrase by decrypting the cypher and extracting the secret ... more hand-shake stuff and ...
... authenticated!
I don't need the bank to know my password, and I can have one password for everywhere that uses this OpenPGP based approach.
I can't imagine a Kerberos (or Kerberos-like) single sign-on mechanism would be a huge step (relatively speaking) from this point.
check out V-ID. They have an free to use single signon system running right now.
If this open, secure, distributed authentication scheme works, maybe it could be used to achieve the US RealID program's (stated) goals. I especially like the idea of allowing an authentication request only a boolean, rather than caching any associated info. Until such a system works, the US shouldn't create a monster that doesn't. Real world test iterations of OpenID might get us there.
--
make install -not war