Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

此内容没有您所选择的语言版本。

Chapter 29. Security

This chapter explores how security works with HornetQ and how it can be configured.
For performance reasons, security is cached and invalidated periodically. To change this period, set the property security-invalidation-interval, which is in milliseconds. The default is 10000 ms.

Warning

Security is enabled by default, to ensure your production system security remains high once properly configured. You can disable security completely by explicitly setting the security-enabled property to false in the <JBOSS_HOME>/jboss-as/server/<PROFILE>/deploy/hornetq/hornetq-configuration.xml file. This practice is strongly discouraged for production environments.

29.1. Role based security for addresses
复制链接

HornetQ contains a flexible role-based security model for applying security to queues, based on their addresses.
As explained in Chapter 7, Using Core, HornetQ core primarily consists of sets of queues bound to addresses. A message is sent to an address and the server looks up the set of queues that are bound to that address. The server then routes the message to those sets of queues.
HornetQ allows sets of permissions to be defined against the queues based on their address. An exact match on the address can be used or a wildcard match can be used using the wildcard characters '#' and '*'.
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 is specified of the roles that are granted that permission. If the user has any of those roles, they will be granted that permission for that set of addresses.
An example security block is described in <JBOSS_HOME>/jboss-as/server/<PROFILE>/deploy/hornetq/hornetq-configuration.xml: 
<security-setting match="globalqueues.europe.#">
   <permission type="createDurableQueue" roles="admin"/>
   <permission type="deleteDurableQueue" roles="admin"/>
   <permission type="createNonDurableQueue" roles="admin, guest, europe-users"/>
   <permission type="deleteNonDurableQueue" roles="admin, guest, europe-users"/>
   <permission type="send" roles="admin, europe-users"/>
   <permission type="consume" roles="admin, europe-users"/>
</security-setting>
Copy to Clipboard Toggle word wrap
The '#' character signifies "any sequence of words". Words are delimited by the '.' character. For a full description of the wildcard syntax refer to Chapter 11, 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 Enterprise Application Platform security.
For more information on configuring the security manager, refer to Section 29.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. 
<security-setting match="globalqueues.europe.orders.#">
   <permission type="send" roles="europe-users"/>
   <permission type="consume" roles="europe-users"/>
</security-setting>
Copy to Clipboard Toggle word wrap
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 effective denial of permissions in more specific security-setting blocks by not specifying them. Otherwise, it would not be possible to deny permissions in sub-groups of addresses.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat