I am working on an application that will use mqtt. I will be using the python library. I have been leaning towards using mosquitto but can find no way of programmatically setting access control limits for it. The application I'm writing needs to be able to differentiate between users, and only allow them to subscribe to certain topics. The current solution looks like this is done from a config file. Is there a scalable solution to access control limits in mosquitto? If not, do you know of a mqtt broker in which this exists?
Even if this might not concern you anymore, others could find it useful. I am following here mosquitto's man page.
There are two configuration files, a general one, say mosquitto.conf
, and an ACL (Access Control List) one, say acl.conf
.
mosquitto.conf
enables the acl.conf
file for access control:
acl_file acl.conf
acl.conf
defines the access control behavior:
# users can anonymously publish to the topic 'in'
topic write in
# users can subscribe topics named 'out/%u', where %u is the user's name
pattern read out/%u
# an admin may subscribe to 'in'
# and publish to all subtopics of 'out/' (note the +)
user adminWithSecretName
topic read in
topic write out/+
We execute mosquitto -c mosquitto.conf
to run mosquitto with the configuration file.
In this case, a dynamic authentication mechanism can be established by using randomly generated user names.
Example: Alice wants to subscribe so that she can read here private messages. She sends her credentials in combination with a nonceN1
to in
. Furthermore, she also subscribes the topic out/N1
, using N1
as user name. The pattern read out/%u
allows that.
A third-party server application, connected as adminWithSecretName
and subscribed to the topic in
receives Alice' message. It verifies its authenticity and then generates a new nonce N2
and publishes it to out/N1
where Alice has subscribed to.
From now on -- at least for this session -- out/N2
is the regular topic where Alice respectively here devices will receive messages. Therefore, Alice unsubscribes and disconnects form out/N1
and subscribes to out/N2
. The third-party server application publishes all new messages, belonging to Alice, to the topic out/N2
.
Further Considerations: One may also want to reflect on other aspects of security such as TLS and/or per-message encryption. The configuration discussed here would, depending on the grade of targeted security/privacy, probably also require TLS. On the other hand, this could be obsolete if the messages are encrypted separately. One, say Eve, could intercept (even subscribe!) the messages if she had access to the cable/WiFi stream, as she would see the secret user name as plain text. But: when one already has access to the data stream, he/she can intercept the bytes anyway. They are encrypted either way, using TLS or per-message encryption. Also, traffic analysis may be applied to both approaches.
I would suggest to use either TLS or per-message encryption. Both should, correctly implemented and applied, lead to comparable security.
You could write a plugin to handle this for you. See http://mosquitto.org/2013/07/authentication-plugins/ for some examples.
You may find more answers if you ask on the mosquitto mailing list.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With