Yeah I like it! I think it would also need to support a `kind` attribute to get specific about the subjects your talking about.
<allow kind="some.foo.UnixPrinciple" subject="app1_producers" action="create,destroy" object="*" id="app1.*"/> And since we support matching against any kind of principle, we have no guarantees that subject won't contain a ',' in it. So, we may have to use a `separator` attribute to enable ',' to delimit multiple subjects. Example: <allow separator="," kind="some.foo.UnixPrinciple" subject="app1_producers,app1_consumers" action="create,destroy" object="*" id="app1.*"/> I've opened up https://issues.apache.org/jira/browse/APLO-56 Regards, Hiram FuseSource Web: http://fusesource.com/ On Tue, Jun 21, 2011 at 6:27 AM, Lionel Cons <[email protected]> wrote: > Hiram, > > We discussed authorization several times and, AFAIK, what is currently in > Apollo does work and is complete (= allows fine tuning). > > However, when I try to put it in practice in our environment, I end up with > a huge messy XML file. > > Here is our (simple and real) use case, with only one application (app1): > - we only use groups for authorization > - the "admins" can do everything everywhere > - the "monitors" can send and receive messages for all destinations > starting with "monitor." (used to monitor the broker, using Nagios) > - the "app1_producers" can send messages to all destinations starting > with "app1." > - the "app1_consumers" can receive messages from all destinations > starting with "app1." > - everything which is not allowed is denied > > Here is the XML that I had to write to implement this use case. This is to > be included in the relevant <virtual_host> element: > > <!-- monitoring --> > <topic id="monitor.*"> > <acl> > <create allow="monitors"/> > <destroy allow="monitors"/> > <send allow="monitors"/> > <receive allow="monitors"/> > <create allow="admins"/> > <destroy allow="admins"/> > <send allow="admins"/> > <receive allow="admins"/> > </acl> > </topic> > <queue id="monitor.*"> > <acl> > <create allow="monitors"/> > <destroy allow="monitors"/> > <send allow="monitors"/> > <receive allow="monitors"/> > <consume allow="monitors"/> > <create allow="admins"/> > <destroy allow="admins"/> > <send allow="admins"/> > <receive allow="admins"/> > <consume allow="admins"/> > </acl> > </queue> > <dsub id="monitor.*"> > <acl> > <create allow="monitors"/> > <destroy allow="monitors"/> > <send allow="monitors"/> > <receive allow="monitors"/> > <consume allow="monitors"/> > <create allow="admins"/> > <destroy allow="admins"/> > <send allow="admins"/> > <receive allow="admins"/> > <consume allow="admins"/> > </acl> > </dsub> > > <!-- application 1 clients --> > <topic id="app1.*"> > <acl> > <create allow="app1_producers"/> > <create allow="app1_consumers"/> > <destroy allow="app1_producers"/> > <destroy allow="app1_consumers"/> > <send allow="app1_producers"/> > <receive allow="app1_consumers"/> > <create allow="admins"/> > <destroy allow="admins"/> > <send allow="admins"/> > <receive allow="admins"/> > </acl> > </topic> > <queue id="app1.*"> > <acl> > <create allow="app1_producers"/> > <create allow="app1_consumers"/> > <destroy allow="app1_producers"/> > <destroy allow="app1_consumers"/> > <send allow="app1_producers"/> > <receive allow="app1_consumers"/> > <consume allow="app1_consumers"/> > <create allow="admins"/> > <destroy allow="admins"/> > <send allow="admins"/> > <receive allow="admins"/> > <consume allow="admins"/> > </acl> > </queue> > <dsub id="app1.*"> > <acl> > <create allow="app1_producers"/> > <create allow="app1_consumers"/> > <destroy allow="app1_producers"/> > <destroy allow="app1_consumers"/> > <send allow="app1_producers"/> > <receive allow="app1_consumers"/> > <consume allow="app1_consumers"/> > <create allow="admins"/> > <destroy allow="admins"/> > <send allow="admins"/> > <receive allow="admins"/> > <consume allow="admins"/> > </acl> > </dsub> > > <!-- admins can do everything everywhere --> > <topic> > <acl> > <create allow="admins"/> > <destroy allow="admins"/> > <send allow="admins"/> > <receive allow="admins"/> > </acl> > </topic> > <queue> > <acl> > <create allow="admins"/> > <destroy allow="admins"/> > <send allow="admins"/> > <receive allow="admins"/> > <consume allow="admins"/> > </acl> > </queue> > <dsub> > <acl> > <create allow="admins"/> > <destroy allow="admins"/> > <send allow="admins"/> > <receive allow="admins"/> > <consume allow="admins"/> > </acl> > </dsub> > > This probably can be compressed a bit but this represents around 100 lines > of XML. Adding another application (like app1) would add around 50 lines. > > To make things worse, the non-security settings (e.g. slow_consumer_policy > for a topic) have to be inserted in the same place. This is good for the > broker (one lookup and you have all the settings for a destination) but not > for the human being that has to manage the configuration. > > As discussed some time ago, another approach would be to use what firewalls > (like iptables) do: a single list of rules. Our use case could be coded with > something like (again under <virtual_host>): > > <acl> > <allow subject="admins" action="*" object="*" id="*"/> > <allow subject="monitors" action="*" object="*" id="monitor.*"/> > <allow subject="app1_producers,app1_consumers" action="create,destroy" > object="*" id="app1.*"/> > <allow subject="app1_producers" action="send" object="*" id="app1.*"/> > <allow subject="app1_consumers" action="receive,consume" object="*" > id="app1.*"/> > <!-- next line would probably be implicit --> > <deny subject="*" action="*" object="*" id="*"/> > </acl> > > (what I called object is the resource type as queue|topic|dsub) > (each attribute="*" could be omitted) > > We end up with something much smaller, without duplication (cf. the admins > line in the big XML), easier to understand and very close to the English > specification. > > What do you think about this? > > Cheers, > > Lionel >
