Page History

...

This document is updated for release 0.1620.

Contents

...

user = username[/domain[@realm]]
user-list = user1 user2 user3 ...
group-name-list = group1 group2 group3 ...

group <group-name> = [user-list] [group-name-list]

permission = [allow|allow-log|deny|deny-log]
action = [consume|publish|create|access|bind|unbind|delete|purge|update]
object = [virtualhost|queue|exchange|broker|link|route|method]
property = [name|durable|owner|routingkey|passive|autodelete|exclusive|type|alternate|queuename|
            policytype|schemapackage|schemaclass|
            queuemaxsizelowerlimit|queuemaxsizeupperlimit|
            queuemaxcountlowerlimit|queuemaxcountupperlimit|
            filemaxsizelowerlimit|filemaxsizeupperlimit|
            filemaxcountlowerlimit|filemaxcountupperlimit]

acl permission {<group-name>|<user-name>|"all"} {action|"all"} [object|"all" [property=<property-value>]]

...

• The minimum matching criteria for all ACL rules are:
  • An actor (individually named or group memberuser (name of an individual or of a group)
  • An action
  • An object
• If a rule does not match the minimum criteria then that rule does not control the ACL decision.
• ACL rules optionally specify object names and property values:
  • If an object is named and/or property values are specified in an ACL rule then all of them must match to cause the rule to match.

# Example of rule matching
#
# Using this ACL file content:

(1)  acl deny bob create exchange name=test durable=true passive=true
(2)  acl deny bob create exchange name=myEx type=direct
(3)  acl allow all all

#
# Lookup 1. id:bob action:create objectType:exchange name=test {durable=false passive=false type=direct alternate=}
#
# ACL Match Processing:
#  1. Rule 1 passes minimum criteria with user bob, action create, and object exchange.
#  2. Rule 1 matches name=test.
#  3. Rule 1 does not match the rule's durable=false with the requested lookup of durable=true.
#  4. Rule 1 does not control the decision and processing continues to Rule 2.
#  5. Rule 2 passes minimum criteria with user bob, action create, and object exchange.
#  6. Rule 2 does not match the rule's name=myEx with the requested lookup of name=test.
#  7. Rule 2 does not control the decision and processing continues to Rule 3.
#  8. Rule 3 matches everything and the decision is 'allow'.
#
# Lookup 2. id:bob action:create objectType:exchange name=myEx {durable=true passive=true type=direct alternate=}
#
# ACL Match Processing:
#  1. Rule 1 passes minimum criteria with user bob, action create, and object exchange.
#  6. Rule 1 does not match the rule's name=test with the requested lookup of name=myEx.
#  4. Rule 1 does not control the decision and processing continues to Rule 2.
#  5. Rule 2 passes minimum criteria with user bob, action create, and object exchange.
#  2. Rule 2 matches name=myEx.
#  3. Rule 2 matches the rule's type=direct with the requested lookup of type=direct.
#  8. Rule 2 matches everything and the decision is 'deny'.
#

• C++ Broker release 0.16 introduces new rule matching criteria.
  • Certain rule properties are introduced that constrain settings from exceeding ACL minimums or maximums.
  • When specified in an ACL allow rule these properties do not affect that rule's match determination. Rather, when the constraint is exceeded then the allow rule which is otherwise matched is converted into a deny rule.
  • The new rule properties have no effect in deny rules.
  • The new New rule properties are added in 0.16:
    • queuemaxsizelowerlimit
    • queuemaxsizeupperlimit (alias: maxqueuesize)
    • queuemaxcountlowerlimit
    • queuemaxcountupperlimit (alias: maxqueuecount)

# Example of ACL specifying queue size constraints
# Note: for legibility this acl line has been split into multiple lines.

acl allow bob@QPID create queue name=q6 queuemaxsizelowerlimit=50 
                                        queuemaxsizeupperlimit=100 
                                        queuemaxcountlowerlimit=200 
                                        queuemaxcountupperlimit=300

#
# These limits come into play when a queue is created as illustrated here:

            queue_options = {}
            queue_options["qpid.max_count"] = 101
            queue_options["qpid.max_size"] = 100
            session.queue_declare(queue="q6", arguments=queue_options)

#
# When the ACL rule is processed the actor, action, object, and object name all match
# and so this allow rule matches for the allow or deny decision. However, the ACL rule
# is further constrained to limit 50 <= max_size <= 100 and 200 <= max_count <= 300.
# Since the queue_option max_count is 101 then the size limit is violated and the
# allow rule is returned with a deny decision.

Validation

• • New rule properties are added in 0.20:
    • filemaxsizelowerlimit
    • filemaxsizeupperlimit
    • filemaxcountlowerlimit
    • filemaxcountupperlimit

This table shows information about the C++ Broker limit properties

The following example demonstrates using the size constraints.

# Example of ACL specifying queue size constraints
# Note: for legibility this acl line has been split into multiple lines.

acl allow bob@QPID create queue name=q6 queuemaxsizelowerlimit=500000 
                                        queuemaxsizeupperlimit=1000000
                                        queuemaxcountlowerlimit=200 
                                        queuemaxcountupperlimit=300

#
# These limits come into play when bob@QPID creates a queue as illustrated here:

    const char* address =

        "message_queue; “
        “ { create: always, “
        “   node: “
        “   { type: queue, “
        “     x-declare: ”
        “     { arguments: “
        “       { qpid.max_count:101,”
        “         qpid.max_size:1000000”
        “       }”
        “     }”
        “   }”
        “ }";
    ...
    Sender sender = session.createSender(address);

#
# When the ACL rule is processed the user, action, object, and object name all match
# and so this allow rule matches for the allow or deny decision. However, the ACL rule
# is further constrained to limit 500000 <= max_size <= 1000000 and 
# 200 <= max_count <= 300. Since the queue_option max_count is 101 then the size 
# limit is violated and the allow rule is returned with a deny decision.

User Name and Domain Name Symbol Substitution

In the C++ Broker 0.20 a simple set of user name and domain name substitution variable keyword tokens is defined. This provides administrators with an easy way to describe private or shared resources.

Symbol substitution is allowed in the ACL file anywhere that text is supplied for a property value.

In the following table an authenticated user named bob.user@QPID.COM has his substitution keywords expanded.

• The original user name has the period “.” and ampersand “@” characters translated into underscore “_”. This allows substitution to work when the substitution keyword is used in a routingkey in the Acl file.
• The Acl processing matches ${userdomain} before matching either ${user} or ${domain}. Rules that specify the combination ${user}_${domain} will never match.

Example:

Administrators can set up Acl rule files that allow every user to create a private exchange, a private queue, and a private binding between them. In this example the users are also allowed to create private backup exchanges, queues and bindings. This effectively provides limits to user's exchange, queue, and binding creation and guarantees that each user gets exclusive access to these resources.

#
# Create primary queue and exchange:
#
acl allow all create  queue    name=$\{user}-work alternate=$\{user}-work2
acl deny  all create  queue    name=$\{user}-work alternate=*
acl allow all create  queue    name=$\{user}-work
acl allow all create  exchange name=$\{user}-work alternate=$\{user}-work2
acl deny  all create  exchange name=$\{user}-work alternate=*
acl allow all create  exchange name=$\{user}-work
#
# Create backup queue and exchange
#
acl deny  all create  queue    name=$\{user}-work2 alternate=*
acl allow all create  queue    name=$\{user}-work2
acl deny  all create  exchange name=$\{user}-work2 alternate=*
acl allow all create  exchange name=$\{user}-work2
#
# Bind/unbind primary exchange
#
acl allow all bind   exchange name=$\{user}-work routingkey=$\{user} queuename=$\{user}-work
acl allow all unbind exchange name=$\{user}-work routingkey=$\{user} queuename=$\{user}-work
#
# Bind/unbind backup exchange
#
acl allow all bind   exchange name=$\{user}-work2 routingkey=$\{user} queuename=$\{user}-work2
acl allow all unbind exchange name=$\{user}-work2 routingkey=$\{user} queuename=$\{user}-work2
#
# Access primary exchange
#
acl allow all access exchange name=$\{user}-work routingkey=$\{user} queuename=$\{user}-work
#
# Access backup exchange
#
acl allow all access exchange name=$\{user}-work2 routingkey=$\{user} queuename=$\{user}-work2
#
# Publish primary exchange
#
acl allow all publish exchange name=$\{user}-work routingkey=$\{user}
#
# Publish backup exchange
#
acl allow all publish exchange name=$\{user}-work2 routingkey=$\{user}
#
# deny mode
#
acl deny all all

Routingkey Wildcard

In the C++ Broker 0.20 the logic governing the ACL Match have changed for each ACL rule that contains a routingkey property. The routingkey property is matched according to Topic Exchange match logic the broker uses when it distributes messages published to a topic exchange.

Suppose an ACL rule file is:

acl allow-log uHash1@COMPANY publish exchange name=X routingkey=a.#.b
acl deny all all

When user uHash1@COMPANY attempts to publish to exchange X the ACL will return these results:

Validation

Note: In the C++ Broker (0.16 and later) Note: In the 0.16 C++ Broker only the following validation is performed on ACL rule files:

• Files are correctly formatted with respect to character sets, white space, continuation, and line length.
• Permissions, Actions and Objects are correctly named.
• Sufficient tokens are presented for each ACL rule.
• Any validation error is fatal and the broker is shut down.
• Every line in an ACL file is validated before and all invalid ACL rules are logged.
• Any validation error is fatal and the broker is shut down due to a validation failure.

Example file:

# Some groups
group admin ted@QPID martin@QPID
group user-consume martin@QPID ted@QPID
group group2 kim@QPID user-consume rob@QPID
group publisher group2 \
                tom@QPID andrew@QPID debbie@QPID

# Some rules
acl allow carlt@QPID create exchange name=carl.*
acl deny rob@QPID create queue
acl allow guest@QPID bind exchange name=amq.topic routingkey=stocks.ibm.#  owner=self
acl allow user-consume create queue name=tmp.*

acl allow publisher publish all durable=false
acl allow publisher create queue name=RequestQueue
acl allow consumer consume queue durable=true
acl allow fred@QPID create all
acl allow bob@QPID all queue
acl allow admin all
acl deny kim@QPID all
acl allow all consume queue owner=self
acl allow all bind exchange owner=self

# Last (default) rule
acl deny all all

...

...