No security mechanism implemented

[antonio-gomez-navarro]

If I am not wrong, there is no authentication/authorization mechanism implemented. Once installed, anyone could send messages to the MQTT endpoint.

Do you know how I could implement at least a simple user and pass authentication? Do you plan to integrate this functionality in the future?

[ppatierno]

You are right there is no such thing for now. There is no plan or ETA but any contributions are very welcome.

[antonio-pedro99]

If I am not wrong, there is no authentication/authorization mechanism implemented. Once installed, anyone could send messages to the MQTT endpoint.

Do you know how I could implement at least a simple user and pass authentication? Do you plan to integrate this functionality in the future?

Hi @antonio-gomez-navarro, thanks to bring this out to our attention. Yes, we do not handle any kind of authentication/authorization.

[antonio-pedro99]

@ppatierno Because this came out, I think we should support OAuth to start as Strimzi has https://github.com/strimzi/strimzi-kafka-oauth.

EDIT: I do not know if there is a plan to add support for MQTT v5, but it would make everything easy when dealing with authentication/authorization.

[antonio-pedro99]

Do you know how I could implement at least a simple user and pass authentication? Do you plan to integrate this functionality in the future?

Answering this question, you can write a basic gateway to authenticate and authorize your MQTT clients before they connect or produce messages through the bridge. This can be a small python script using paho-mqtt and any auth provider of your choice.
ATT: I have not tested it, and I am not sure it is suitable for your use case, so try at your own risk.

[ppatierno]

I am not sure it's simple as you are describing.
An MQTT client cannot connect to a gateway first to be authenticated/authorized and then, if it's ok, it connects to the MQTT bridge. The auth process has to happen on the connection to the bridge, or your API gateway should connect to the bridge when a client connect to it. It means that API gateway cannot be a simple Python script as you describe.
Also MQTT v3 has only username/password for auth which would need TLS as well to avoid security issues.
Finally, regarding OAuth it's not just about moving to MQTT v5 (which is a big move itself) but also not sure that strimzi oauth could be used for this purpose.

[antonio-pedro99]

I am not sure it's simple as you are describing.
An MQTT client cannot connect to a gateway first to be authenticated/authorized and then, if it's ok, it connects to the MQTT bridge. The auth process has to happen on the connection to the bridge, or your API gateway should connect to the bridge when a client connect to it. It means that API gateway cannot be a simple Python script as you describe.

As I said, I have not tested it so I can't ensure we get rid of any complexity. It was an initial workaround.

And I agree with you, this auth should come from the Bridge only. In this scenario, where the Bridge does not have any support for auth, this gateway would somehow be helpful.

Let's see a breakdown of the working gateway, it should:

• have an oauth server connection along with all details it needs.
• setup everything needed to authenticate and authorize clients
• have the MQTT Bridge connections details(IP and the port)
• have its own mqtt server to receive connection and publish "message" types from clients: the clients will need to connect to the gateway and the gateway to the Bridge.
• on client trying to connect, authenticate against the username/password provided.
• on receiving publish message type from the connected device, check if the client is authorized and forward the message to the Bridge.
• and more

Maybe some extra configuration/behavior would be needed.

Note that the MQTT clients does not have to connect with the Bridge. In the end, the MQTT clients just need to be aware of the gateway.

Again, I have to agree with you that it might not be an easy task as I mentioned early.

[ppatierno]

It was an initial workaround

Well it's a big workaround I would say. You are rewriting an MQTT server from scratch in the end (notice I said an MQTT server not an MQTT broker).
You are actually rewriting an Nginx for MQTT (i.e. Nginx is exactly the solution we suggest for the HTTP bridge which has the kind of same missing feature).

[antonio-pedro99]

Yeah, even paho-mqtt might not be helpful because it was built necessarily to create MQTT clients and not servers.
Talking about Nginx, maybe use it as a reverse proxy for MQTT work?

I did a quick search and found this useful: https://www.nginx.com/blog/nginx-plus-iot-security-encrypt-authenticate-mqtt

ATT: Just because the Bridge does not support Auth yet.

[ppatierno]

But Nginx Plus is not free and/or open source AFAIK.

[antonio-pedro99]

But Nginx Plus is not free and/or open source AFAIK.

You are right, it is not free nor open source.