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.

...

• CONSUME
• PUBLISH
• CREATE
• ACCESS
• BIND
• UNBIND
• DELETE
• PURGE

XML Format

DTD TBC

User Guide (SimpleXML)

...

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 consume from the brokeran exchange + 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 allows the granting of permissions to Consumers. There are two formats the <queue> entry can take: *

• Users can be granted permission to a named queue by the use of the <name> field.

...

• Users can be granted permission to ALL temporary queues with the addition of the <temporary/> key.

These two formats can be combined to allow the consumption from a named queue and temporary queues. However, care must be taken if using multiple <queue> entries as access to temporary queues will be defined by the last <queue> definition. This is a known issue.

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

        <!-- Allow the clients to consume from their temporary queues-->
        <queue>
            <temporary/>
            <users>
                <user>client</user>
            </users>
        </queue>


        <!-- Only allow the server to consume from the Request Queue-->
        <queue>
            <name>example.RequestQueue</name>
            <users>
                <user>server</user>
            </users>
        </queue>

    </queues>
</consume>

...

This section allows the granting of permissions to create new queues as used by Consumers. When a consumer is created it makes a request to create the queue for the consumer. This means that all your consumers must also be allowed to create the queue they are going to consume from or they will fail to create.

The <create> section contains a number of fields that can be present:

<temporary/>
<name>
<users>
<exchanges>

The first three behave as in <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> 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>
   

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

        <!-- Allow the server to create the Request Queue-->
        <queue>
            <name>example.RequestQueue</name>
            <users></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           <user>server</user>
        them full permissions to all artifacts in the containing virtualhost -->
<access>
    </users><users>
        <<user>admin</queue>
user>
    </queues>users>
</create>access>

Known Issues

...

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>

...

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

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

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