Skip to content
This repository has been archived by the owner on Nov 17, 2020. It is now read-only.

Topic authorization #95

Closed
uvzubovs opened this issue Aug 16, 2016 · 7 comments · Fixed by #115
Closed

Topic authorization #95

uvzubovs opened this issue Aug 16, 2016 · 7 comments · Fixed by #115
Assignees
Milestone

Comments

@uvzubovs
Copy link

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

  1. Users can subscribe to topics of particular structure, e.g. foo/, foo/bar/
  2. Users can subscribe to topics bearing the MQTT client id (%c option in Mosquitto)
  3. Users can subscribe to topics bearing the user id (%u option in Mosquitto)

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.

@michaelklishin
Copy link
Member

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.

@uvzubovs
Copy link
Author

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?

@uvzubovs
Copy link
Author

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?

@michaelklishin
Copy link
Member

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.

@uvzubovs
Copy link
Author

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 ?

@michaelklishin
Copy link
Member

We are not interested in having 2 different authentication or authorization systems. Moreover, that wouldn't ship any earlier compared to server#505.

@uvzubovs
Copy link
Author

When will rabbitmq/rabbitmq-server#505 ship?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants