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. ---