Where's Single Sign-On? Part 2 7
In a recent Wired article regarding One Login, reference is made to a new social style network called GoingOn. The article spends most of its time focusing on one site that hopes to aggregate functionality that currently is split between Blogger, Flickr, Friendster, and Bloglines (for the most part). However, the thing it misses is what I previously discussed regarding the lack of a working distributed identity system.
After looking around more, I’m happy to say there are indeed working identity systems out there. Unfortunately the most promised of them, the Liberty Alliance doesn’t seem to have much oomph behind it, but two others that I previously didn’t know about are now out there.
The first is from the folks at Microsoft, which they’ve called an Identity Meta-System (or something like that), which is described over at vnunet. It seems to be rather tied (or at least integrated heavily) to Microsoft technology (go figure!), and will be included in Indigo and other various Micrsoft technologies. As a mainly open-source coder, this has little appeal to me, nor am I about to start using Microsoft API’s to write my websites and web code. The standards utilized by Microsoft for their Federated Identity are generally known as WS-* for some reason I’m too lazy to investigate.
The second is much more appealing (to interested users and web developers), and has actually been around for a very long time in a primitive form (2000 is ancient by web standards). The home site appears to be the identity commons, and the current sole Identity Broker is 2idi, the organization behind the standards is XDI. They’ve made the entire code-base they run the Identity Broker on, open-source under the Affero General Public License to ensure that users are never locked into just one Identity Broker (Yea!).
If you’re curious how the Microsoft and Liberty Alliance methodology differs, idcommons has a useful FAQ addressing the differences.
The most exciting aspect for me, is that all the technology behind the XDI approach is completely open-source, and geared towards maximum user flexibility and empowerment. The user gets to move data between Identity Brokers, and every care has been made to ensure the user is never locked into a single Identity Broker. Actually, the most exciting part, is that it works right now. :)
They’re currently preparing to switch to a SAML-2.0 backed code-base, however the code they have only works from PHP, Java, and Perl. If you want to try it out, here’s how to get an i-Name, and you can try it out on those two sites. Also, a developer made a ISSO (I-name Single Sign-On) authentication system for WordPress which is pretty cool.
So what’s stopping ISSO from being used on more websites? It’s free, its open-source, its standards based, its not controlled by a commercial corporation….
It needs Python libraries!
I should mention, when I first wrote this as far as I knew, there was no Ruby version. There still isn’t a public one, but Victor Grey is fairly close to a Ruby version with a full Rails rig to go with it which I’m rather looking forward to.
Anyone want to help? I’m tired of remembering a zillion usernames and passwords, and with ISSO on the horizon I shouldn’t need to, all the Python web frameworks will be a bit better (at least the sites that use usernames/passwords) with an easy way to use ISSO.
By the way, for a useful overview of SAML, there’s a very detailed write-up of SAML2 on xml.com.






What about http://openid.net/ ?
Phillip: I did look at OpenID, however I was looking for a full fledged Identity Management solution. It does provide an answer to my first complaint though, which is having to remember tons of username/password combos, and it is a slick way who owns a URL.
From looking at the OpenID Status page though, it seems they’re a ways behind ISSO. The i-Name (as much as I hate things that begin with i) has a working version right now, and is migrating to a SAML-2 based version.
The OpenID system should be great for most people (ones that don’t want to do more complex identity stuff), and if I could cut myself down to one OpenID, and one i-Name to use all the dozens of sites I use, that’d be just fine. :)
You can use Liberty Alliance from Python with the Lasso library http://lasso.entrouvert.org (GPL License).
There is even a Python Identity Provider based on Lasso: http://authentic.labs.libre-entreprise.org/ (GPL License)
I should also mention, that’s there’s another system quite similar to openid called mIDm. There’s even a Zope demonstration of mIDm.
R. Eldred: I saw the Python example of that with the Identity Provider and such, any idea how many current Identity Providers are out there offering free sign-ups?
One of the big appeals to XDI and the iName, is that they allow registering within the XNS namespace, sort of like registering domain names on the Internet. There’s also more advanced services that will enable a lot of nice features, however mIDm and OpenID will be sufficient for some.
I just wonder how many average people can handle setting up a program on their website (many ppl still don’t have websites) that will allow them to authenticate.
Systems tying you to a URL, while giving you one username/password, have tied you to that URL. There doesn’t seem to be any portability to avoid lock-in present. This is fine if you own the domain, but if you’re just a user (say on LiveJournal), your login is at the mercy of someone else.
How can you do better than a URL? The URL space is far more flexible than, for instance, the email space (web hosts are cheap and plentiful and easy to migrate compared to emails). If you are going to have an identifier, that seems like a cheap and transparent kind of identifier.
Since openid is indirect (the URL just refers to the identity server) it is secure against one kind of lockin.
I hadn’t really looked at openid before, but reading it I’m rather impressed. It’s limited compared to any other login method, but I like that; it solves Just One Problem, and gives a good start towards solving the other problems incrementally.
Thanks for all the nice comments.
Us i-name afficionado’s would definitely love to see the python and ruby libraries and your other recommendations come to pass!
From the Identity Commons perspective, one of the most interesting things about i-names is their ability to interop with other technologies (the XRI standard is a kind of meta-identifier that plays nice with others).
The Identity Commons’ mission is creating a system where we have choice and control of our digital data and this requires interoperable technologies and open data protocols such as XRI and XDI. We’re not just about i-names but we started with them because of the philosophy they embody and because of the importance of initial conditions when you create any new system. We want to make this stuff work with everything we can and believe it’s the standard best suited to do exactly that.
But our plan is to promote all the technologies and sites that work together in pursuit of our mission.
You can see a glimpse of where we’re headed with the demonstration of XDI interop with LID (see link on http://wiki.idcommons.net/moin.cgi/UseAnIName); store some data under your i-name (really the i-name is a virtual point of aggregation for distributed data under your control) and optionally publish it through the LID identity protocol.
Anyone else think this is cool? :-)
PS. One small point: there actually isn’t any claim of trademark on the term “i-name” so we don’t capitalize it unless in titles when we’re capitalizing other stuff also.
Ian: Maybe I wasn’t clear in my comment. The URL space is a lock-in if you don’t own the domain for the URL. Most people don’t own domains, which would make their login reliant and locked into the owner of the domain.
The URL is their login under OpenID. Losing the URL, means they lose their single sign-on. It’s definitely very flexible and great for those of us that own our own domains. As we can be quite certain they’ll be around as long as we continue to pay for them (and make sure a website is setup to answer the sign-on request).
What if you forget to pay for your domain, and the domain is in limbo for a month while you resolve it? Bye-bye login. Or maybe the company that owns the domains changes policy (as happens way too frequently) and decides to scrap the sign-on service.
That’s why I’m fairly interested in the XDI stuff (amongst the other great points Owen cited).