Slashdot Mirror
Liberty Alliance Releases Specifications
Darren.Moffat writes "Has the time come for Passport to move over ? Technical Specs of the Liberty Alliance Project technology are now available from the website and were officially announced at the Burton Group conference today." We've done stories on the Liberty Alliance and digital identity before.
I was thinking rather pessimistic about all this, until this little beauty popped up:
"The Liberty version 1.0 specifications do not involve the exchange of personal information. Instead, they involve a format for exchanging authentication information between companies so the identity of the user is safe, and specific details about the customer's identity are not shared. The user may choose which accounts he/she wants to link, and may maintain separate identities in different locations while still benefiting from a seamless sign-on experience."
So, it's cool. Well, not that Em Emalb would be targetted anyway, more along the lines of some poor dude named Pete Slashtaco (who for some reason, lives in New York City 10101) and makes $15,000 a year working as a CEO of a Fortune 500 business with 250,000 employees. Poor, poor Pete.
Sent from your iPad.
Ironically, passport started as a stop AOL Instant Messenger affair. So I don't think it is impossible that Passport and Liberty will eventually merge.
On a technical level this is certainly possible and if folk look hard at the underlying SAML spec that Liberty is based on you will notice that there is an interesting intersection between SAML and the GXA world.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
a direct link to the specs is here
-BlueLines
--BlueLines "The cost of living hasn't affected it's popularity." -anonymous
I downloaded the specification, but it's obnoxiously long/buzzwordish and my Linux PDF software sucks. I've got some pretty basic questions I'm hoping someone can answer:
One would hope they are only sent to the identity provider, and encrypted. But this talk of using existing deployed clients makes me nervous, since I don't see how both things are possible together.
They mention HTTP redirects...I think you go to the Service Provider's page, they redirect you to the identity provider as the form action, and they redirect you back, authenticated. That doesn't seem like a good plan to me, no one will actually check that the form action goes elsewhere.
I'd be much more comfortable with something similar to Kerberos: you get a TGT (ticket-generating ticket) from the Key Distribution Center (excuse me, Identity Provider) and use that to provide a ticket to the Service Provider. That ticket can't be used elsewhere and will be invalidated after a certain length of time.
I'd like to use it to authenticate with HTTP, SSH, IMAP, SMTP, and Jabber - probably others I'm forgetting, too. A GSSAPI and/or SASL mechanism would help a lot here.
I'd hope that anyone can set up Identity Providers and Service Providers at little or no cost and have them work with major players. I think this would require
Here, I think the answer is yes. They said something about opaque tokens that gave me hope. I'd like clarification, though.
First up, this is very similar (possibly even based off of) the Internet2 middleware project, Shibboleth. Incorporating similar technology such a SAML assertions. In the interest of disclosure, I am working on a setting up Shibboleth at my University as a method of allowing intra-University authentication AND authorization. So I can talk somewhat about that (although I do not in any way speak for Internet2, I do not work for them, I probably will get some details mixed up, have a grain of salt, etc.)
This is not about central authN or authZ (authentication and authorization), it is about utilizing existing auth databases and methods and allowing them to talk to each other. An example, if I may:
A student at University A wants to take a web based class offered at at University B. The two Universities have a partnership established but unfortunatly University A uses Kerberos as a central authentication tool and University B uses Active Directory (Uni B obviously never plans to scale, but I digress). Either way, Uni A is not going to give Uni B the user's password, and Uni B really does not want to add every external user who is going to take this class through the partnership.
The solution Shibboleth offers is that Uni B can simply "point back" to a url at Uni A that is protected with their central authentication system, and if the student can log in there, Uni A creates a digitaly signed certificate identifying the user to Uni B AND any relevant authZ information. Meaning that the the list of students allowed to take this class is managed by Uni A and Uni B never has to worry, the signed certificate proves all they need to know. There is obviously more to this but check out the above web site for the specifics.
The important part to all this is (1) inter-realm authentication: There is not one single database of users and authZ info, there are multiple players who pre-agree on authZ info, but maintain their own internal user databases and methods of authN. Presumably, the ability to say what the external entities can see about the users could be delegated down to the users themselves. (2) Authorization: Everybody is familiar with single sign on concepts that only prove who you are, how about ones that also say what you are allowed to do, what groups you belong to, and what access you have. DCE did a fine job of this (and Microsoft did a fine job of renaming DCE to Active Directory and calling it innovation) but it did not talk to other authN/authZ systems.
If the Liberty Alliance is as close to Shibboleth as I think it is, then it offers something we have never had before. A framework for a single sign on system that is not centrally managed, but leaves control to seperate entities that mutually trust each other.
Let's face it, when it comes to something like this you don't want all your eggs in one basket, especially if that basket has to answer to stockholders and has possibly the worst security reputation in the shory history of computing (really, I don't know why Hailstorm failed...)
This looks promising and it appears to be an approach that nobody has taken before. So don't assume it is just Sun's version of Passport, the technology seems vastly different. Specifically, it seems to be designed with the user's best interest in mind, not a single corporation's.
Finkployd