You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Carl Trieloff <cc...@redhat.com> on 2008/07/30 21:29:28 UTC

ACL file format.

please review/ comment etc, Ted and I have worked through it.

http://cwiki.apache.org/confluence/display/qpid/ACL

Carl.

Re: ACL file format.

Posted by 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.

Re: ACL file format.

Posted by 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.

Posted by 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.

Re: ACL file format.

Posted by Carl Trieloff <cc...@redhat.com>.
Martin Ritchie wrote:
> 2008/7/30 Carl Trieloff <cc...@redhat.com>:
>   
>> please review/ comment etc, Ted and I have worked through it.
>>
>> http://cwiki.apache.org/confluence/display/qpid/ACL
>>
>> Carl.
>>     
>
> Carl/Ted,
>
> Looks good, just a few points on what is there. I was going to edit
> the wiki then thought we should discuss first.
> The wiki currently isn't consistent with the positioning of permission
> and user|group but I think you were after  'permission
> <group-name|user-name>' rather than the other way around as the
> examples show.
>
> I think we need to add some implementation detail/guidance so that the
> functionality on all our brokers is equivalent.
>
> I shall try and find some time to add such detail but the example that
> is in my head is that a passive declare queue|exchange should not be
> denied by the acls.
>
> We want to make it easy and understandable for non-tech-business
> people to understand how to configure these controls.
>
> i.e. I want to allow user Ux to publish to queue Qx and user Uy to
> consume from Qy
>
> Perhaps an example file would be sufficient but I don't think we
> should need end users to know about the AMQP specifics of exchanges
> and bindings. That is not to say some users may wish that
> expressiveness I think in 99% of the user cases users will want
> controls similar to other messaging products that talk in terms of
> Queues and Topics.
>
> Having an example file with entries that describe the AMQP feature and
> how to safely default them would probably suffice.
>
> i.e. for a request response application such as is used by the current
> Java SimpleACLTest.
>
> acl allow bind owner=self
> acl allow consume owner=self
> acl allow publisher publish temporary=true
> acl allow publisher create queue=RequestQueue
>
> acl allow consumer consume temporary=true
> acl allow consumer create temporary=true
> acl deny
>
> Having written that out I don't think we need the * values. Can we not
> just assume * for all values that are not present. This would also
> avoid the confusion with:
> acl deny all
>
> is that 'all' the group-name|user-name with no permissions, a special
> permissions with no user|group?
>
> I think you were going for the latter but that would mean the user has
> been defaulted to all users. In which case can we not use the same
> defaulting with the other permissions?
>
>
> So updating the acl line from the wiki to read:
> {code}
> acl permission [<group-name|user-name>] [action]
> [object=<object-name>] [property = <property-value>]
> {code}
>
>
> as always comments welcome
>
> Martin
>
>
>   

yes, good comments- let's update the wiki

One questions, don't we still the * for a rule like

acl allow consumer bind queue=stock.buy.*


Carl.

Re: ACL file format.

Posted by Martin Ritchie <ri...@apache.org>.
2008/7/30 Carl Trieloff <cc...@redhat.com>:
>
> please review/ comment etc, Ted and I have worked through it.
>
> http://cwiki.apache.org/confluence/display/qpid/ACL
>
> Carl.

Carl/Ted,

Looks good, just a few points on what is there. I was going to edit
the wiki then thought we should discuss first.
The wiki currently isn't consistent with the positioning of permission
and user|group but I think you were after  'permission
<group-name|user-name>' rather than the other way around as the
examples show.

I think we need to add some implementation detail/guidance so that the
functionality on all our brokers is equivalent.

I shall try and find some time to add such detail but the example that
is in my head is that a passive declare queue|exchange should not be
denied by the acls.

We want to make it easy and understandable for non-tech-business
people to understand how to configure these controls.

i.e. I want to allow user Ux to publish to queue Qx and user Uy to
consume from Qy

Perhaps an example file would be sufficient but I don't think we
should need end users to know about the AMQP specifics of exchanges
and bindings. That is not to say some users may wish that
expressiveness I think in 99% of the user cases users will want
controls similar to other messaging products that talk in terms of
Queues and Topics.

Having an example file with entries that describe the AMQP feature and
how to safely default them would probably suffice.

i.e. for a request response application such as is used by the current
Java SimpleACLTest.

acl allow bind owner=self
acl allow consume owner=self
acl allow publisher publish temporary=true
acl allow publisher create queue=RequestQueue

acl allow consumer consume temporary=true
acl allow consumer create temporary=true
acl deny

Having written that out I don't think we need the * values. Can we not
just assume * for all values that are not present. This would also
avoid the confusion with:
acl deny all

is that 'all' the group-name|user-name with no permissions, a special
permissions with no user|group?

I think you were going for the latter but that would mean the user has
been defaulted to all users. In which case can we not use the same
defaulting with the other permissions?


So updating the acl line from the wiki to read:
{code}
acl permission [<group-name|user-name>] [action]
[object=<object-name>] [property = <property-value>]
{code}


as always comments welcome

Martin


-- 
Martin Ritchie