[
https://issues.apache.org/jira/browse/ARTEMIS-2503?focusedWorklogId=329457&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-329457
]
ASF GitHub Bot logged work on ARTEMIS-2503:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 16/Oct/19 22:22
Start Date: 16/Oct/19 22:22
Worklog Time Spent: 10m
Work Description: jbertram commented on pull request #2851: ARTEMIS-2503
Improve wildcards for the roles access match
URL: https://github.com/apache/activemq-artemis/pull/2851#discussion_r334624011
##########
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/JMXAccessControlList.java
##########
@@ -25,12 +25,22 @@
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
+import org.apache.activemq.artemis.core.config.WildcardConfiguration;
+import org.apache.activemq.artemis.core.settings.HierarchicalRepository;
+import
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository;
+
public class JMXAccessControlList {
private Access defaultAccess = new Access("*");
- private Map<String, Access> domainAccess = new HashMap<>();
+ private HierarchicalRepository<Access> domainAccess;
private ConcurrentHashMap<String, List<String>> whitelist = new
ConcurrentHashMap<>();
+ public JMXAccessControlList() {
+ WildcardConfiguration domainAccessWildcardConfiguration = new
WildcardConfiguration();
Review comment:
These use-cases seem pretty different to me. The wildcard configuration in
broker.xml is for address matching which is hierarchical in nature and
therefore requires separating "words", matching individual and groups of words,
etc. The "match" performed for keys defined in management.xml is basically just
a **prefix**. It's not hierarchical and doesn't even use regular expressions.
It's *very* simple and IMO it should stay that way.
> If i need to secure a wildcard of address or queues on broker then no
doubt i need to secure the same pattern from admin pov to.
I'm not sure there is "no doubt" about that. Use cases for the security of
actual messaging clients and management users can vary quite a bit. In any
case, the same kind of matching isn't possible in management.xml as it is in
broker.xml either before or after this PR. The use-case for this PR is just
allowing a simple prefixing for the match "key" just like is available for the
access "method" field. The syntax is the same. It's just allowing it in a new
field. I don't see any issue with that.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 329457)
Time Spent: 3h 20m (was: 3h 10m)
> Improve wildcards for the roles access match
> --------------------------------------------
>
> Key: ARTEMIS-2503
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2503
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Reporter: Domenico Bruscino
> Priority: Major
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> Please improve wildcard support for the key element in the roles access
> <match> element.
> ATMÂ you can NOT apply a restriction across a set of queue instances starting
> with the same prefix (like below):
> {code:java}
> <match domain="org.apache.activemq.artemis" key="queue=my*">
> <access method="list*" roles="group2"/>
> <access method="get*" roles="group2"/>
> ...
> </match>{code}
> If queues are created dynamically and only a queue name "prefix" is known in
> advance; JMX RBAC cannot be used to restrict access in this case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
