Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
@jbertram I'm not sure about using the queue name to control access. It
requires users to understand how subscriptions work internally and how the
queue name is constructed, which might be different across protocols.
Perhaps a neater approach could be to allow all users of a particular role
to share subscriptions, controlled by an address setting. e.g.
User defines a role "production", all users within this role are able to
share subscriptions between themselves. Many roles could be created that are
able to share subscriptions, "production", "test", "application-x", only users
within the role are able to share the subscription.
Production Role: user1, user2
Test Role: user3, user4
user1 and user2 can share the subscription, user3 and user4 can also share
a subscription, user1 and user3 can not share a subscription.
We could also create a new security-setting to limit which roles are able
to share subsctipions and for which addresses, something like
"sharedSubscriptionGroup" (or better name), which specifies which roles are
allowed to share subscriptions.
e.g.
```xml
<security-setting match="jms.topic.news.us.#">
<permission type="createDurableQueue" roles="user"/>
<permission type="send" roles="us-user"/>
<permission type="shareSubscription" roles="production,test"/>
</security-setting>
```
We already store which user created the queue "the queue owner", we could
use this information to determine whether or not to allow another user to share
this subscription. You can get the queue owner roles and the current user
roles to make the comparison and do a check on the security setting.
Does this make sense? Any thoughts?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
