Hi Keith,

thanks for explanation.

It will be great if you can post skeletal code of ACL module.

Tomas


Keith Wall wrote
> 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
> exchange.
> 
> ACL ALLOW-LOG foo PUBLISH EXCHANGE name="" routingKey="queueName"
> 
> Hope this helps.
> 
> Keith
> 
> On 5 April 2018 at 14:46, Vavricka <

> vavricka.tomas@

> > 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 ACCESS VIRTUALHOST
>> ACL ALLOW-LOG user1 CREATE QUEUE temporary="true" owner="user1"
>> ACL ALLOW-LOG user1 CONSUME QUEUE temporary="true" owner="user1"
>>
>> ACL ALLOW-LOG user2 ACCESS VIRTUALHOST
>> 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-unsubscribe@.apache

>> For additional commands, e-mail: 

> users-help@.apache

>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 

> users-unsubscribe@.apache

> For additional commands, e-mail: 

> users-help@.apache





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

Reply via email to