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.

Comments

Sweet...

[Anonytroll]

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!

Re:Sweet...

[Hitch]

unfortunately, they have a much LARGER marketshare (Than jabber, at least) - but you're right, their share would grow faster, and we'd be far less pissy w/them all the time. I mean, most geeks that dislike M$ still praise the things they DO do well. I have two microsoft mice and a microsoft keyboard. you couldn't get me to run windows if you paid me, but I like some of their hardware. and as much of a living hell as exchange is to administer, it's a good idea in theory if not always in execution. so yah, maybe they should drop their "lock in" paradigm. unfortunately, it's so entrenched in Bill Gates' way of thinking that they company will likely die first.
heh...Microsoft of the Endless - where a company learns that it must change or die, and makes its decision. (apologies to Messr. Gaiman)

Nice feature,

[noselasd]

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.. ?

Jabber Site

[Mizery De Aria]

I think the poster meant http://www.jabber.org
I could be wrong though. Perhaps he wanted some Duff(tm/r/c?)

Re:Jabber Site

[Mizery De Aria]

http://www.jabber.org

Also, a mirror in case it gets slashdotted:

OpenPGP based single-sign-on

[Anonymous Coward]

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

Requires a client plugin - for web services?

[Bazzargh]

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.

Re:Requires a client plugin - for web services?

[Specialist2k]

GET http://www.webserver.com/webpage.html HTTP/1.1
Authorization: JabberTicket 54yudvjhssa76dta6sgdst78r4sadsfjdhs...

[...] 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?

Not necessarily. I didn't RTFA, but a proxy (which could even run on the end-user's computer) could handle the authorization part without the need for new browsers, which understand the JabberTicket authorization method.

Kerberos??

[Visigothe]

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.

Re:Kerberos??

[kelnos]

i would agree with this, except for one caveat. (this may not be an issue, as i haven't RTFAed, but...)

kerberos is designed with the concept of a single authoritative authentication directory in mind. that seems to be pretty much at odds with jabber's goals here.

now, it _is_ possible to form "trust relationships" between disparate kerberos realms, but that isn't really an oft-used feature, and it seems to me to be something that was almost tacked on last minute without being truly designed into the system.

now, what i'd really like to see is a fundamental redesign of kerberos (version 6, anyone?) that takes into account some of the open, decentralised concepts that jabber seems to be pushing here.

of course, the final issue is application support. despite being around forever, kerberos still has little to no support in web browsers. certainly none of the major browsers (moz, IE, safari) support kerberos auth. other kerberised apps are hard to come by - sure, the krb5 distribution comes with kerberised telnet, ftp, rsh, etc., but GUI clients are hard to come by. and they want to add _yet another_ authentication protocol? who's going to support it?

i think something like this is a great idea, but unfortunately i believe that you'd need some major corporate backing to get this into current applications.

Jabber is good stuff...

[tcopeland]

....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...

Re:Jabber is good stuff...

[AJWM]

More serious question: since Cougaar is Java-based, howcome you're using Ruby and not a Java wrapper or something like JSO (Jabber Streaming Objects)?

(Speaking of which, for those in the Denver area, Peter Saint-Andre and Matt Miller will be talking about Jabber and JSO at the Denver Java Users Group (www.denverjug.org) tonight.)

Re:Jabber is good stuff...

[tcopeland]

> how come you're using Ruby and
> not a Java wrapper

We've put together a distributed testing and control framework in Ruby, and so we used Jabber as middleware between Java and Ruby. We've got some in house expertise in Ruby and it just made sense to use a scripting language to do some of the sorts of things we're doing.

> Peter Saint-Andre and Matt Miller will
> be talking about Jabber

Cool. I work with Dana Moore and Bill Wright who wrote the Jabber Developer's Handbook. Fun stuff!

Re:Jabber is good stuff...

[AJWM]

The running style is the big givaway, other points are the shape of the head and the length of the tail. That thing is built for speed, for running down its prey in open, flat terrain. Cougars (at least around these parts) live in mountainous, wooded terrain and prefer to attack from hiding.

At least it's colored correctly for a cougar, no spots.

Still vulnerable to man in the middle

[hargettp]

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.

Kerberos + PAM??

[SgtChaireBourne]

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?

I know nothing of Jabber, but looking at the jabber components they seem like the might be able to use Pluggable Authentication Modules (PAM) by telling that service to authenticate using Kerberos. Kerberos is not so difficult to implement using PAM and you can even set it up for fail over between different authentication methods.

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.