Page History

A lot of the object types and operations used in the ACL file are shared between the Java and C++ brokers and are non-contentious, since they represent actual objects that exist in AMQP - broker, queue, exchange and so forth. What appears to be at issue is how to permission extra funtionality in the broker, such as administration of user accounts or logging levels The C++ broker's 'METHOD' object is one mechanism, and results in ACL lines that specify a single method or set of methods that can be executed, and does not convey whether these are reading, writing or have other side effects on the broker. An example is shoen below:

ACL ALLOW adk UPDATE METHOD name=getLoggingLevel
ACL ALLOW adk UPDATE METHOD name=setLoggingLevel
ACL ALLOW adk UPDATE METHOD name=reloadLoggingConfig

This seems to be at the wrong level of abstraction. Looking at this in a general fashion, there are three things we wish to do to objects: get a property, set a property and execute an operation. These can be mapped to READ, WRITE, EXECUTE or GET, SET, INVOKE, ACCESS, UPDATE, ADMIN, and so on as operations. The next step would be to decide what the object type is that is being manipulated. I would be happy for this to be one of the existing AMQP objects, including BROKER, since this follows the existing pattern of permissions. Another point to note is that existing mechanisms such as JMX already have the conceptual split into these three types of action.

If we abandon the METHOD object in favour of existing object types, we still need to be able to permission such items as users and logging, and I propose these are made part of the broker object, with the possibility of adding other, vendor-specific extensions too. This would result in ACL lines as shown below, which would grant permission to view attributes of the logging subsystem, update those attributes and execute other administrative actions. Finally, if there is a management schema change and the names of methods used change, or new methods and attributes are added, the ACL file does not have to be changed, since the permissions relate to subsystems or extensions.

ACL ALLOW adk ACCESS BROKER extension=logging
ACL ALLOW adk UPDATE BROKER extension=logging
ACL ALLOW adk ADMIN BROKER extension=logging

or

ACL ALLOW adk ADMIN BROKER subsystem=acl

If we want to create an ACL file format that is usable across AMQP brokers, then the use of 'extension=<name>' or 'subsystem=<name>' with a set of pre-defined names, say 'logging', 'users', 'configuration', and a naming convention to prevent clashes, such as 'x-<vendor>-*' for vendor specific implementations or just 'x-*' for experimental extensions/subsystems seems appropriate.