On Thu, 2002-01-10 at 16:11, Michael F Lin wrote: > > Distributed authentication is something that we need down the line, but > it's not quite true that the changes it requires are trivial. Firstly, it > requires trust between servers (the authenticating server simply asserts > that the credentials presented by the client's server are valid.) > Furthermore it has routing issues. If I want to log in as [EMAIL PROTECTED] > on jabber.com, how does everyone know to route messages to jabber.com? This > seems to imply some kind of smart multi-hop routing, which we don't have.
OK, I see the above as two separate problems, not one that has to be taken in one lump. One, you have the distributed authentication, which as you say requires trust between the issuers (servers). I have been doing a good bit of thinking on this for the past few months as part of my Genio [ http://www.theoretic.com/genio ] project with Mike Hearn (formerly the Jabber Identity project). I have so far seen no way around this required trust between issuers, only ways to make it easier to manage (such as an intelligent web of trust and such). This can be done, however. The real trick is finding or creating a distributed auth system that can realistically be distributed on the Internet, not just corporate intranets. An example of this seems to be Kerberos, which really isn't ideal for an Internet environment. Mike Hearn is creating a distributed Authentication system made for the Internet over at Genio [ http://www.theoretic.com/genio ]. Take a look. The second issue is what I call "forwarding". After the server you are currently using gets authentication from your real server that you are who you say you are, it creates a temp JID such as "[EMAIL PROTECTED]". It then sends a command on your behalf to your real account "[EMAIL PROTECTED]" telling it to forward all messages to this temp account, much like how email forwarding works. The temp account also gets enough of your information from your real account to act like your real account (respond to IQ-Get's properly, etc...). > > All this can probably be done within one institution (one server farm) > because you have that trust between the servers and there is probably > already some kind of routing-resolving mechanism set up. But to have this > on the wider Jabber cloud is going to require more careful engineering and > strong crypto. > > -Mike > > > > |---------+----------------------------> > | | Al Sutton | > | | <[EMAIL PROTECTED]>| > | | Sent by: | > | | jdev-admin@jabber| > | | .org | > | | | > | | | > | | 01/10/2002 02:59 | > | | PM | > | | Please respond to| > | | jdev | > | | | > |---------+----------------------------> > >>------------------------------------------------------------------------------------------------------------------------------| > | > | > | To: [EMAIL PROTECTED] > | > | cc: > | > | Subject: Re: [JDEV] The Important Things > | > | > | > | > | > >>------------------------------------------------------------------------------------------------------------------------------| > > > > Why not add authentication and message relaying to the S2S protocol. > > This would give four advantages; > > 1. Any user could log into any machine and the server would relay the > authentication request to the relevant machine to handle authentication. > > 2. The messages for that user would be relayed to the server they are > logged in to and then forwarded on to them. > > 3. Clusters or farms could be constructed to server a a single jabber > community and the load shared between them. > > 4. This would only involve a change to the S2S protol and servers > supporting it (of which there are few), and would leave the C2S protocol > unchanged and thus not require any client changes. > > Comments? > > Al. > > On Thu, 2002-01-10 at 15:50, Ashvil wrote: > > > I found that we could use some kind of a gateway - > > > people connect to one server ( for example jabbber.org ) autheticate - > > > get a token/session id - and then continue with a server > > > l1.l4.dddljfds.jabbber.org that are real jabber servers. > > <snip> > > > > Any ideas that can help in scalability are welcome. If we can use a pool > of > > cheap PCs to build a scalable jabber network, then even more valuable > then > > having One big Server with Gigs of memory. > > > > This will require some changes in the Jabber protocol. The MSN protocol > does > > something like this, but takes this one step ahead by letting you connect > to > > any server in the pool, which then refers you to the right server that > can > > authenticate you. If you make logging in a two-step process, you can > solve > > this problem but that would mean changing all the Jabber clients and also > > the S2S communication in the Jabber server. > > > > Anyway, this is an area that the Jabber server developers are the best > folks > > to comment on. > > > > Regards, > > Ashvil > > > > _______________________________________________ > > jdev mailing list > > [EMAIL PROTECTED] > > http://mailman.jabber.org/listinfo/jdev > > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > > > > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev -- /\ Adam Theo, Age 22, Tallahassee FL USA //\\ Email & Jabber: [EMAIL PROTECTED] // \\ AIM: AdamTheo2000 ICQ: 3617306 =//====\\= MSN: [EMAIL PROTECTED] YIM: adamtheo2 // || \\ Theoretic Solutions: http://www.theoretic.com || "Bringing Ideas Together" || Jabber Protocol: http://www.jabber.org || "The Coolest IM on the Planet" || "A Free-Market Socialist Patriotic American Buddhist" Patriotic American Buddhist" _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
