Page History

...

This page documents version 1 of Qpid ACLs that was implemented only in the Java broker and supported up to (and including) release 0.10. Newer releases support ACL V2 only.

...

Permission Limitations

Only the first three four permissions, CONSUME, PUBLISH and CREATE , CREATE and ACCESS (since Qpid 0.6) have been implemented. An oversight in the original design resulted in the inability to specify negative permissions. As a result permission can only be granted to users and not taken away.

...

This tells the broker that it should use the SimpleXML class to perform access control. When the broker starts up the SimpleXML class will look in the the <security> section subsection for each virtualhost for the required ACLs.

ACL Configuration

...

The ACL configuration lives inside the <access_control_list> section, inside the <security> subsection of each virtualhost configuration.

...
<security>
  <access_control_list>
    <!-- This section grants publishvirtualhost-level rightsaccess to anthe exchangespecified + routing key pair -->users, giving
    <publish>...</publish>
     giving them full permissions to all artifacts in the containing virtualhost -->
         <access>...</access>

    <!-- This section grants userspublish the abilityrights to consumean fromexchange the broker+ routing key pair -->
    <consume><publish>...</consume>publish>

    <!-- This section grants users the ability to consume from the broker -->
            <consume>...</consume>

    <!-- This section grants clients the ability to create queues and exchanges -->
    <create>...</create>
  </access_control_list>
...

...

Here the 'client' users is only give rights to PUBLISH messages using the key 'example.RequestQueue'.
The 'server' user is allowed to publish to 'tmp_*' and 'TempQueue*' keys. The reason there are two values here is due to changes in the naming of temporary queues during the example's development. However, what occurs here is that the 'server' is granted permission to publish messages to any routing key that begins with 'tmp_' or 'TempQueue', the '*' matching is only completed at the end of the key so entries such as 'Special*Key' are not allowed.

...

Remember that the routing_key value in the Java broker is the same as the queue name (correct at release of M4) for the amq.direct exchange. For topic exchanges the routing_key is the topic name that a Publisher uses to send messages.

<publish>    
    <exchanges>
        <exchange>
            <!-- This is the name of the exchange to limit publication to. -->
            <name>amq.direct</name>
            <routing_keys>

                <!-- Allow clients to publish requests -->
                <routing_key>
                    <value>example.RequestQueue</value>
                    <users>
                        <user>client</user>
                    </users>
                </routing_key>

                <!-- Allow the processor to respond to a client on their Temporary Topic -->
                <routing_key>
                    <value>tmp_*</value>
                    <users>
                        <user>server</user>
                    </users>
                </routing_key>
                <routing_key>
                    <value>TempQueue*</value>
                    <users>
                        <user>server</user>
                    </users>
                </routing_key>
            </routing_keys>

        </exchange>
    </exchanges>
</publish>

...

<!-- This section grants clients the ability to create queues and exchanges -->
<create>
    <queues>
        <!-- Allow clients to create temporary queues-->
        <queue>
            <temporary/>
            <exchanges>
                <exchange>
                    <name>amq.direct</name>
                    <users>
                        <user>client</user>
                    </users>
                </exchange>
            </exchanges>
        </queue>
        <!-- Allow the server to create the Request Queue-->
        <queue>
            <name>example.RequestQueue</name>
            <users>
                <user>server</user>
            </users>
        </queue>

    </queues>
</create>

ACCESS Section (since Qpid 0.6)

This section allows granting virtualhost-level access permissions to specific users, giving them full permissions to all artifacts within the virtualhost irrespective of any rights assigned in the CREATE, CONSUME, and PUBLISH sections outlined above. This allows granting only certain users full access to certain virtualhosts.

The <access> section contains a <users> subsection, with a list of indivual <user> elements:

<!-- This section grants virtualhost-level access to the specified users, giving
     giving them full permissions to all artifacts in the containing virtualhost -->
<access>
    <users>
        <user>admin</user>
    </users>
</access>

Durable topic subscriptions

Qpid implements durable topic subscriptions as a persistent queue bound to the topic exchange. This queue is named <clientid>:<subscriptionname>. To allow a JMS durable topic subscription it's necessary to allow queue creation and consumption for the user. eg:

<consume>
  <queues>
     <queue>
        <name>clientid:subscriptionName</name>
        <users>
          <queue><user>testuser</user>
        </users>
    <name>example.RequestQueue</name> </queue>
   </queues>
</consume>

<create>
  <queues>
     <queue>
        <users>
<name>clientid:subscriptionName</name>
        <users>
          <user>server<<user>testuser</user>
            </users>
        </queue>

    </queues>
</create>

Known Issues

...