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/lates
> > > 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
>
>
