This is an automated email from the ASF dual-hosted git repository.
cshannon pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/activemq-website.git
The following commit(s) were added to refs/heads/main by this push:
new c9d223141 Update recommendations for default authorization map
c9d223141 is described below
commit c9d2231415de7266781347ac86be761ccbbfdbeb
Author: Christopher L. Shannon <[email protected]>
AuthorDate: Thu May 28 14:36:35 2026 -0400
Update recommendations for default authorization map
---
.../classic/documentation/networks-of-brokers.md | 29 ++++++++++++++
src/components/classic/documentation/security.md | 46 +++++++++++++++++++++-
2 files changed, 73 insertions(+), 2 deletions(-)
diff --git a/src/components/classic/documentation/networks-of-brokers.md
b/src/components/classic/documentation/networks-of-brokers.md
index 9c70e76ae..9ad7484f5 100644
--- a/src/components/classic/documentation/networks-of-brokers.md
+++ b/src/components/classic/documentation/networks-of-brokers.md
@@ -198,6 +198,35 @@ Network of brokers relies heavily on advisory messages, as
they are used under t
This is all fine and well in small networks and environments whit small number
of destinations and consumers. But as things starts to grow a default model
(listen to everything, share everything) won't scale well. That's why there are
many ways you can use to filter destinations that will be shared between
brokers.
+#### Authorization for advisories
+
+If using the authorization plugin ensure that the user used for the network
connections has permissions to the advisory destinations;
+
+```
+<broker>
+ ..
+ <plugins>
+ ..
+ <authorizationPlugin>
+ <map>
+ <authorizationMap>
+ <authorizationEntries>
+ ...
+ <!-- Grant users that will be used to create a network of
brokers permission for consumer and virtual destination consumer advisories -->
+ <authorizationEntry topic="ActiveMQ.Advisory.Consumer.>"
read="bridge-user,admin" write="bridge-user,admin" admin="bridge-user,admin"/>
+ <authorizationEntry
topic="ActiveMQ.Advisory.VirtualDestination.Consumer.>"
read="bridge-user,admin" write="bridge-user" admin="bridge-user,admin"/>
+ ...
+ </authorizationEntries>
+ </authorizationMap>
+ </map>
+ </authorizationPlugin>
+ ..
+ </plugins>
+ ..
+</broker>
+```
+
+
#### Dynamic networks
Let's start with dynamically configured networks. This means that we only want
to send messages to the remote broker when there's a consumer there. If we want
to limit this behavior only on certain destinations we will use
`dynamicallyIncludedDestinations`, like
diff --git a/src/components/classic/documentation/security.md
b/src/components/classic/documentation/security.md
index 70c7b0723..a38eaf58e 100644
--- a/src/components/classic/documentation/security.md
+++ b/src/components/classic/documentation/security.md
@@ -73,9 +73,47 @@ Queues/Topics can specified using the ActiveMQ Classic
[Wildcards](wildcards) sy
#### Authorization Example
-The following
[example](http://svn.apache.org/repos/asf/activemq/trunk/activemq-unit-tests/src/test/resources/org/apache/activemq/security/jaas-broker.xml)
shows these 2 plugins in operation. Though note its very easy to write your
own plugin. **Note** that full access rights should generally be given to the
ActiveMQ.Advisory destinations because by default an ActiveMQConnection uses
destination advisories to get early knowledge of temp destination creation and
deletion. In addition, dyn [...]
+The following
[example](https://github.com/apache/activemq/blob/main/activemq-unit-tests/src/test/resources/org/apache/activemq/security/jaas-broker.xml)
shows these 2 plugins in operation. Though note its very easy to write your
own plugin.
+
+**Note:** All users need permission to create ActiveMQ.Advisory destinations,
which is given by the "admin" acl. This is to allow the creation of advisory
destinations generated as a side effect of user operations. For example,
sending a message for the first time may trigger producer advisory destination
creation.
+However, normal users should generally **not** be given access to read/write
all Advisories because those are messages meant for admin users.
+
+The following advisory permissions are required for proper operations:
+* All users should be given access to advisories for temporary destinations
because ActiveMQConnection uses those advisories to get early knowledge of temp
destination creation and deletion.
+* In addition, dynamic network connectors use advisories to determine consumer
demand so the users that will be used to create bridges need access to those
advisories.
+
If necessary, the use of advisories in this manner can be disabled via the
_watchTopicAdvisories_ boolean attribute of ActiveMQConnectionFactory and for a
networkConnector, via the network connector _staticBridge_(5.6) boolean
attribute.
+**Example configuration:**
+```
+<broker>
+ ..
+ <plugins>
+ ..
+ <authorizationPlugin>
+ <map>
+ <authorizationMap>
+ <authorizationEntries>
+ <!-- Some destination a user may access -->
+ <authorizationEntry queue="TEST.Q" read="users" write="users"
admin="users" />
+ <!-- Grant all users permission to create advisory topics, but
only admins to read/write -->
+ <authorizationEntry topic="ActiveMQ.Advisory.>" read="admin"
write="admin" admin="*"/>
+ <!-- Grant all users permission to read/write advisories for
temporary destinations -->
+ <authorizationEntry topic="ActiveMQ.Advisory.TempQueue" read="*"
write="*" admin="*"/>
+ <authorizationEntry topic="ActiveMQ.Advisory.TempTopic" read="*"
write="*" admin="*"/>
+ <!-- Grant users that will be used to create a network of
brokers permission for consumer advisories -->
+ <authorizationEntry topic="ActiveMQ.Advisory.Consumer.>"
read="bridge-user,admin" write="bridge-user,admin" admin="bridge-user,admin"/>
+ <authorizationEntry
topic="ActiveMQ.Advisory.VirtualDestination.Consumer.>"
read="bridge-user,admin" write="bridge-user" admin="bridge-user,admin"/>
+ </authorizationEntries>
+ </authorizationMap>
+ </map>
+ </authorizationPlugin>
+ ..
+ </plugins>
+ ..
+</broker>
+```
+
### Broker-to-Broker Authentication and Authorization
If you have enabled authentication for a particular message broker, then other
brokers that wish to connect to that broker must provide the proper
authentication credentials via their <networkConnector> element. For example,
suppose that we have a network of brokers with the following configuration:
@@ -111,7 +149,11 @@ To control access to temporary destinations, you will need
to add a `<tempDestin
<authorizationMap>
<authorizationEntries>
<authorizationEntry queue="TEST.Q" read="users" write="users"
admin="users" />
- <authorizationEntry topic="ActiveMQ.Advisory.>" read="*"
write="*" admin="*"/>
+ <authorizationEntry topic="ActiveMQ.Advisory.>" read="admin"
write="admin" admin="*"/>
+ <authorizationEntry topic="ActiveMQ.Advisory.TempQueue" read="*"
write="*" admin="*"/>
+ <authorizationEntry topic="ActiveMQ.Advisory.TempTopic" read="*"
write="*" admin="*"/>
+ <authorizationEntry topic="ActiveMQ.Advisory.Consumer.>"
read="bridge-user,admin" write="bridge-user,admin" admin="bridge-user,admin"/>
+ <authorizationEntry
topic="ActiveMQ.Advisory.VirtualDestination.Consumer.>"
read="bridge-user,admin" write="bridge-user" admin="bridge-user,admin"/>
</authorizationEntries>
<tempDestinationAuthorizationEntry>
<tempDestinationAuthorizationEntry read="admin" write="admin"
admin="admin"/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact