Authorization to queues does not work correctly with AMQP 1.0

[Amerrak]

Describe the bug

In the current version of RabbitMQ (3.13) with AMQP1.0 enabled (using rabbitmq_amqp1_0 plugin), it is not possible to correctly evaluate permissions to specific queues. I need to use rabbitmq_auth_backend_http plugin to handle authorization to queues for users based on some business configuration that is stored in my datastore, but the RabbitMQ server is not providing enough information about the client request.

here is my rabbitmq_auth_backend_http plugin configuration:

# https://github.com/rabbitmq/rabbitmq-auth-backend-http/tree/master/examples
auth_backends.1 = http
auth_http.http_method   = post
auth_http.user_path     = http://host.docker.internal:8080/brokerauthg01/auth/user
auth_http.vhost_path    = http://host.docker.internal:8080/brokerauthg01/auth/vhost
auth_http.resource_path = http://host.docker.internal:8080/brokerauthg01/auth/resource
auth_http.topic_path    = http://host.docker.internal:8080/brokerauthg01/auth/topic

# SSL Auth mechanism
# https://github.com/rabbitmq/rabbitmq-server/blob/main/deps/rabbitmq_auth_mechanism_ssl/README.md
auth_mechanisms.1 = EXTERNAL
ssl_cert_login_from = common_name
management.disable_basic_auth = true

