Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
5.15.4
-
None
-
None
Description
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.