Programmatically setting access control limits in mosquitto

Question

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?

Accepted Answer

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 nonce`N1` 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.

Programmatically setting access control limits in mosquitto

Solution

Problem