qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Federation and ACLs
Date Mon, 23 Feb 2009 10:48:31 GMT
Mark Moseley wrote:
> My question is: is that a normal consequence of federation, i.e. that
> credentials aren't passed around and that neither the authenticated
> sender nor the user used to create the static route is used as the
> 'id' on the dest side?

That is a defect in the current implementation[1]. The destination 
broker opens a connection to the source broker and this connection is 
authenticated using the username/password supplied for the source broker 
in the qpid-route arguments.

The problem at present is that the destination broker doesn't have an 
identity associated with the connection, so when transfers come in 
response to the subscription set up for a bridge, no userid is available 
for testing permissions (or rather the empty string is used).

A short-term fix is just to use the userid with which that connection 
authenticated itself to the source broker. That will get around the 
immediate problem, but it does mean that the source broker needs to be 
trusted (it hasn't been authenticated to the source broker, the source 
broker has been authenticated to it). SSL can be used if that trust 
needs to be made explicit.

GSSAPI authentication would also server. Unfortunately only anonymous 
and plain are currently supported as mechanisms for inter-broker 
links[2]. That will also be fixed shortly I hope.

(By way of clarification on a related point, the original sender may 
include their userid in each published message. This will be verified by 
the first broker to receive it (i.e. the specified userid will be 
checked against the connections authenticated id). Once that broker has 
accepted it however, subsequent brokers in any federation routes assume 
the identity of the original publisher to be already checked. Provided 
that all the brokers through which the message passes are trusted, the 
publisher id can be relied on by the final receiver of the message).

[1] https://issues.apache.org/jira/browse/QPID-1671
[2] https://issues.apache.org/jira/browse/QPID-1672

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

View raw message