-
Notifications
You must be signed in to change notification settings - Fork 69
Topic authorization #95
Comments
It might require changes to the core. This is largely a duplicate of rabbitmq/rabbitmq-server#505. There are no plans to look into 2 or 3 until that part is done. |
rabbitmq/rabbitmq-server#505 is about enhancing Rabbit core security mechanism to pass routing keys. This issue is about implementing access control entirely in the plug-in and outside of Rabbit core. Doesn't the plug-in have access to the client and user ids when it receives subscription request? |
Can we set standard Rabbit security aside for the consumer - to - business MQTT use-case? Can we let MQTT plug-in handle authentication and authorization, and then use internal user id when talking to Rabbit? |
Doing too much in this plugin may break compatibility with various authn/authz backends, so there are no short term plans to do such things. |
How about making it conditional? For example: mode 1 is to delegate authn/authz to Rabbit, mode 2 is to let the plug-in handle authn/authz ? |
We are not interested in having 2 different authentication or authorization systems. Moreover, that wouldn't ship any earlier compared to server#505. |
When will rabbitmq/rabbitmq-server#505 ship? |
It seems that the MQTT plug-in currently delegates security to Rabbit, which is based on user to exchange and user to queue grants, and works for B2B but is not appropriate for C2B. There needs to be a way to authorize access to MQTT topics as is done, for instance, in Mosquitto (https://mosquitto.org/man/mosquitto-conf-5.html, see acl_file) and other commercial MQTT brokers.
Specifically, we should be able to prescribe that
I suspect this enhancement need not change anything in the core of Rabbit; it could be just plug-in specific configuration enforced by the plug-in.
The text was updated successfully, but these errors were encountered: