ACL Implementation
See also Method Considered Harmful and Method Considered Harmful Redux for discussion on the METHOD object type and its implications.
Use Cases
- Allow access to broker functions to be controlled by an ACL, with the checks being carried out independantly of the mechanism used to access the broker. This would mean that a single
CREATE QUEUE
permission would apply whether the queue was created when a user logged in and used it, or if that user connected to the broker via JMX or QMF and used the management operations to create the queue. - Permissions must be definable at a virtualhost level, with fallback to global permissions. This allows access to be granted for operations only on a certain host, while global operations such as broker administration can be defined at the global level. It also allows default behaviour to be specified globally and then overridden on a per-host basis.
- The ACL mechanism controls access to operations on particular objects for all users, if at least one user has a rule controlling access to that operation on that type of object. This means that all users requiring access to a particular operation must be configured. The default behaviour will be to deny access.
- It should be possible for the addition of one access control rule to trigger the addition of other rules, to simplify creation of rulesets.
- The behaviour of the access control mechanism should be configurable.
Plugin interaction
The plugins can return four different values - ALLOWED, DENIED, ABSTAIN and DEFER. Since we can have two plugins of the same type looking at a particular access request, one for the virtual host and the other for global, the reults ineract as follows:
Host |
Global |
Result |
---|---|---|
ALLOWED |
any |
ALLOWED |
DENIED |
any |
DENIED |
ABSTAIN |
ALLOWED |
ALLOWED |
ABSTAIN |
DENIED |
DENIED |
ABSTAIN |
ABSTAIN |
ABSTAIN |
ABSTAIN |
DEFER |
global |
ABSTAIN |
none |
ABSTAIN |
DEFER |
ALLOWED |
ALLOWED |
DEFER |
DENIED |
DENIED |
DEFER |
ABSTAIN |
host |
DEFER |
DEFER |
global |
DEFER |
none |
host |
The host and global entries in the Result column indicate that the default answer for that plugin should be returned.
ACL File
The access control file consists of a series of rules, describing the permissions granted to users or groups for operations on object types, with specific properties. these are all restricted to certain values, as illustrated by the following lists of tokens:
Permission
ALLOW, ALLOW_LOG, DENY, DENY_LOG
Operation
ALL, CONSUME, PUBLISH, CREATE, ACCESS, CONNECT, BIND, UNBIND, DELETE, PURGE, UPDATE, (ADMIN ?)
ObjectType
ALL, VIRTUALHOST, QUEUE, TOPIC, EXCHANGE, BROKER, LINK, ROUTE, METHOD, (USER, LOG, CONFIG ?)
ObjectProperty
ROUTING_KEY, NAME, QUEUE_NAME, OWNER, TYPE, ALTERNATE, INTERNAL, NO_WAIT, NO_LOCAL, NO_ACK, PASSIVE, DURABLE, EXCLUSIVE, TEMPORARY, AUTO_DELETE
The ObjectProperties are keys that are listed as key = value
pairs after an Operation/ObjectType combination. They must be in this format; a lone string is not accepted here. This is to make the ACL entries less ambiguous.
Allowed Combinations
The object types and operations are related, with only certain combinations allowed. The table below lists allowed combinations with y
. The rows contain ObjectTypes and the columns Operations.
|
CONSUME |
PUBLISH |
CREATE |
ACCESS |
BIND |
UNBIND |
DELETE |
PURGE |
UPDATE |
EXECUTE |
---|---|---|---|---|---|---|---|---|---|---|
VIRTUALHOST |
|
|
|
y |
|
|
|
|
|
|
QUEUE |
y |
|
y |
|
|
|
y |
y |
|
|
TOPIC |
y |
|
y |
|
|
|
y |
|
|
|
EXCHANGE |
|
y |
y |
|
y |
y |
y |
|
|
|
BROKER |
|
|
|
y |
|
|
|
|
|
|
LINK |
|
|
|
|
|
|
|
|
|
|
ROUTE |
|
|
|
|
|
|
|
|
|
|
METHOD |
|
|
|
y |
|
|
|
|
y |
y |
OBJECT |
|
|
|
y |
|
|
|
|
|
|
See Method Considered Harmful Redux for more information on how METHOD and OBJECT are intended to work.
ACL Configuration
These are true/false properties that can be specified to confgure the ACL mechanism further, and would be added to the start of an ACL file.
- transitive If true, the creation of ACLS, so that if, e.g.
CREATE QUEUE
is permissioned, appropriateACCESS VIRTUALHOST
andBIND EXCHANGE
permissions would also be added. - defaultdeny Sets the default result to
DENIED
if true. - defaultallow Sets the default result to
ALLOWED
if true. - expand Expands synthetic objects, such as
TOPIC
if true. - controlled If there are no access controls on a particular object and operation, the result should be to abstain, wheras if the controlled configuration property is true, the requestshould be denied.
Syntax
- Whitespace is considered to be any ASCII byte with a value below 0x20, and is ignored when it occurs between tokens.
- Continuations using the '\' character (ASCII 0x5c) are allowed anywhere on a line, and can consist of a blank line with a continuation character as the lat non-whitespace token
- Comments are line-style comments, and any text after an un-quoted '#' (ASCII 0x23) are ignored, including continuations. The '#' charater may appear in a quoted string.
- Quoted strings consist of any ASCII inside matching pairs of ''' or '"' (ASCII 0x27 and 0x22) characters, including any otherwise special characters.
- Tokens are NOT case sensitive, but quoted strings ARE.
- The '=' (ASCII 0x3d) character is special, and is used to indicate property value assignment.
- Wildcards are specified using the '*' (ASCII 0x2a) character in a property value string, which may be quoted.
The declarations are as follows, using some kind of grammar, with + and * having the usual regular expression meanings, parenthesis denote grouping and brackets denote optional elements.
CONFIG ( <config-property> '=' <TRUE | FALSE> ) + GROUP <group-name> ( <username | group-name> ) + [ <number> ] ACL <permission> <username | group-name | ALL> <operation> [ <object-type> ( <property-name> '=' <property-value> ) * ]
This allows a rather looser and more readable style for ACL files, while still retaining the ability to read the stricter files accepted by the C++ broker. Bear in mind that the group declarations are to be deprecated, in favour of an external directory service, using a plugin mechanism.
The initial <number> is used to allow rulesets to be created which allow indicidual rules to be enabled and disabled using an admin interface, and an ACL file using numbered lines would be restricted to having increasing numbers per rule, although gaps would be allowed to enable rules to be inserted later, again using an admin interface. This administrative interface would also allow saving of a modified ruleset and re-loading.
Examples
Allow "adk@iterator.co.uk" Create Queue \ Owner="adk@iterator.co.uk" Routingkey = "chocolate biscuits" \ QueueName="kitten.*"
# allow adk to create queues Allow "adk@iterator.co.uk" Create Queue \ Owner = "adk@iterator.co.uk" \ Routingkey = "chocolate biscuits" \ QueueName=kitten
# allow adk access to this virtual host 110 ALLOW "adk@iterator" ACCESS VIRTUALHOST # allow creating temporary queues and queues with names matching adk.* 210 ALLOW-LOG \ "adk@iterator" BIND EXCHANGE \ routingKey="adk.*" \ name="amq.direct" # allow adk.* queue bind to amq.direct 220 \ ALLOW-LOG "adk@iterator" BIND EXCHANGE \ routingKey="tmp.*" name="amq.direct" 230 ALLOW "adk@iterator" CREATE QUEUE name="adk.*" owner="adk@iterator" 240 ALLOW "adk@iterator" CREATE QUEUE temporary="true" owner="adk@iterator" # allow publish and consume of messages on the queues 310 ALLOW "adk@iterator" CONSUME QUEUE name="adk.*" 315 ALLOW "adk@iterator" PUBLISH QUEUE routingkey="adk.export#extra" # foo 320 ALLOW "adk@iterator" PUBLISH QUEUE name="adk.*" # default deny 910 DENY ANY ALL ALL