As a client application, I have a Java Server that publishes messages to RabbitMQ using standard JmsQueues from Apache Qpid JMS (see https://qpid.apache.org/components/jms/index.html). I also tried the swiftmq and Apache Qpid ProtonJ clients, but the result was the same.

Here is the object RabbitMQ passes to the auth/resource method on the configured authorization server:

{
  "username": "CN_FROM_CERT",
  "vhost": "/",
  "resource": "exchange",
  "name": "amq.default",
  "permission": "write",
  "tags": "USER_ROLES"
}

All write operations to any queue are handled via the amqp.default exchange without any additional information about the target queue. I think the RabbitMQ server should either provide information with something like "resource": "queue", "name": "queueName" or add a routingKey parameter to the existing request. That way it would be possible to handle queue authorization correctly.

Reproduction steps

1. Start RabbitMQ with rabbitmq_amqp1_0 and rabbitmq_auth_backend_http plugins
2. Start custom auth server
3. Publish any message into any queue and check auth/resource function
   ...

Expected behavior

RabbitMQ server with AMQP1.0 enabled should provide queue name information to the authentication/resource request. This can be something like "resource": "queue", "name": "queueName" or add a routingKey parameter to an existing request. That way it would be possible to handle queue authorization correctly.

Additional context

No response

[michaelklishin]

@Amerrak please put together an executable way to reproduce. We do not guess in this community and your claim does not include any specific examples.

In fact, you start with a claim that you'd like to not use the HTTP authN/authZ backend but then the only example there is does use it.

[Amerrak]

Hi, I am sorry if there is some misunderstanding. I would like to use the HTTP authN/authZ backend, but I ran into a problem that in the case of AMQP1.0, the HTTP authN/authZ backend does not provide enough information to verify queue rights (there is only information about default exchange and not the queue). I will prepare executable files with RabbitMQ configuration, authN/authZ server and client server and provide them to you as soon as possible.

[michaelklishin]

That's fine. See my comment below, I will edit it to reflect what we need from your to begin investigating.

[michaelklishin]

To be more specific, what we need to try to reproduce this behavior and debug the root cause is:

• A public git repo that we can use to run a RabbitMQ node with the desired configuration (so, if you want to use an HTTP authN/authZ service, the setup should use it with one of the example apps or any comparable minimalistic service you care to put together)
• A way to run the smallest possible AMQP 1.0-based example to demonstrate what operation is denied because of (supposedly incorrectly) computed permissions

Docker Compose is a very commonly used tool for such executable examples. Once we have it, we will have a look because improving AMQP 1.0 support is one of the priorities for RabbitMQ.

Without it we cannot investigate much. Our team is small, we don't have all the information needed to re-create this behavior, and guessing is an extremely expensive way of troubleshooting distributed systems and infrastructure in general.

[Amerrak]

Thank you for the quick reply. I understand these requirements and will provide you a public git repo by tomorrow.

[Amerrak]

I have prepared an executable example that is available here. How-to is described in the README file and should contain all the information you need to reproduce my issue.

/auth/user interface always returns "allow", but there is a logger for all information that is passed to this function by RabbitMQ server. For queue authorization, these parameters include the following:

Checking resource access with ResourceCheck{resource='exchange', name='amq.default', permission='write'} ResourceCheck{username='guest', vhost='/'}

As you can see, there is only information that the client is accessing the amq.default exchange, but there is no information about which queue the client wants to write to. These parameters are the same for all users and in AMQP1.0 all requests are sent through the amq.default exchange, so it is not possible to recognize which queue the user wants to write to.

In AMQP0.9 this was not a problem as there could be a specific exchange for each queue. Write operations are then performed through this exchange and routed to queues so authorization is processed based on a specific exchange name. AMQP1.0 does not use exchanges in the same way as AMQP0.9 and all operations are handled by the amq.default exchange, so authorization cannot be done as before and requires routingKey information to determine the QueueName.

[lukebakken]

@Amerrak thanks for your example.

in the case of AMQP1.0, the HTTP authN/authZ backend does not provide enough information to verify queue rights (there is only information about default exchange and not the queue

This is due to the fact that the message routing key is only provided when doing checks for access to a topic exchange. Since the amq.default exchange is being used any auth backend does not have the routing key information available, not just the HTTP auth backend. This applies to all protocols as well, not just AMQP 1.0

Pinging @ansd and @kjnilsson since they may have additional input about how authorization may change with regard to #9022 and #10559

[ansd]

@lukebakken The RabbitMQ authorisation model doesn't change with Native AMQP 1.0 in RabbitMQ 4.0.

As documented in https://www.rabbitmq.com/docs/access-control#authorisation a client that publishes a message needs merely write access to the exchange it is publishing to.

@Amerrak if you, as a RabbitMQ operator, grant write permissions to the amq.default exchange to the RabbitMQ users which your publishers authenticate with, it means that your publishers can indeed write into any queue because every queue implicitly binds to the default exchange with its queue name being the binding key.

This authorisation model works exactly the same way for both AMQP 0.9.1 and AMQP 1.0.

So, if you need more fine grained authorisations, do not grant publishers access to the amq.default exchange.

AMQP1.0 does not use exchanges in the same way as AMQP0.9 and all operations are handled by the amq.default exchange

This statement is wrong. AMQP 1.0 re-uses the AMQ 0.9.1 model including exchanges, queues, and bindings. Again, the RabbitMQ permission model doesn't change either.
Your AMQP 1.0 clients do not have to use one of the following AMQP 1.0 target address schemes

| "/amq/queue/" Q         Publish to default exchange with routing key Q
| "/queue/"     Q         Publish to default exchange with routing key Q
| Q (no leading slash)    Publish to default exchange with routing key Q
| "/queue"                Publish to default exchange with message subj as routing key

Instead, your AMQP 1.0 clients could use one of the following target address schemes:

= "/exchange/"  X "/" RK  Publish to exchange X with routing key RK
| "/exchange/"  X         Publish to exchange X with message subject as routing key
| "/topic/"     RK        Publish to amq.topic with routing key RK

In AMQP0.9 this was not a problem as there could be a specific exchange for each queue. Write operations are then performed through this exchange and routed to queues so authorization is processed based on a specific exchange name.

Therefore, for AMQP 1.0 you can achieve the same authorisation model that you outlined for AMQP 0.9.1.

Note that AMQP 1.0 clients creating dynamic routing topologies including exchanges, queues, and bindings gets implemented in #10559

[lukebakken]

Thanks @ansd