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
whatever means).
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
remote.
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.
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
services...
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
password).
ok, for a pure client usage of bosh (javascript etc) this is true (as
long as you trust the javascript is talking directly to a bosh server,
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.
Dave.
I hope you are right. I will be very happy to discover what I missed :)
Thank for your input.
Jason.
