You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2009/12/07 18:16:01 UTC
IP white-lists for brokers
Hi All,
Currently the Java broker implements IP white-lists where using
firewall rules is not an option.
http://qpid.apache.org/ip-whitelisting.html
There is an email on the user list which has a similar requirement,
where a certain user is allowed to connect via an approved list of IP
addresses.
It seem to me this requirement is best handled via the ACL mechanism.
However I'd like to see similar functionality/behaviour implemented by
our brokers for a given requirement where possible.
The Java brokers ip-whitelisting feature is standalone atm.
So wondering if there is any interest in combining with the ACL, or
why it wasn't done that way as it maybe due to some factors that I
have overlooked.
Also irrespective of how it's implemented I am keen to have the same
test cases against both brokers to ensure we share the effort.
Thoughts/suggestions are most welcomed.
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: IP white-lists for brokers
Posted by Marnie McCormack <ma...@googlemail.com>.
Existing users of the ACLs have had to suffer quite a bit (see the JIRAs
fixed in the last couple of releases), thus my impression is that
there is/was a real motivation for not making big changes there.
We need to maintain (at least) backward compatibility so that we don't cause
users with production ACLs migration/test overhead.
I don't have any objection with the idea of bringing the ACLs together, but
for me the big caveat is test coverage since that was the issue (really)
with the old ACLs.
Marnie
On Mon, Dec 7, 2009 at 7:59 PM, Carl Trieloff <cc...@redhat.com> wrote:
> Aidan Skinner wrote:
>
>> On Mon, Dec 7, 2009 at 5:16 PM, Rajith Attapattu <ra...@gmail.com>
>> wrote:
>>
>>
>>
>>> However I'd like to see similar functionality/behaviour implemented by
>>> our brokers for a given requirement where possible.
>>> The Java brokers ip-whitelisting feature is standalone atm.
>>> So wondering if there is any interest in combining with the ACL, or
>>> why it wasn't done that way as it maybe due to some factors that I
>>> have overlooked.
>>> Also irrespective of how it's implemented I am keen to have the same
>>> test cases against both brokers to ensure we share the effort.
>>>
>>>
>>
>> Martin and I kicked about the idea of integrating the two at one
>> point, but didn't due to logistical problems with the current ACL
>> implementation in the Java broker. It seemed to make more sense to do
>> it as an extension to the shared ACL format, but that patch never
>> quite seems to go in.
>>
>> Adding in a "from <netmask/hostname>" would be pretty simple syntax
>> wise, and similar to what things like PostgreSQL do. It's a shame the
>> @ syntax is already taken, but nm.
>>
>> Something like this perhaps?
>>
>> acl allow user from localhost
>> acl allow user from 192.168.1.1/24
>>
>>
>>
>
> yes, following the format for acl below would be very intuitive and not
> introduce another
> mechanism to that would have to be documented.
>
> Carl.
>
>
>
Re: IP white-lists for brokers
Posted by Carl Trieloff <cc...@redhat.com>.
Aidan Skinner wrote:
> On Mon, Dec 7, 2009 at 5:16 PM, Rajith Attapattu <ra...@gmail.com> wrote:
>
>
>> However I'd like to see similar functionality/behaviour implemented by
>> our brokers for a given requirement where possible.
>> The Java brokers ip-whitelisting feature is standalone atm.
>> So wondering if there is any interest in combining with the ACL, or
>> why it wasn't done that way as it maybe due to some factors that I
>> have overlooked.
>> Also irrespective of how it's implemented I am keen to have the same
>> test cases against both brokers to ensure we share the effort.
>>
>
> Martin and I kicked about the idea of integrating the two at one
> point, but didn't due to logistical problems with the current ACL
> implementation in the Java broker. It seemed to make more sense to do
> it as an extension to the shared ACL format, but that patch never
> quite seems to go in.
>
> Adding in a "from <netmask/hostname>" would be pretty simple syntax
> wise, and similar to what things like PostgreSQL do. It's a shame the
> @ syntax is already taken, but nm.
>
> Something like this perhaps?
>
> acl allow user from localhost
> acl allow user from 192.168.1.1/24
>
>
yes, following the format for acl below would be very intuitive and not
introduce another
mechanism to that would have to be documented.
Carl.
Re: IP white-lists for brokers
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Dec 7, 2009 at 2:54 PM, Aidan Skinner <ai...@gmail.com> wrote:
> On Mon, Dec 7, 2009 at 5:16 PM, Rajith Attapattu <ra...@gmail.com> wrote:
>
>> However I'd like to see similar functionality/behaviour implemented by
>> our brokers for a given requirement where possible.
>> The Java brokers ip-whitelisting feature is standalone atm.
>> So wondering if there is any interest in combining with the ACL, or
>> why it wasn't done that way as it maybe due to some factors that I
>> have overlooked.
>> Also irrespective of how it's implemented I am keen to have the same
>> test cases against both brokers to ensure we share the effort.
>
> Martin and I kicked about the idea of integrating the two at one
> point, but didn't due to logistical problems with the current ACL
> implementation in the Java broker. It seemed to make more sense to do
> it as an extension to the shared ACL format, but that patch never
> quite seems to go in.
>
> Adding in a "from <netmask/hostname>" would be pretty simple syntax
> wise, and similar to what things like PostgreSQL do. It's a shame the
> @ syntax is already taken, but nm.
>
> Something like this perhaps?
>
> acl allow user from localhost
> acl allow user from 192.168.1.1/24
Yep, seems more intuitive.
I hope you and Martin could at some point get this going.
> - Aidan
>
> --
> Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
> "A witty saying proves nothing" - Voltaire
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: IP white-lists for brokers
Posted by Aidan Skinner <ai...@gmail.com>.
On Mon, Dec 7, 2009 at 5:16 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> However I'd like to see similar functionality/behaviour implemented by
> our brokers for a given requirement where possible.
> The Java brokers ip-whitelisting feature is standalone atm.
> So wondering if there is any interest in combining with the ACL, or
> why it wasn't done that way as it maybe due to some factors that I
> have overlooked.
> Also irrespective of how it's implemented I am keen to have the same
> test cases against both brokers to ensure we share the effort.
Martin and I kicked about the idea of integrating the two at one
point, but didn't due to logistical problems with the current ACL
implementation in the Java broker. It seemed to make more sense to do
it as an extension to the shared ACL format, but that patch never
quite seems to go in.
Adding in a "from <netmask/hostname>" would be pretty simple syntax
wise, and similar to what things like PostgreSQL do. It's a shame the
@ syntax is already taken, but nm.
Something like this perhaps?
acl allow user from localhost
acl allow user from 192.168.1.1/24
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org