Yes, I understood these options. I would definitely prefer #3 as this takes
permissions from external user completely, but would you advice going this way
or it could be a complicated solution in a sense like "building a house from
sticks" :) ?
--
Vilius
-----Original Message-----
From: Justin Bertram <jbert...@apache.org>
Sent: Friday, April 18, 2025 5:20 PM
To: users@activemq.apache.org
Subject: Re: limiting queue creation in JMS durable subscription flow
There are different ways to lock down the broker.
1) You can make it so that external clients can only create exactly the
subscription queue(s) you allow them to create by defining security-settings
with the FQQN (i.e.
<addressName>::<clientID>.<subscriptionName>). This, of course, requires you to
know the client ID and subscription name the client will use which may be
difficult since the app is not under your control.
2) You can limit the external app's ability to create > 1 subscription queue
at a time using resource-limit-settings [1]. This is the most flexible option
since it only requires knowing the name of the corresponding user.
3) You can create the subscription queues yourself and completely revoke the
external app's ability to create subscription queues. This is similar to #1
since it requires knowing the client ID and subscription name. It likely also
requires some additional administration to enable the queue only once the
external app connects otherwise you may have unwanted message accumulation.
Justin
[1]
https://activemq.apache.org/components/artemis/documentation/latest/resource-limits.html#resource-limits
On Fri, Apr 18, 2025 at 6:20 AM Vilius Šumskas
<vilius.sums...@rivile.lt.invalid> wrote:
> I guess that makes sense. If client ID and subscription name is known
> in advance, would you advise to create queues via management API in
> disabled state and then enable after consumer comes online, like
> suggested by Alexander?
>
> --
> Vilius
>
> -----Original Message-----
> From: Justin Bertram <jbert...@apache.org>
> Sent: Thursday, April 17, 2025 5:44 PM
> To: users@activemq.apache.org
> Subject: Re: limiting queue creation in JMS durable subscription flow
>
> The createDurableQueue permission is required for JMS durable
> subscribers (i.e. consumers) since the durable subscription they
> create is represented by a durable, multicast queue. The name of the
> queue is based on the client ID & subscription name provided by the client.
>
> Sending a message to the JMS topic (i.e. Core address) won't result in
> the creation of a queue as that would violate pub/sub semantics. Queues (i.e.
> subscriptions) are only created in response to a consumer.
>
>
> Justin
>
> On Thu, Apr 17, 2025 at 1:43 AM Vilius Šumskas
> <vilius.sums...@rivile.lt.invalid>
> wrote:
>
> > I would like to rephrase my question regarding createDurableQueue
> > permissions requirement. Is it required *by the consumer*? Can those
> > topic queues be created by the producer, or does it go against
> > pub/sub
> model?
> >
> > --
> > Vilius
> >
> > -----Original Message-----
> > From: Justin Bertram <jbert...@apache.org>
> > Sent: Wednesday, April 16, 2025 8:22 PM
> > To: users@activemq.apache.org
> > Subject: Re: limiting queue creation in JMS durable subscription
> > flow
> >
> > > ...I’m not 100% sure if this requirement comes from Qpid library
> > > which we
> > are using, or Camel, or is it a requirement for JMS subscribers in
> > general...
> >
> > This is a requirement for JMS topic subscriptions in general. See
> > the documentation [1] for more details.
> >
> > > Is there a way to limit amount of queues a particular role or user
> > > can
> > create?
> >
> > Yes. See the resource limits documentation [2].
> >
> >
> > Justin
> >
> > [1]
> >
> > https://activemq.apache.org/components/artemis/documentation/latest/
> > jm s-core-mapping.html#mapping-jms-concepts-to-the-core-api
> > [2]
> >
> > https://activemq.apache.org/components/artemis/documentation/latest/
> > re
> > source-limits.html#resource-limits
> >
> > On Wed, Apr 16, 2025 at 3:43 AM Vilius Šumskas
> > <vilius.sums...@rivile.lt.invalid>
> > wrote:
> >
> > > Hello,
> > >
> > > we have a pub/sub Java app which relies on JMS durable
> > > subscriptions and is using Artemis as messaging broker. The broker
> > > runs in our
> > environment.
> > > The app is deployed externally in the environment we don’t control
> > > an acts as a subscriber. For this app we have dedicated a separate
> > > role in the Artemis broker.
> > >
> > > We noticed that this role needs to have createDurableQueue and
> > > deleteDurableQueue permission for the app to work correctly.
> > > Something
> > like:
> > >
> > > <security-setting match="address-for-external-role">
> > > <permission type="createDurableQueue" roles="amq,
> > > external-role"/>
> > > <permission type="deleteDurableQueue" roles="amq,
> > > external-role"/>
> > > <permission type="createAddress" roles="amq"/>
> > > <permission type="consume" roles="amq, external-role"/>
> > > <permission type="send" roles="amq"/>
> > > </security-setting>
> > >
> > > Since I’m not a developer I’m not 100% sure if this requirement
> > > comes from Qpid library which we are using, or Camel, or is it a
> > > requirement for JMS subscribers in general, however I’m trying to
> > > understand what could be done to protect our Artemis environment.
> > > Mainly I’m concerned that even if the role has access to just one
> > > address, in theory, the user could create as many durable queues
> > > in the address as he wants, this way overloading the system.
> > >
> > > Is there a way to limit amount of queues a particular role or user
> > > can create? Or maybe our messaging model is wrong and we should
> > > not be using JMS subscriptions in case of external app at all?
> > >
> > > --
> > > 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
