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 therights ability to consumean fromexchange the+ brokerrouting 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>

...

The first three behave as in consume <consume> limiting the list of users to a named queue or all temporary queues. The additional <exchanges> element contains a number of <exchange> entries, this entry contains a list of users that are limited to using only that exchange for the given queue. This is used in the example below to limit the user 'client' to only be able to create temporary queues on the 'amq.direct' exchange.

NOTE: This section also suffers from the same issue as CONSUME <consume> with regard to the <temporary/> keyword. See the known issue for more details.

<!-- 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>

Known Issues

...

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>
    

...

Granting temporary queue and named queue consume rights

When defining a <queue> entry the existence of the <temporary/> key grants access to temporary queues. However, the lack of the key denies access to temporary queues. As a result if there are multiple <queue> entries the last entry will specify the value for access to temporary queues. i.e. In this example it is expected that 'client' can consume from temporary queues and named queue 'exampleQueue2'. Infact what will happen is that the user will only have access to 'exampleQueue2'.

        <queue>
            <temporary/>
            <users>
                <user>client<<user>admin</user>
            </users>
</users>
        </queue>
        <queue>
     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>
       <name>exampleQueue2</name><queue>
        <name>clientid:subscriptionName</name>
    <users>
    <users>
            <user>client<<user>testuser</user>
            </users>
     </queue>
   </queues>
</queue>
/consume>

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

Known Issues

Granting temporary queue and named queue consume rights

When defining a <queue> entry the existence of the <temporary/> key grants access to temporary queues. However, the lack of the key denies access to temporary queues. As a result if there are multiple <queue> entries the last entry will specify the value for access to temporary queues. i.e. In this example it is expected that 'client' can consume from temporary queues and named queue 'exampleQueue2'. Infact what will happen is that the user will only have access to 'exampleQueue2'.To work around this issue the correct definition would be:

        <queue>
            <name>exampleQueue2<<temporary/name>>
            <users>
                <user>client</user>
            </users>
        </queue>

        <queue>
            <temporary<name>exampleQueue2</>name>
            <users>
                <user>client</user>
              </users>
        </queue>

To work around this issue the correct definition would be:

   <user>client</user>
        <queue>
    </users>
        </queue>

The last <queue> entry sets access to the temporary queues. In this simple example where there is only a single named queue it would of course be correct to combine the definitions as follows:

   <name>exampleQueue2</name>
            <users>
        <queue>
        <user>client</user>
            </users>
      <temporary/>  </queue>

        <queue>
            <name>exampleQueue2<<temporary/name>>
            <users>
                <user>client</user>
            </users>
        </queue>