Slashdot Mirror
Jabber Takes On MS Passport
Lord Prox writes "Jabber Ticket Authentication is a method of authenticating with HTTP servers using your jabber identification. This allows you to login to websites using your jabber address in a single sign-on fashion similar to .NET Passport, but unlike .NET Passport is not locked into a single authentication provider. Tickets also mean the jabber ticket provider and the web server do not need to be tightly integrated for authentication to work, also because its not tightly integrated it means webmasters do not need to setup their own jabber server to provide tickets, they can use a third party provider even a central "tickets.jabber.org". Also because tickets are not tightly integrated it makes it far easier for webmasters to integrate with Jabber, it also makes web farms far more scalable and reliable." Update: 02/11 19:22 GMT by T : The link to jabber.org has been fixed; thanks to reader Laurence Withers.
Their and quite a few other project's motto could be "do it like Microsoft, but do it right". Sadly, that would end up in a lawsuit, so we'd better not say that openly.
However, it is interesting to see how easily Microsoft could do something right if they would only abandon their lock-in paradigm. I wonder how long it would take for them to realize that they could have a similar amount of marketshare if they were fair to their customer instead of trying to screw them over.
In the meantime: Go, Jabber!
It's a rather nice feature, but with all these diffrent single
signon/central-whatnot technologies, do we really get single-signon and all the other features we're promised.. ?
Was it just me or were there way too many times that post used the word also. It sounds like interesting information though. Also, it could be really cool if you're a webmaster wanting to secure access centrally and also don't want to deal with it yourself. It would also be cool as a user not needing extra passwords also. Also, there must be one more way I can find to use the word also. Also
When I tell an object to delete this, am I killing it or telling it to kill me?
I think the poster meant http://www.jabber.org
I could be wrong though. Perhaps he wanted some Duff(tm/r/c?)
If you're religishitty, KILL YOURSELF!
I'd really like to see OpenPGP key infrastructure used as a SSO mechanism. Perhaps this can be integrated into
the key-exhange mechanism of this Jabber project
and the SASL client side.
The public OpenPGP keys could be fetched from public keyservers/jabber servers/LDAP servers.
Complex stuff, but still important missing stuff IMO.
Walden
If you look at what is proposed, it describes clients sending tokens like this:
GET http://www.webserver.com/webpage.html HTTP/1.1
Authorization: JabberTicket 54yudvjhssa76dta6sgdst78r4sadsfjdhs...
now apart from the nitpicking complaint that they should use example.com as the test domain (follow link to see why), its obvious that this needs client-side support. With browser rollouts being mindnumbingly s l o w, that means they are probably targeting web services, or non-browser clients, or must be building a browser extension?
Secondly, the spec for the client request for a ticket doesnt include any authentication info whatsoever. Ok, this means they must be doing that in 'some other protocol' (presumably Jabber + SASL). They could be a bit clearer... this part basically requires you to have a fairly complete XMPP implementation in order to get at the apparently simple ticket service.
Mark me down as unconvinced. Take a look at Shibboleth and OpenSAML to see what others are doing in this space - they are already doing single sign on, and it already works (OpenSAML does have the downside of being affected by a free-to-license RSA patent).
We have integrated sites into Athens (SSO for the UK EDU/GOV sectors), which is similar to Shibboleth in scope, and doesn't require browser changes.
I may be totally out of line, but the idea of single sign-on through tickets/tokens already works rather well with Kerberos. Why not incorporate Kerberos into the Jabber system?
Many people think that Kerberos is very difficult to implement properly, but it doesn't have to be so. Currently Apple makes authentication via Kerberos rather simple.
Perhaps I just don't see a benefit of going with something new/different when something battle tested will fit the bill.
Blocklevel: Practical Information Architecture
....we've been using the Jabber4R Ruby wrapper to route Cougaar status messages for a couple years now.
It's kind of running out of gas on us as our message volume increases, but it's worked well enough so far...
The Army reading list
After reading that JEP, I think that jabber doesn't need to spend time solving this domain problem. Let others do it and stick with messaging.
I personally like Yale's CAS system for what is stated in the JEP introduction... A nice single sign-on method for non affiliated websites.
The proposed design asserts that man-in-the-middle (MITM) attacks can be eliminated by using SSL. However, SSL suffers from man in the middle vulnerabilities; see Netscape's SSL documentation and this paper from the SANS institute.
I think I was hoping for an algorithm with the handshaking complexity of Kerberos or SSL, because unfortunately a good security algorithm typically requires that level of sophistication, I would assert. Perhaps the design was aiming for a simpler starting point, with furthe refinement in the future; if so, it has met the goal nicely.
Even installing Kerberos is not a bit deal anymore. For several years now it's been part of distros as ready-to-use RPMs or .deb packages.
If you combine Kerberos with OpenLDAP, then you get great flexiblity with users and groups in addition to the security, scalability, and platform independence lacking for weaker substitutes like MSAD.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
Interesting enough would be knowing the relationships between the Jabber proposal for SSO and the efforts pursued within Liberty Alliance.