Supply AMQP operation to resource check

[uvzubovs]

Currently resource_path takes:

• username - the name of the user
• vhost - the name of the virtual host containing the resource
• resource - the type of resource (exchange, queue)
• name - the name of the resource
• permission - the access level to the resource (configure, write, read)

However, it is not clear what operation is being attempted. For instance, queue.bind and queue.unbind are both 'write' operations on the queue.

Also, there is no routing key. Can it be added (perhaps as a generic bag of attributes associated with an operation)? I understand that standard Rabbit authorization model does not go so deep so to consider routing keys, but since you give us control of the authorization repository, we would like to restrict to which topics (routing keys) the consumers may bind.

Thanks!

[Amithpn]

Any progress with this issue? Anything you found?

[michaelklishin]

The routing key part is addressed in rabbitmq/rabbitmq-server#505 (#44) by introducing a separate endpoint.

The granularity of permissions in RabbitMQ is read, write, configure and that has been the case for a decade. Starting with 3.7.0, there are separate read and write permissions for topics as of 3.7.0 (rabbitmq/rabbitmq-server#505 (#44) only introduce the write part but we decided to separately add a read one).

I'm not convinced per-operation granularity is essential: very very few users ask for it. The earliest it can be considered for is now 3.8.0.

[michaelklishin]

The granularity of permissions in RabbitMQ is read, write, configure and that has been the case for a decade

so we will keep it this way => this is a wontfix.