You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Mark Moseley <mo...@gmail.com> on 2009/02/21 04:35:30 UTC
Federation and ACLs
I'll apologize in advance that I'm pretty new to QPid (and AMQP) in
general, so forgive the possibly n00b questions :)
I've been playing around with federation and reading through the Qpid
docs as well as the Redhat MRG docs. I can only seem to get it working
if I completely open up the ACL on the destination side, i.e. acl has
"acl allow-log all all"
When I send to the source broker, with a wide-open ACL, the message
gets dumped over to the dest broker just fine. Without "acl allow-log
all all" in my ACL, it gets denied. Looking at the logs on the dest
broker, there doesn't seem to be an 'id' associated with the publish,
even though it was authenticated on the source side. I'd have expected
that the 'id' showing up on the dest broker would either be the
authenticated sender ('mark' in this case) or the user used to create
the federation -- cleverly named 'router' in this case. I'm using the
same ACL file for both brokers and both 'mark' and 'router' have "acl
allow-log <username> all all", so they don't have any problem
performing actions on either broker (just a test bed).
The federation was created with a static route:
# qpid-route route add router/router@localhost:5672
router/router@localhost:5671 amq.direct mykey
On the source broker:
2009-feb-20 22:24:13 info ACL Allow id:mark@QPID action:publish
ObjectType:exchange Name:amq.direct
2009-feb-20 22:24:13 debug Message 0x80cc400 enqueued on
bridge_queue_1_ba641f59-76ef-48c2-875c-d05e6c5d2132[0x80cb538]
On the dest broker (with open ACL):
2009-feb-20 22:24:05 info Inter-broker link established to localhost:5671
2009-feb-20 22:24:13 info ACL Allow id: action:publish
ObjectType:exchange Name:amq.direct
On the dest broker (without a wide-open ACL):
2009-feb-20 22:32:04 info Inter-broker link established to localhost:5671
2009-feb-20 22:32:20 info ACL Deny id: action:publish
ObjectType:exchange Name:amq.direct
2009-feb-20 22:32:20 error Execution exception: not-allowed: cannot
publish to amq.direct with routing-key mykey
(qpid/broker/SemanticState.cpp:384)
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?
If not, is there some obvious configuration option I'm missing?
Thanks! And again, sorry for the possibly RTFM!
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Federation and ACLs
Posted by Mark Moseley <mo...@gmail.com>.
On Tue, Feb 24, 2009 at 3:35 PM, Mark Moseley <mo...@gmail.com> wrote:
> Excellent! I'll check it out ASAP. Thanks for the info as well.
>
Looks good. I agree that it's not a perfect (and definitely good for
the short-term), but it's definitely better than having to have a
default 'allow' to get federation working. That was a pretty speedy
patch, btw. Thanks!
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Federation and ACLs
Posted by Mark Moseley <mo...@gmail.com>.
>> 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.
Excellent! I'll check it out ASAP. Thanks for the info as well.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Federation and ACLs
Posted by Gordon Sim <gs...@redhat.com>.
Gordon Sim wrote:
> 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.
FYI: I've checked in a fix for this (r747507 on trunk).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Federation and ACLs
Posted by Gordon Sim <gs...@redhat.com>.
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
Re: Federation and ACLs
Posted by Mark Moseley <mo...@gmail.com>.
> Did you setup dynamic or static federation routes? Dynamic routes will
> require ACL to setup
> subscriptions on-demand which can be blocked via ACL. static would have then
> pre configured...
>
> There might be a case here for another action for dynamic links -- but lets
> try work through the details
> first. (are you doing dynamic or static federation routes ?)
>
This is with static routes. I haven't done any testing with dynamic
routes. It was created with:
# qpid-route route add router/router@localhost:5672
router/router@localhost:5671 amq.direct mykey
The actual message transfer seems to be working just fine (as long as
I set up a 'allow allow-log all all' ACL rule. With a default 'allow'
ACL, sending to the amq.direct exchange with the routing key of
'mykey' gets to the right queue on the destination broker. With
anything tighter, ACL-wise, it gets denied by the destination broker
when the publish action occurs, since according to the logs, it's
trying to do the publish action without an authenticated ID. I'd have
expected that when the destination broker goes to evaluate its ACLS
that either the user used to send the message to the source side (in
the log above, user 'mark') would be used -- either because the
setting up of the federated link would create some sort of trust
relation or by just sending along the original authentication
credentials -- or that it would use the user used to create the
federated link (user 'router' here). I'm assuming that there's some
option I'm missing, either in the 'route add' command or perhaps in
the message's delivery properties but I haven't yet been able to dig
up what that might be.
Thanks!
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Federation and ACLs
Posted by Carl Trieloff <cc...@redhat.com>.
Mark Moseley wrote:
> On Fri, Feb 20, 2009 at 7:35 PM, Mark Moseley <mo...@gmail.com> wrote:
>
>> I'll apologize in advance that I'm pretty new to QPid (and AMQP) in
>> general, so forgive the possibly n00b questions :)
>>
>> I've been playing around with federation and reading through the Qpid
>> docs as well as the Redhat MRG docs. I can only seem to get it working
>> if I completely open up the ACL on the destination side, i.e. acl has
>> "acl allow-log all all"
>>
>> When I send to the source broker, with a wide-open ACL, the message
>> gets dumped over to the dest broker just fine. Without "acl allow-log
>> all all" in my ACL, it gets denied. Looking at the logs on the dest
>> broker, there doesn't seem to be an 'id' associated with the publish,
>> even though it was authenticated on the source side. I'd have expected
>> that the 'id' showing up on the dest broker would either be the
>> authenticated sender ('mark' in this case) or the user used to create
>> the federation -- cleverly named 'router' in this case. I'm using the
>> same ACL file for both brokers and both 'mark' and 'router' have "acl
>> allow-log <username> all all", so they don't have any problem
>> performing actions on either broker (just a test bed).
>>
>> The federation was created with a static route:
>> # qpid-route route add router/router@localhost:5672
>> router/router@localhost:5671 amq.direct mykey
>>
>> On the source broker:
>> 2009-feb-20 22:24:13 info ACL Allow id:mark@QPID action:publish
>> ObjectType:exchange Name:amq.direct
>> 2009-feb-20 22:24:13 debug Message 0x80cc400 enqueued on
>> bridge_queue_1_ba641f59-76ef-48c2-875c-d05e6c5d2132[0x80cb538]
>>
>> On the dest broker (with open ACL):
>> 2009-feb-20 22:24:05 info Inter-broker link established to localhost:5671
>> 2009-feb-20 22:24:13 info ACL Allow id: action:publish
>> ObjectType:exchange Name:amq.direct
>>
>> On the dest broker (without a wide-open ACL):
>> 2009-feb-20 22:32:04 info Inter-broker link established to localhost:5671
>> 2009-feb-20 22:32:20 info ACL Deny id: action:publish
>> ObjectType:exchange Name:amq.direct
>> 2009-feb-20 22:32:20 error Execution exception: not-allowed: cannot
>> publish to amq.direct with routing-key mykey
>> (qpid/broker/SemanticState.cpp:384)
>>
>> 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?
>>
>> If not, is there some obvious configuration option I'm missing?
>>
>> Thanks! And again, sorry for the possibly RTFM!
>>
>>
>
>
> I probably ought to have mentioned that this is on the C++ broker,
> from the qpid-M4 distribution, with both brokers on localhost (one on
> port 5671, one on 5672).
Did you setup dynamic or static federation routes? Dynamic routes will
require ACL to setup
subscriptions on-demand which can be blocked via ACL. static would have
then pre configured...
There might be a case here for another action for dynamic links -- but
lets try work through the details
first. (are you doing dynamic or static federation routes ?)
Carl.
Re: Federation and ACLs
Posted by Mark Moseley <mo...@gmail.com>.
On Fri, Feb 20, 2009 at 7:35 PM, Mark Moseley <mo...@gmail.com> wrote:
> I'll apologize in advance that I'm pretty new to QPid (and AMQP) in
> general, so forgive the possibly n00b questions :)
>
> I've been playing around with federation and reading through the Qpid
> docs as well as the Redhat MRG docs. I can only seem to get it working
> if I completely open up the ACL on the destination side, i.e. acl has
> "acl allow-log all all"
>
> When I send to the source broker, with a wide-open ACL, the message
> gets dumped over to the dest broker just fine. Without "acl allow-log
> all all" in my ACL, it gets denied. Looking at the logs on the dest
> broker, there doesn't seem to be an 'id' associated with the publish,
> even though it was authenticated on the source side. I'd have expected
> that the 'id' showing up on the dest broker would either be the
> authenticated sender ('mark' in this case) or the user used to create
> the federation -- cleverly named 'router' in this case. I'm using the
> same ACL file for both brokers and both 'mark' and 'router' have "acl
> allow-log <username> all all", so they don't have any problem
> performing actions on either broker (just a test bed).
>
> The federation was created with a static route:
> # qpid-route route add router/router@localhost:5672
> router/router@localhost:5671 amq.direct mykey
>
> On the source broker:
> 2009-feb-20 22:24:13 info ACL Allow id:mark@QPID action:publish
> ObjectType:exchange Name:amq.direct
> 2009-feb-20 22:24:13 debug Message 0x80cc400 enqueued on
> bridge_queue_1_ba641f59-76ef-48c2-875c-d05e6c5d2132[0x80cb538]
>
> On the dest broker (with open ACL):
> 2009-feb-20 22:24:05 info Inter-broker link established to localhost:5671
> 2009-feb-20 22:24:13 info ACL Allow id: action:publish
> ObjectType:exchange Name:amq.direct
>
> On the dest broker (without a wide-open ACL):
> 2009-feb-20 22:32:04 info Inter-broker link established to localhost:5671
> 2009-feb-20 22:32:20 info ACL Deny id: action:publish
> ObjectType:exchange Name:amq.direct
> 2009-feb-20 22:32:20 error Execution exception: not-allowed: cannot
> publish to amq.direct with routing-key mykey
> (qpid/broker/SemanticState.cpp:384)
>
> 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?
>
> If not, is there some obvious configuration option I'm missing?
>
> Thanks! And again, sorry for the possibly RTFM!
>
I probably ought to have mentioned that this is on the C++ broker,
from the qpid-M4 distribution, with both brokers on localhost (one on
port 5671, one on 5672).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org