search

VolantMQ / volantmq

High-Performance MQTT Server
Apache License 2.0
981 stars 169 forks source link

Auth Plugin using Mongo Backend #166

Open arihantdaga opened 4 years ago

arihantdaga commented 4 years ago

Is your feature request related to a problem? Please describe. Currently, the auth plugin only supports Http backend (Apart from SimpleAuth). It does not support database connections directly.

Describe the solution you'd like I think it would be a nice feature if we can support auth using a database of user's choice as a backend. It'll be faster and more efficient.

I want to contribute with plugins for supporting authentication with database backends. I started with Supporting MongoDB. I would be doing for other databases as well. However, I am not sure about the contribution process. I created a GitHub repo https://github.com/arihantdaga/volantmqplugin_auth_mongo. But I saw that all plugins are maintained on Gitlab, I am new to it and I do not have access to the VolantMq project there. Can the author please guide me on how to add this plugin and others to the GitLab project.

troian commented 4 years ago

Hi @arihantdaga Thank you in your attempts to contribute. All plugins are located on Gitlab due to only there we can create subgroups that recreate a folder structure. Thus in the future, we could merge all plugins into one git repo if we sort out versioning for each plugin.

I've created mongo plugin repo on Gitlab. Feel free to fork. Once you're ready, make a PR to Gitlab repo. If all goes good we will include it into Docker image

troian commented 4 years ago

@arihantdaga I think the best option would be to postpone the development of this feature. One of the reasons I want to keep authentication decisions away from VolantMQ and put this job entirely to middle-ware which is 100% is on the customer side, and each customer has its ways to manage users.

Currently, there is an excellent plugin called http auth, and a job it does is entirely sufficient. Though it would be ok to implement different relays like AMQP, for example. But the general point would be the following: VolantMQ plugins shall not make authentication decisions and use HTTP relay to authenticate (log in) and authorize (ACL). SimpleAuth is provided as a reference (or running tests) to allow easy start and test VolantMQ without any external dependency and is not recommended for use in production.

arihantdaga commented 4 years ago

Hmm. Ok. I just saw that many other brokers support this. It makes user's decision to choose volantMQ as broker easy. Right now they have to implement an additional Http service. Which is called on every connection and every pub//sub. It's good for small amounts of load. For higher loads, it'll introduce additional latency.

Moreover, the roadblocking factor we had in these plugins was ACL. Authentication was sorted anyway. For ACL, the approach i took was because i have seen simmilar things in other brokers.For the confusion part, we can convey the users in our documentation about things to take care while preparing ACL List. And how i see that list is, as an allowed topics list and not disallowed. If we convey the same in docummentation, users will be responsible for setting the list properly. But it's alright. :)

troian commented 4 years ago

There are no objections to make such a plugin. The only concern is how such a plugin handles users add/remove and permissions model.

Regarding http auth and it's an approach to request permissions on every publish/subscribe. There is no way to rid it off as permissions must be checked on every publish/subscribe. Instead, there are plans to make permissions caching so, for example, embed Redis or make it as a plugin so different caching mechanisms could be implemented.

arihantdaga commented 4 years ago

@troian Yeah, I too had a similar idea for optionally supporting ACL Caches and that was in my queue. I was thinking in memory itself, but I am not sure how good go applications like this can handle that memory-wise. I am very new to golang. There'll be additional memory overhead per client. But even if we go for a separate plugin based on redis or anything else, that too requires memory and a separate instance of redis. With the plugin approach, the caching will be optional anyway. But once again, I am not sure about the right way to do that. If you can share your idea about it, I can go ahead and try to make this caching plugin.