Reference: Role Based Security for Addresses
Seven different permissions can be given to the set of queues which match the address. Those permissions are: createDurableQueue. This permission allows the user to create a durable queue under matching addresses. deleteDurableQueue. This permission allows the user to delete a durable queue under matching addresses. createNonDurableQueue. This permission allows the user to create a non-durable queue under matching addresses. deleteNonDurableQueue. This permission allows the user to delete a non-durable queue under matching addresses. send. This permission allows the user to send a message to matching addresses. consume. This permission allows the user to consume a message from a queue bound to matching addresses. manage. This permission allows the user to invoke management operations by sending management messages to the management address. For each permission, a list of roles who are granted that permission is specified. If the user has any of those roles, he/she will be granted that permission for that set of addresses. Let's take a simple example, here's a security block from hornetq-configuration.xml or hornetq-queues.xml file: The '#' character signifies "any sequence of words". Words are delimited by the '.' character. For a full description of the wildcard syntax please see Chapter 13, Understanding the HornetQ Wildcard Syntax. The above security block applies to any address that starts with the string "globalqueues.europe.": Only users who have the admin role can create or delete durable queues bound to an address that starts with the string "globalqueues.europe." Any users with the roles admin, guest, or europe-users can create or delete temporary queues bound to an address that starts with the string "globalqueues.europe." Any users with the roles admin or europe-users can send messages to these addresses or consume messages from queues bound to an address that starts with the string "globalqueues.europe." The mapping between a user and what roles they have is handled by the security manager. HornetQ ships with a user manager that reads user credentials from a file on disk, and can also plug into JAAS or JBoss Application Server security. For more information on configuring the security manager, please see Section 31.4, “Changing the security manager�. There can be zero or more security-setting elements in each xml file. Where more than one match applies to a set of addresses the more specific match takes precedence. Let's look at an example of that, here's another security-setting block: In this security-setting block the match 'globalqueues.europe.orders.#' is more specific than the previous match 'globalqueues.europe.#'. So any addresses which match 'globalqueues.europe.orders.#' will take their security settings only from the latter security-setting block. Note that settings are not inherited from the former block. All the settings will be taken from the more specific matching block, so for the address 'globalqueues.europe.orders.plastics' the only permissions that exist are send and consume for the role europe-users. The permissions createDurableQueue, deleteDurableQueue, createNonDurableQueue, deleteNonDurableQueue are not inherited from the other security-setting block. By not inheriting permissions, it allows you to effectively deny permissions in more specific security-setting blocks by simply not specifying them. Otherwise it would not be possible to deny permissions in sub-groups of addresses.