Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Privacy Security The Internet

Jabber Takes On MS Passport 32

Posted by timothy from the lower-fat dept.
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.
This discussion has been archived. No new comments can be posted.

Jabber Takes On MS Passport More

Jabber Takes On MS Passport

Comments Filter:

  • Sweet... (Score:4, Insightful)

    by Anonytroll ( 751214 ) on Wednesday February 11, 2004 @10:01AM (#8248703) Journal
    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... (Score:4, Insightful)

      by Hitch ( 1361 ) <hitch&propheteer,org> on Wednesday February 11, 2004 @10:15AM (#8248852) Homepage
      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, (Score:4, Insightful)

    by noselasd ( 594905 ) on Wednesday February 11, 2004 @10:17AM (#8248869)
    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 (Score:2, Informative)

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

  • OpenPGP based single-sign-on (Score:4, Interesting)

    by Anonymous Coward on Wednesday February 11, 2004 @10:50AM (#8249232)
    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? (Score:5, Interesting)

    by Bazzargh ( 39195 ) on Wednesday February 11, 2004 @10:56AM (#8249274)
    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 [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 [internet2.edu] and OpenSAML [opensaml.org] 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 [athens.ac.uk] (SSO for the UK EDU/GOV sectors), which is similar to Shibboleth in scope, and doesn't require browser changes.
    • 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, whi

  • Kerberos?? (Score:5, Interesting)

    by Visigothe ( 3176 ) on Wednesday February 11, 2004 @11:07AM (#8249383) Homepage
    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?? (Score:5, Interesting)

      by kelnos ( 564113 ) <bjt23@cornel[ ]du ['l.e' in gap]> on Wednesday February 11, 2004 @01:13PM (#8250854) Homepage
      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.

      • Re:Kerberos?? (Score:1, Informative)

        by Anonymous Coward
        Kerberos is supported by lots of software save for web browsers - but for those one could use kx509, kweb, or other services. Even jabber may be usable for kerberised http someday.
        And interrealm kerberos is used every day by big universities and other institutions (not to mention single users as well)
    • My impression was that it is nearly impossible to deploy Kerberos outside an Intranet. Has this changed or is my information incorrect?

    • 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 [jabber.org] they seem like the might be able to use Pluggable Authentication Modules [kernel.org] (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 method

  • Jabber is good stuff... (Score:3, Informative)

    by tcopeland ( 32225 ) * <tom@NoSPaM.thomasleecopeland.com> on Wednesday February 11, 2004 @11:08AM (#8249389) Homepage
    ....we've been using the Jabber4R Ruby wrapper [rubyforge.org] to route Cougaar [cougaar.org] 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...
    • So, why does the Cougaar website show a logo with a picture of a cheetah?

      Totally different species, living on totally different continents.
      • > a picture of a cheetah?

        Is it? Hm. How can you tell the difference?

        • Re:Jabber is good stuff... (Score:3, Informative)

          by AJWM ( 19027 )
          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.
          • > for running down its prey in open, flat terrain.

            Nifty! I'll have to bring that up at our next group noodle. Thanks.

            > for a cougar

            After working on this program for a couple of years and seeing it spelled "cougaar" over and over, my mind sees the correct spelling "cougar" as a mispeling. Ack!
        • Trust me. A biologist just knows.

    • Re:Jabber is good stuff... (Score:3, Interesting)

      by AJWM ( 19027 )
      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.)
      • > 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 [amazon.com]. Fun stuff!
        • We've put together a distributed testing and control framework in Ruby, and so we used Jabber as middleware between Java and Ruby.

          Okay, cool.

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

          Ah, I hadn't seen that book. I'll have to check it out.
  • 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.

  • Still vulnerable to man in the middle (Score:4, Informative)

    by hargettp ( 74445 ) * on Wednesday February 11, 2004 @04:37PM (#8253288)
    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 [netscape.com] and this paper [sans.org] 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.
  • Interesting enough would be knowing the relationships between the Jabber proposal for SSO and the efforts pursued within Liberty Alliance [projectliberty.org].

Slashdot Top Deals

Garbage In -- Gospel Out.

Close