ACL Implementation

See also Method Considered Harmful and Method Considered Harmful Redux for discussion on the METHOD object type and its implications.

Use Cases

  1. 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.
  2. 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.
  3. 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.
  4. It should be possible for the addition of one access control rule to trigger the addition of other rules, to simplify creation of rulesets.
  5. 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, appropriate ACCESS VIRTUALHOST and BIND 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

  1. Whitespace is considered to be any ASCII byte with a value below 0x20, and is ignored when it occurs between tokens.
  2. 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
  3. 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.
  4. Quoted strings consist of any ASCII inside matching pairs of ''' or '"' (ASCII 0x27 and 0x22) characters, including any otherwise special characters.
  5. Tokens are NOT case sensitive, but quoted strings ARE.
  6. The '=' (ASCII 0x3d) character is special, and is used to indicate property value assignment.
  7. 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
  • No labels