Hello Vilius, I tried to use a temporary queue namespace to define security settings, and it definitely doesn't work this way. If an application tries to use a temporary address with a random name, it needs permissions for all addresses.
Recently we solved a problem in the JMSToolBox application which also tried to use a random UUID-like address. It needs to implement a custom queue requester or something like that which uses a prefixed address/queue name for the management client. The discussion was here: https://lists.apache.org/thread/4yp9n3tom9lk81hs1d3xgfwgld4cwhx0 I'm not sure if it is possible in your case. Maybe applications can be changed to use a particular address with random queue names. чт, 10 апр. 2025 г. в 14:29, Vilius Šumskas <vilius.sums...@rivile.lt.invalid>: > Sorry, but I must come back to this. > > Does setting security settings on temporary queues supposed to work this > way? Or is the namespace only supported for standard address settings, like > metrics, etc.? > > <temporary-queue-namespace>temp</temporary-queue-namespace> > <security-setting match="temp.#"> > <permission type="send" roles="role1, role2" /> > </security-setting> > > I'm asking, because it looks like my assumptions previously were wrong and > we get permission denied error when trying to send to such temporary random > UUID based queues. > > o.apache.camel.processor.CatchProcessor : The exception is handled for > the exception: org.springframework.jms.JmsSecurityException caused by: > AMQ119017: not authorized to create producer, AMQ229032: User: com-testing > does not have permission='SEND' on address > d649d0ca-15de-11f0-a16a-42010a5aa004 [condition = amqp:unauthorized-access] > > -- > Vilius > > -----Original Message----- > From: Vilius Šumskas <vilius.sums...@rivile.lt.INVALID> > Sent: Wednesday, April 9, 2025 10:02 PM > To: users@activemq.apache.org > Subject: RE: how to separate permissions for replyTo temporary queues > > Yes. We will just set namespace and limit queue permissions to: > > <temporary-queue-namespace>temp</temporary-queue-namespace> > <security-setting match="temp.#"> > <permission type="send" roles="roleofourexternalusers" /> > </security-setting> > > One thing I didn't mention is that we have thousands (potentially tens of > thousands) of such external users using these temporary queues, so this > method will be less complex for us to control. We will accept the possible > low security risk. > Lockdown method you have proposed is sound, but giving some internal > complexity in our app we postponed it for later. > > -- > Vilius > > -----Original Message----- > From: Justin Bertram <jbert...@apache.org> > Sent: Wednesday, April 9, 2025 4:48 PM > To: users@activemq.apache.org > Subject: Re: how to separate permissions for replyTo temporary queues > > > ...we have decided to use random UUID temporary replyTo queues for now. > > Unless I'm mistaken, this is the approach you were originally asking about > for which you wanted to separate permissions. Is that correct? > > > Justin > > On Wed, Apr 9, 2025 at 8:37 AM Vilius Šumskas > <vilius.sums...@rivile.lt.invalid> > wrote: > > > Thanks. After some back and forth we have decided to use random UUID > > temporary replyTo queues for now. Until PCI DSS or similar compliance > > will require us to completely separate our clients. > > > > -- > > Vilius > > > > -----Original Message----- > > From: Justin Bertram <jbert...@apache.org> > > Sent: Tuesday, April 8, 2025 9:36 PM > > To: users@activemq.apache.org > > Subject: Re: how to separate permissions for replyTo temporary queues > > > > > Another penalty I suppose is queue scanning every > > "address-queue-scan-period"? > > > > Unless you've disabled scanning (i.e. by setting > > address-queue-scan-period to -1) the broker is already doing most of > > the scanning work. It happens in its own thread and isn't CPU intensive. > > > > Also, consider that tracking & deleting a temporary queue isn't free > > either. You're essentially trading real-time clean-up with periodic > > clean-up. > > > > > > Justin > > > > On Tue, Apr 8, 2025 at 12:47 AM Vilius Šumskas > > <vilius.sums...@rivile.lt.invalid> > > wrote: > > > > > Understood. So one probable performance penalty would be due to > > > queues sitting on disk. Another penalty I suppose is queue scanning > > > every "address-queue-scan-period"? If we have thousands of queues > > > and the scan needs to check every queue for messages and consumer > > > count I suppose this is also relatively slow operation? > > > > > > -- > > > Vilius > > > > > > -----Original Message----- > > > From: Justin Bertram <jbert...@apache.org> > > > Sent: Monday, April 7, 2025 8:04 PM > > > To: users@activemq.apache.org > > > Subject: Re: how to separate permissions for replyTo temporary > > > queues > > > > > > > I'm wondering what is the performance penalty of having > > > auto-delete-queues/auto-delete-addresses enabled on a broker with > > > tens of thousands of queues versus using temporary queues? > > > > > > Predicting performance is tricky given all the variables, but just > > > looking only at the relative "cost" of using a temporary queue vs. a > > > durable queue the durable queue will cost more simply because the > > > disk > > is involved. > > > However, that may not actually have a statistically significant > > > impact on your overall use-case. Only testing will tell. > > > > > > > If performance impact is considerable, can it be alleviated, by > > > > let's > > > say, enabling auto-delete-queues/auto-delete-addresses only on > > > replyTo queues? > > > > > > This was my original suggestion. Notice the match in my example > > > address-setting was "replyTo.#". > > > > > > I think it would make sense to add a new address-setting to make > > > queues temporary. I opened ARTEMIS-5386 [1] to track this. > > > > > > > > > Justin > > > > > > [1] https://issues.apache.org/jira/browse/ARTEMIS-5386 > > > > > > On Mon, Apr 7, 2025 at 6:39 AM Vilius Šumskas > > > <vilius.sums...@rivile.lt.invalid> > > > wrote: > > > > > > > Thank you for your response. > > > > > > > > Suggestion regarding switching to persistent queues looks > interesting. > > > > I'm wondering what is the performance penalty of having > > > > auto-delete-queues/auto-delete-addresses enabled on a broker with > > > > tens of thousands of queues versus using temporary queues? > > > > Currently we have tens of thousands of durable queues + max one > > > > temporary queue per every durable queue acting as a replyTo queue > > > > (not all temporary queues exist at all times obviously). If > > > > performance impact is considerable, can it be alleviated, by let's > > > > say, enabling auto-delete-queues/auto-delete-addresses > > > > only on replyTo queues? > > > > > > > > -- > > > > Vilius > > > > > > > > -----Original Message----- > > > > From: Justin Bertram <jbert...@apache.org> > > > > Sent: Friday, April 4, 2025 5:18 PM > > > > To: users@activemq.apache.org > > > > Subject: Re: how to separate permissions for replyTo temporary > > > > queues > > > > > > > > > <security-setting > > > > > > > > match="^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4 > > > > }- > > > > [0 > > > > -9a-fA-F]{12}$"> > > > > > > > > I would not expect this syntax to work. The match for a > > > > security-setting must conform to the wildcard syntax [1] which > > > specifically states: > > > > > > > > ...wildcard characters cannot be used like wildcards in a > > > > regular expression. > > > > > > > > > Are we doing something wrong? Should we just rely on the fact > > > > > that it > > > > would be very difficult to guess other temp queue names? > > > > > > > > I don't think you're doing anything _wrong_ per se. If you want to > > > > use temporary queues then this is a trade-off you'll have to make. > > > > > > > > However, if you really want to lock everything down then I > > > > recommend you don't use temporary queues and just let the broker > > > > deal with automatically creating and deleting the queues. You can > > > > name the queues with a particular prefix and assign permissions to > > > > roles as > > > appropriate, e.g.: > > > > > > > > <address-settings> > > > > ... > > > > <address-setting match="replyTo.#"> > > > > <auto-create-queues>true</auto-create-queues> > > > > <auto-delete-queues>true</auto-delete-queues> > > > > <auto-create-addresses>true</auto-create-addresses> > > > > <auto-delete-addresses>true</auto-delete-addresses> > > > > <address-setting> > > > > ... > > > > </address-settings> > > > > ... > > > > <security-settings> > > > > ... > > > > <security-setting match="replyTo.app1.#"> > > > > <permission type="send" roles="app1" /> > > > > <permission type="consume" roles="app1" /> > > > > </security-setting> > > > > <security-setting match="replyTo.app2.#"> > > > > <permission type="send" roles="app2" /> > > > > <permission type="consume" roles="app2" /> > > > > </security-setting> > > > > ... > > > > </security-settings> > > > > > > > > Then each of your applications could use something like this: > > > > > > > > ... > > > > Session replyTo = session.createQueue("replyTo.app1." + > > > > java.util.UUID.randomUUID().toString()) > > > > ... > > > > message.setJMSReplyTo(replyTo); > > > > ... > > > > > > > > This is all off the top of my head so there might be some errors > > > > in there, but hopefully you get the idea. Let me know if you have > > > > further > > > questions! > > > > > > > > > > > > Justin > > > > > > > > [1] > > > > > > > > https://activemq.apache.org/components/artemis/documentation/lates > > > > t/ > > > > wi > > > > ldcard-syntax.html#wildcard-syntax > > > > > > > > On Fri, Apr 4, 2025 at 8:14 AM Vilius Šumskas > > > > <vilius.sums...@rivile.lt.invalid> > > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > I’m wondering how one separates permissions of two different > > > > > roles for temporary replyTo queues? Let’s say we have two > > > > > external users which can consume from their durable queues, but > > > > > they respond to replyTo queue created by producer (RPC flow > > > > > model). We can only set one namespace for the queue and limit > these users by: > > > > > > > > > > <temporary-queue-namespace>temp</temporary-queue-namespace> > > > > > <security-setting match="temp.#"> <permission type="send" > > > > > roles="roleofbothusers" /> </security-setting> > > > > > > > > > > Or we could do: > > > > > > > > > > <security-setting > > > > > match="^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F] > > > > > {4 > > > > > }- > > > > > [0 -9a-fA-F]{12}$"> <permission type="send" roles=" > > > > > roleofbothusers " /> </security-setting> > > > > > > > > > > But this doesn’t forbit user1 to send messages to temporary > > > > > queues of user2. ReplyTo queues obviously have just random IDs > > > > > and there is no way to differentiate between user1 temporary > > > > > queues and > > > > > user2 temporary > > > > queues. > > > > > > > > > > Are we doing something wrong? Should we just rely on the fact > > > > > that it would be very difficult to guess other temp queue names? > > > > > > > > > > -- > > > > > Best Regards, > > > > > > > > > > Vilius Šumskas > > > > > Rivile > > > > > IT manager > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > -- > > > > - To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org > > > > For additional commands, e-mail: users-h...@activemq.apache.org > > > > For further information, visit: > > > > https://activemq.apache.org/contact > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org > > > For additional commands, e-mail: users-h...@activemq.apache.org For > > > further information, visit: https://activemq.apache.org/contact > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org > > For additional commands, e-mail: users-h...@activemq.apache.org For > > further information, visit: https://activemq.apache.org/contact > > > > >
