Re: ACL file format.

[Martin Ritchie <ri...@apache.org>]

2008/7/31 Carl Trieloff <cc...@redhat.com>:
>
>
> Martin,
>
> wiki updated, and I have implemented something that maps to Java quite
> closely. take a look. Will
> be doing file reading next.
>
> Author: cctrieloff
> Date: Thu Jul 31 13:45:44 2008
> New Revision: 681479
>
> URL: http://svn.apache.org/viewvc?rev=681479&view=rev
> Log:
>
> - Implementation of ACL plugin
> - Apply ACL to Exchange, Queue, Binding, Subscribe
> - Follow Java ACL types, few added
>
> To complete the implementation of ACL the following items are remaining.
> - ACL on message transfer
> - ACL on MGNT commands
> - Reading ACL from File, into auth map.

Carl,

Great to see such quick progress on the CPP side.

Will try and get the Java converted ASAP but it will have to wait till post M3.

Yes I only meant that queue=* or * (user|group) entries were not
needed. The * notation will still be needed for queue patterns
queue=tmp* and especially routingkey=stocks.usd.ibm.* as it is in the
AMQP spec.

Just had two further thoughts.

1) We should look to standardise the error responses, what does the
NotAllowedExceptions cause to happen on the CPP broker? Currently I
believe it a '503 Not Authorised' channel close is sent to the client
on the Java side.

2) I've had requests in the past from users wanting IP based security,
I haven't pursued it much as I didn't think using IPs was very secure.
However, If you assume an environment where IP spoofing is unlikely
but an mistaken connection can be costly then I can see the merit.

I'm not sure what you would think but I know IBM MQ does IP based
restriction, my quick google didn't give me an example but what I was
thinking was this

user ritchiem limit-ip=10.10.10.10  # Limit user ritchiem to
connections from given IP
group users limit-if=eth0 # Limit group to connections on the given interface
acl allow all limit-subnet=255.255.0.0 # Limit allow alls to the
specified subnet.

The new limit-* property would provide a restriction on the user group
or acl and would have more than one mechanism of limitation. The
limit-* values that spring to mind are:
 - ip
 - if
 - subnet

What are peoples thoughts on this? I know IP based security isn't
super but it should make us similar in functionality to IBM MQ and
could prevent errors from users who have various environments
(dev,test,live) and what to try and prevent erroneous connections
between the environments.

This limit-* mechanism would of course (if the AMQP-WG adopted this
approach) allow for vendor extension in the acl functionality.

Cheers

Martin

-- 
Martin Ritchie

Re: ACL file format.

[Carl Trieloff <cc...@redhat.com>]

Martin Ritchie wrote:
> 2008/7/31 Carl Trieloff <cc...@redhat.com>:
>   
>> Martin,
>>
>> wiki updated, and I have implemented something that maps to Java quite
>> closely. take a look. Will
>> be doing file reading next.
>>
>> Author: cctrieloff
>> Date: Thu Jul 31 13:45:44 2008
>> New Revision: 681479
>>
>> URL: http://svn.apache.org/viewvc?rev=681479&view=rev
>> Log:
>>
>> - Implementation of ACL plugin
>> - Apply ACL to Exchange, Queue, Binding, Subscribe
>> - Follow Java ACL types, few added
>>
>> To complete the implementation of ACL the following items are remaining.
>> - ACL on message transfer
>> - ACL on MGNT commands
>> - Reading ACL from File, into auth map.
>>     
>
> Carl,
>
> Great to see such quick progress on the CPP side.
>
> Will try and get the Java converted ASAP but it will have to wait till post M3.
>
> Yes I only meant that queue=* or * (user|group) entries were not
> needed. The * notation will still be needed for queue patterns
> queue=tmp* and especially routingkey=stocks.usd.ibm.* as it is in the
> AMQP spec.
>
> Just had two further thoughts.
>
> 1) We should look to standardise the error responses, what does the
> NotAllowedExceptions cause to happen on the CPP broker? Currently I
> believe it a '503 Not Authorised' channel close is sent to the client
> on the Java side.
>   

correct, what do you use on the Java side?


> 2) I've had requests in the past from users wanting IP based security,
> I haven't pursued it much as I didn't think using IPs was very secure.
> However, If you assume an environment where IP spoofing is unlikely
> but an mistaken connection can be costly then I can see the merit.
>
> I'm not sure what you would think but I know IBM MQ does IP based
> restriction, my quick google didn't give me an example but what I was
> thinking was this
>
> user ritchiem limit-ip=10.10.10.10  # Limit user ritchiem to
> connections from given IP
> group users limit-if=eth0 # Limit group to connections on the given interface
> acl allow all limit-subnet=255.255.0.0 # Limit allow alls to the
> specified subnet.
>
> The new limit-* property would provide a restriction on the user group
> or acl and would have more than one mechanism of limitation. The
> limit-* values that spring to mind are:
>  - ip
>  - if
>  - subnet
>
> What are peoples thoughts on this? I know IP based security isn't
> super but it should make us similar in functionality to IBM MQ and
> could prevent errors from users who have various environments
> (dev,test,live) and what to try and prevent erroneous connections
> between the environments.
>
> This limit-* mechanism would of course (if the AMQP-WG adopted this
> approach) allow for vendor extension in the acl functionality.
>
>
>   

I have also had no requests for IP based limits, so maybe we start 
without it and if
it comes up we can do that on both brokers.

Carl.