On Thu Jan 21 03:48:41 2010, Jason Eacott wrote:
what I mean is that xmpp clients are the only entities with any power. they are the only entities that can interact with anything on a clients behalf. this is very different from the webserver paradigm where a user remotely logs in and then the server has power to BE the user, reuse other webservices as the logged in user (via any number of authentication schemes) etc.
Internally within a security domain, this is simply not the case. Within a security domain, servers can (and do, in some cases) act as the user.
A classic case is the widely deployed "auto accept/auto subscribe" feature in some servers, which sends out subscribe[d] stanzas per-pro the user.
With xmpp its also possible to use other webservices, but critically NOT xmpp services! its not possible for example for an xmpp plugin to access a users pubsub node, or private xml storage AS the owner unless the plugin knows the users id and password and opens its own client connection.
Again, this is only true if you're crossing the boundary of a security domain. Otherwise, no, pubsub code could reach into the XEP-0049 store authorized as the user - it's really only cross-boundary authorization and delegation that are missing.
In the specific case of an XMPP plugin (whatever that is) accessing a user's pubsub node in another security domain, then in principle the user could allow this by setting the affiliations suitably on the domain, or by the plugin simply requesting a subscription. This could, of course, be made smoother, with a pawn-ticket system to instantly grant the subscription, perhaps.
You cant use a bosh server with your existing xmpp account without giving it your user/pass details.
Well, there are currently two forms of BOSH server implemented, there's the built-in BOSH listeners of ejabberd, and Openfire (possibly others), and then there's the pure proxy style of Punjab.
With the former, handing over credentials is equivalent to handing them to the server anyway. With the latter, then the SASL exchange itself is passed through, so in principle, if a mechanism is used which is secure against MITM attacks, the credentials are safe. (In practise, most SASL mechanisms designed recently assume the presence of TLS, but it'd still require some effort on the part of a BOSH component operator to get your password).
It pains me to see all the cool xmpp component functionality about that I can only leverage from a client application. I dont know how this can best be resolved but I really think it needs to be. Allowing xmpp server level oauth style authentication could work, albeit a bit heavy, as might other strategies.
OAuth is fine for inter-domain authorization delegation, but it massive overkill within a domain.
FWIW, most servers support XEP-0114, and (I'm told) most servers have a way of trusting a component to send stanzas from a specific account. The missing part of this is that there's no method for getting a response - there are some obvious solutions here, but many of them aren't needed, since other inter-domain authentication mechanisms work just as well.
In summary, then, whilst I do agree there's some work to be done here, I really don't think it's nearly as bleak a picture as you're painting.
Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
