[Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
jason at hardlight.com.au
Thu Jan 21 12:06:14 UTC 2010
to be clear I am talking about cross domain, because I dont think its
reasonable for every new service/component/whatever to require users to
create new accounts on the local domain should that service require the
use of third party services.
By plugin I mean server component or vendor specific plugin (by
Dave Cridland wrote:
> 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.
ok maybe I wildly misunderstand xmpp?(its definitely possible).
If I have an xmpp server at somewhere.com, and install a pubsub
component and a personal xml component at pubsub.somewhere.com and
xml.somewhere.com and my own new service at new.somewhere.com, are you
saying that new.somewhere.com can access xml.somewhere.com on behalf of
any user registered at somewhere.com?
even so, this is a very limited case as most users of my service will be
>> 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
> 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.
does this boundary include subdomains? I thought it did in which case
components are generally unavailable for reuse by other components.
> 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.
this is true, but requires serious intervention by the user. My service
wants to create a pubsub node for its own use, but its preferable that
the currently interacting (and probably remote domain) user own the
node(for whatever reason). Its not possible without the user correctly
creating their own node and configuring it appropriately. this is pretty
unreasonable request to make of my users I think - and if I need 6 other
also pubsub is about the only xep with such rich auth control anyway.
>> 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
but for something like a serverside impl of a web ui chatroom, which
itself uses bosh to connect to the xmpp network (or even just direct
connect) then you have to give the webui provider your xmpp credentials
first. if xmpp supported some extra (pluggable, extensible) auth scheme
then this could be mitigated.
the alternative which exists now is to use XEP-0235 oauth but it would
require that the chatroom component in use is itself an oauth producer.
>> 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.
agreed - and I'm not saying the answer is oauth, its just 1 way I know
that could work (albeit not great).
oauth is overkill in xmpp in general, but it does provide a workable
model for thinking about.
> 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.
I dont know how to send stanzas from a component as an arbitrary user
from an account of another domain. please tell me how! this is exactly
what I need. (in my experience the stanza is sent but the recipient
server rejects it, as it should).
> 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.
I hope you are right. I will be very happy to discover what I missed :)
Thank for your input.
More information about the Standards