Is your feature request related to a problem? Please describe.
Yes. When deploying RabbitMQ as an MQTT broker for thousands of IoT clients, a common security requirement is that each client may only publish or subscribe to topics that contain its own clientId — for example, client ABC should only access topics under ABC/.
The current topic permissions system is static per user, so the only way to enforce this is to create one permission entry per client:
rabbitmqctl set_topic_permissions ABC / amq.topic "^ABC\..*" "^ABC\..*"
rabbitmqctl set_topic_permissions XYZ / amq.topic "^XYZ\..*" "^XYZ\..*"
# ... repeated for every client
With thousands of clients this is unmanageable and creates significant operational overhead.
Describe the solution you'd like
Support a {username} placeholder in topic permission patterns, interpolated at runtime with the authenticated client's username:
rabbitmqctl set_topic_permissions "*" / amq.topic "^{username}\..*" "^{username}\..*"This single rule would cover all clients dynamically. A client authenticating as ABC would only be allowed to access topics matching ^ABC..*, and so on for every other client — with zero per-client provisioning.
Describe alternatives you've considered
-
Per-user topic permissions — creating one set_topic_permissions entry per client. Works correctly but does not scale to thousands of clients.
-
rabbitmq_auth_backend_http — delegating authorization to a custom HTTP service that checks whether the routing_key starts with the username. Scalable when combined with rabbit_auth_backend_cache, but introduces an external runtime dependency and additional infrastructure just to enforce a simple naming convention.
-
rabbitmq_auth_backend_ldap — using an LDAP server with dynamic query patterns. Technically possible but trades one dependency for another and adds significant operational complexity.
Additional context
This pattern is already supported by other MQTT brokers.
Is your feature request related to a problem? Please describe.
Yes. When deploying RabbitMQ as an MQTT broker for thousands of IoT clients, a common security requirement is that each client may only publish or subscribe to topics that contain its own clientId — for example, client ABC should only access topics under ABC/.
The current topic permissions system is static per user, so the only way to enforce this is to create one permission entry per client:
With thousands of clients this is unmanageable and creates significant operational overhead.
Describe the solution you'd like
Support a {username} placeholder in topic permission patterns, interpolated at runtime with the authenticated client's username:
This single rule would cover all clients dynamically. A client authenticating as ABC would only be allowed to access topics matching ^ABC..*, and so on for every other client — with zero per-client provisioning.
Describe alternatives you've considered
Per-user topic permissions — creating one set_topic_permissions entry per client. Works correctly but does not scale to thousands of clients.
rabbitmq_auth_backend_http— delegating authorization to a custom HTTP service that checks whether the routing_key starts with the username. Scalable when combined with rabbit_auth_backend_cache, but introduces an external runtime dependency and additional infrastructure just to enforce a simple naming convention.rabbitmq_auth_backend_ldap— using an LDAP server with dynamic query patterns. Technically possible but trades one dependency for another and adds significant operational complexity.Additional context
This pattern is already supported by other MQTT brokers.