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