2008/7/22 Carl Trieloff <[EMAIL PROTECTED]>: > > Martin, > > I found the permissions etc and that seems fine. I agree with that negative > permissions would be nice to add. > > One thing I did not like at first sight was the ACL in XML file. It is very > verbose > and hard to read to do very little. That would be the one thing I would be > highly > tempted to change to a more editable/readable format. (no ideas yet) > > I was thinking to create an ACL plugin interface, we could support the same > rules. I would > like to have a more compact file format for the file plug-in, and then would > also > like to write a plug-in for centralized ACL management (from IPA / AD etc) > > thoughts on trying for a more readable/compact ACL format?
How about something like the following: [allow|deny] [permission] [queue=<queuename>] [exchange=<exchangename>] [routingkey=<routingkey>] [user=<userlist>] [group=<grouplist>] This is loosely based on how httpd set up ACLs. My thought here would be that the ACL file could be potentially processed by some CLI tool as well as being read on startup. qpid-acl allow create queue=example.queue user=guest qpid-acl allow consume queue=example.queue user=guest So the order in the file would have an impact, I'm not sure if this makes things more complicated in terms of quickly looking at a file. I think this is a reasonable approach as this would then allow you to add an 'allow ALL' or 'deny ALL' default to the top of the file. If the ACLs were all self contained then any potential CLI tool could do a --reload <file> on acl change. The tricky bit from the Java side is the fact that we always Create and Bind an exchange and queue when we consume, but that is something we can deal with locally to the java as an aside to the ACL configuration. The key-value pair approach allows for more complex ACLs based on the broker suport qpid-acl allow create queue=* temporary=true durable=false user=guest qpid-acl allow bind queue=* exchange=amq.topic routingkey=stocks.ibm.# owner=<self> user=guest qpid-acl allow consume queue=<self> user=guest There are a few pieces of nomenclature we need to agree on: permissions objects (queue,exchange, rkey...) users (user, group,role?) properties(temporary,durable,owner) and there may also be special value cases such as the <self> and * values above in the allow bind that need to be ironed out more. Perhaps one way to proceed with this is to define a series of use cases to focus our efforts on real world cases. My intention with the three line example above is, in JMS terms, to allow the user to consume from topic 'stocks.ibm.#'. They are limited to creating temporary, non-durable queues that can only be bound to amq.topic with the set topic. In addition they are unable to bind or consume from any queue that they did not create. Would more examples like this be a useful approach or for this? Alternatively, would providing more details on what effect each permission would have and how it would be used in the real world be more beneficial? Thoughts and comments Martin > Carl. > > > Martin Ritchie wrote: >> >> Hi Carl, >> >> Have been out on holiday the last few days. I've been trying to find >> some time to put up some documentation about the ACLs that have been >> started on the Java Broker. >> >> The various permissions in the Java broker >> (server.security.access.Permission) have not all been implemented. The >> focus was to provide a business friendly configuration so that end >> users did not need to know if someone should have bind or unbind >> permissions. >> >> One thing that is currently missing from the configuration is the >> ability to have 'Negative Permissions', It would be good to be able to >> state that user X is not allowed ACCESS to Virtualhost Y, rather than >> specifying all the users that ARE allowed ACCESS to Virtualhost Y. >> >> It would be good if we could co-ordinate to ensure we have >> interoperable configuration between the Qpid brokers. This would be >> beneficial for our users as they would not need to worry about >> converting any config between brokers. It would also make testing a >> lot easier as we can write an ACL test in a client along with a >> configuration which we can then instruct the target broker to run >> with. Currently the Java SimpleACLTest only provides the configuration >> to the InVM broker but it would be a logical next step to convert it >> to use the QpidTestCase model. For this to work however we would need >> to provide the ACL configuration hence if it was the same config for >> all Qpid Brokers then it would make that testing much simpler. >> >> Having looked through what the Java does do you have any comments / >> feedback? I don't know of anyone that is using this functionality yet >> so before it is documented and then potentially used it would be good >> to come to a solution that we are all happy to use in the Qpid >> Brokers. >> >> Regards >> >> Martin >> >> 2008/7/22 Carl Trieloff <[EMAIL PROTECTED]>: >> >>> >>> I have worked through the Java code and it looks like we can just re-use >>> what it does for C++ broker >>> also for ACL. Those that worked on it, was there anything lacking or you >>> wish was different? >>> >>> >>> Carl Trieloff wrote: >>> >>>> >>>> I understand that the Java broker has some sort of RBAC implemented. Are >>>> there any notes >>>> so that we can copy / extend / crib ... the scheme for C++ broker. >>>> >>>> Thanks >>>> Carl. >>>> >>> >>> >> >> >> >> > > -- Martin Ritchie
