That's what I was afraid of. It looks like we will have to allow send
permission for our external roles to all queues for now, and then speed-up
implementation of our own prefix for replyTo queues.
--
Vilius
-----Original Message-----
From: Alexander Milovidov <[email protected]>
Sent: Thursday, April 10, 2025 10:45 PM
To: [email protected]
Subject: Re: how to separate permissions for replyTo temporary queues
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
<[email protected]>:
> 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 <[email protected]>
> Sent: Wednesday, April 9, 2025 10:02 PM
> To: [email protected]
> 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 <[email protected]>
> Sent: Wednesday, April 9, 2025 4:48 PM
> To: [email protected]
> 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
> <[email protected]>
> 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 <[email protected]>
> > Sent: Tuesday, April 8, 2025 9:36 PM
> > To: [email protected]
> > 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
> > <[email protected]>
> > 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 <[email protected]>
> > > Sent: Monday, April 7, 2025 8:04 PM
> > > To: [email protected]
> > > 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
> > > <[email protected]>
> > > 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 <[email protected]>
> > > > Sent: Friday, April 4, 2025 5:18 PM
> > > > To: [email protected]
> > > > 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/lat
> > > > es
> > > > t/
> > > > wi
> > > > ldcard-syntax.html#wildcard-syntax
> > > >
> > > > On Fri, Apr 4, 2025 at 8:14 AM Vilius Šumskas
> > > > <[email protected]>
> > > > 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: [email protected]
> > > > For additional commands, e-mail: [email protected]
> > > > For further information, visit:
> > > > https://activemq.apache.org/contact
> > > >
> > > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: [email protected]
> > > For additional commands, e-mail: [email protected]
> > > For further information, visit:
> > > https://activemq.apache.org/contact
> > >
> > >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected] For
> > further information, visit: https://activemq.apache.org/contact
> >
> >
>
