I would like to integrate my loraserver application with an external MQTT based application, but to my big surprise I can only select HTTP and InfluxDB.
I have figured that I can simply subscribe to the mosquito used internally between the loraserver components, but that seems like an inelegant hack.
I guess I could write my own http<->mqtt gateway if I really have to.
Am I missing something?
Ah yes, my loraserver is a freshly installed docker install, guess that pulls the latest as greatest releases.
Problem is I have several organisations, each with their own application(s), and I must make sure they can not interfere with each other. Myself operating the loraserver is yet again a different entity, as an admin I am trusted to handle data, but the organisations should not have to trust each other.
I could configure the mosquito server to allow a particular user specific access to certain MQTT topics, but that would then have to be configured outside the loraserver admin interface, and would have to be maintained, by me as the global admin, every time a organisation decides to add/remove applications.
All this seems to be handled nicely with the HTTP integration since that is done at the application level, where as the MQTT is a global integration.
So if I run the server in a multi tenant environment, using MQTT as the integration method, yes I think it turns “ugly”. Of course given all my assumptions above are correct.
You are right that at application level it’s not. It’s easy to add application level authorization, but you’ll have to modify lora-app-server's source to add user privileges. Though I’d argue that if your users are not allowed to see different applications within the same organization, then maybe they shouldn’t be part of the same organization at all. After all, organization/application are just names for access and configuration grouping, with the first one grouping where users belong and the second one stating how devices should work (of course this is a bit simplistic and there’s more to it, but still).
This is an old thread, but I just found myself in a similar position as in the original question.
We are setting up an environment with several Chirpstack tenants and would very much like to use MQTT for integration with upstream systems. However, we would like to keep tenants separated from each other.
I was hoping that the Chirpstack MQTT topics would include “tenant” as a level higher than “application”, but this does not seem to be the case. Has this been discussed at some point?
If “tenant” was part of the MQTT topic, then it would be easy to create per tenant ACL:s and each tenant could easily create and subscribe to all its applications. Right now the ACL would have to be updated for each newly created application.
Am I missing something here? Is there some other good way of keeping tenants separate when using MQTT?
You can create a client-certificate per application to connect to the MQTT broker. Once you set this up in for example Mosquitto, then this works for all applications without further changes.
Users can create a client-certificate through the web-interface and this (client)certificate contains the application id in the CN field. As the client certificate is signed by CA that is trusted by the MQTT broker, the MQTT broker is able to validate that the client certificate is valid.
The CN can be used as username (in Mosquitto), thus with:
I see that this probably should work for our usecases, with overhead upstrem. I still think that there could be many benefits with being able to have tenants as a parent topic to applications. Then it could be possible to restrict access without certificates for every application and to add the possibility to have tenant level certificates.
Is there some particular reason for not having tenants as part of the topics, or is it a “sure, it would be great to have if someone finds the time and creates a pull request for it”?
I’m not considering adding an option to generate tenant certificates (but you would not need ChirpStack to generate these per-se). At some point I would like to change the MQTT itegration topic templates into a single topic_prefix configuration, like the gateway MQTT configuration. This makes things a lot easier. In such case, I might consider adding a {{ tenant_id }} option for the prefix as an option to add more flexibility.
