Programmatically setting access control limits in

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?

Answer 1

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.

Answer 2

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.

Answer 3

If you are familiar with Java you should try the HiveMQ MQTT broker: http://www.hivemq.com.

There is an open PluginSDK, which enables you to write any kind of extensions to the broker.

You can implement the authentication or authorization method that fits your use case best, for example from database, file...

The authorization based on topic is a common use case and there is an example in the HiveMQ Plugin Guide.

As entry point into HiveMQ plugin development see the Get started with Plugins page: http://www.hivemq.com/documentations/getting-started-plugins/

Disclosure: I'm one of the developers of HiveMQ.