Auth Plugin using Mongo Backend about volantmq HOT 5 OPEN

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

from volantmq.

@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.

from volantmq.

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. :)

from volantmq.

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.

from volantmq.

@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.

from volantmq.