qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: ACL file format.
Date Fri, 01 Aug 2008 11:50:29 GMT
Martin Ritchie wrote:
> 2008/7/31 Carl Trieloff <cctrieloff@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.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message