|
Page Edited :
qpid :
Java XML ACLs
Java XML ACLs has been edited by Aidan Skinner (Jan 22, 2009). Content:Java XML ACLsThis page documents version 1 of Qpid ACLs that was implemented only in the Java broker. SpecificationThe XML ACL focus was to take to business style focus to access rather than the individual AMQP method level.
XML FormatDTD TBC User Guide (SimpleXML)The XML ACLs have been implemented as per the ACLPlugin Permission LimitationsOnly the first three permissions, CONSUME, PUBLISH and CREATE 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. Enabling XML ACLsTo enable the ACLs the security access class in the main broker configuration needs to be updated as follows: ...
<security>
<access>
<class>org.apache.qpid.server.security.access.plugins.SimpleXML</class>
</access>
...
Here the 'client' users is only give rights to PUBLISH messages using the key 'example.RequestQueue'. Whilst not shown here multiple <user> values can be specified in the <users> section. 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>
CONSUME SectionThis section allows the granting of permissions to Consumers. There are two formats the <queue> entry can take:
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>
CREATE SectionThis 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>
<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>
Durable topic subscriptionsQpid 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>
<user>testuser</user>
</users>
</queue>
</queues>
</consume>
<create>
<queues>
<queue>
<name>clientid:subscriptionName</name>
<users>
<user>testuser</user>
</users>
</queue>
</queues>
</create>
Known IssuesGranting temporary queue and named queue consume rightsWhen 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>
</users>
</queue>
<queue>
<name>exampleQueue2</name>
<users>
<user>client</user>
</users>
</queue>
To work around this issue the correct definition would be: <queue>
<name>exampleQueue2</name>
<users>
<user>client</user>
</users>
</queue>
<queue>
<temporary/>
<users>
<user>client</user>
</users>
</queue>
|
Unsubscribe or edit your notifications preferences
