Bruce Dodson created AMQ-6984:
---------------------------------
Summary: Authorization rules not honored for virtual topic
consumer queues containing wildcards
Key: AMQ-6984
URL: https://issues.apache.org/jira/browse/AMQ-6984
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.15.4
Reporter: Bruce Dodson
If you use <authorizationMap> to restrict which users can create queues or
topics according to a given pattern, e.g. for "Consumer.*.VirtualTopic.>", this
is normally honored correctly, and an exception occurs if the physical
destination does not exist and user does not have admin access.
The attempt to create the physical destination is bypassed, properly, if the
consumer is subscribing to a wildcard destination, and no check for admin
access is performed in this case.
However, if the wildcard destination corresponds to a Consumer queue for a
Virtual Topic, a physical queue is still created, containing literal wildcard
characters. This is somewhere in the implementation details of Virtual Topics.
Perhaps this behavior, based on physical Consumer queues that contain literal
wildcards, may be applicable for some use cases, e.g. to aggregate multiple
virtual topics to a single consumer. There may be applications that rely on
this behavior.
However, in any case, there is an issue in that access limits from the
<authorizationMap> are not checked when the broker creates this queue. Thus,
even if the user has only read access to that destination pattern, the broker
will still create a queue containing literal wildcards if the user requests one
via a consumer.
For one possible workaround, I looked into an option to address this within
AbstractRegion.addConsumer(): if the destination is a queue containing
wildcards, have it check broker.getDestinationInterceptor() and figure out if
the destination corresponds to a Virtual Topic consumer queue, and if so, try
to create it as a physical queue at that point (with authorization checks),
e.g. by calling lookup(), as is done for destinations that do not contain
wildcards. But it seemed like this might create some unwanted tight coupling to
the implementation details of Virtual Topics, if done in this way, and I was
not sure it would work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
