Hi Tomas

Unfortunately, Broker-J's access_control plugin is not too good.  It
is something we would like to rework when schedules allow.  The
current module actually uses an object modal that pre-dates the
current one - which leads to user confusion and an ugly adaption layer
in the code.  The ACL also assumes AMQP 0-x conventions - publishing
only to exchanges and consuming from queues when expressing rules
which creates a further wrinkle when using AMQP 1.0.

The current module lets you specify rules that match objects using
zero or more property qualifiers (e.g. name="foo" or type="fanout"),
so it is possible to write rules about named objects in your system
and all objects matching certain criteria.   For temporary queues,
this doesn't work well as you have discovered.  It is possible to say
that user foo can (or cannot) consume from any temporary queue using
the temporary=true qualifier, but it is not possible to be specific,
but you cannot express a rule that gives users to temporary queues
that they have created.

The ACL mechanism is pluggable - so it would be possible to write a
module that would give the behaviour you need.  You would need to look
at the AccessControlProvider and AccessControl interfaces.  The Broker
supports one or more access control providers.  It consults each
AccessControlProvider in order until one make a decision that is not
DEFER.  So you could hopefully write a simple ACL module that you give
you the additional behaviour you need and fallback on access_control
plugin for everything else.  If you want to explore this route, I
could share some skeletal code to help get you started.

Turning to your last point, when using AMQP 1.0 and wishing to
permission publishing directly to queues, as access_control plugin
knows only AMQP 0-x conventions you have to permission the default

ACL ALLOW-LOG foo PUBLISH EXCHANGE name="" routingKey="queueName"

Hope this helps.


On 5 April 2018 at 14:46, Vavricka <vavricka.to...@gmail.com> wrote:
> Hi,
> I am trying to get working temporary queues on Java Broker. Each user should
> have access only to queue which he created.
> ACL rights:
> ACL ALLOW-LOG user1 CREATE QUEUE temporary="true" owner="user1"
> ACL ALLOW-LOG user1 CONSUME QUEUE temporary="true" owner="user1"
> ACL ALLOW-LOG user2 CREATE QUEUE temporary="true" owner="user2"
> ACL ALLOW-LOG user2 CONSUME QUEUE temporary="true" owner="user2"
> I successfully create temporary queue by JMS method "TemporaryQueue
> temporaryQueue = session.createTemporaryQueue()", queue is correctly created
> on broker, but owner is not set in webgui (however createdBy and
> lastUpdatedBy in JSON is correctly set to corresponding user).
> When I try to create consumer by "MessageConsumer consumer =
> session.createConsumer(temporaryQueue)", I get "Permission CREATE is denied
> for : Consumer ...". When owner is not set in CONSUME ACL I can create
> consumer without error, but both users can consume same queue. Is there any
> different way to distinguish temporary queues, so one user cannot read other
> user messages?
> Another issue is I cannot sent messages directly to temporary queue. When I
> try to send message I get error "Permission PERFORM_ACTION(publish) is
> denied for : Queue 'TempQueueba2f889e-f95c-49d4-8c15-023e62666320'". We
> could utilize sending messages directly to queue, because we cannot
> dynamically create exchange binding by REST API. Or is there any way to set
> bindings by JMS?
> Java Broker 7.0.3
> Qpid JMS client 0.31.0
> Tomas
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org

To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Reply via email to