问题描述
我正在开发将使用mqtt的应用程序.我将使用python库.我一直倾向于使用mosquitto，但是找不到以编程方式为其设置访问控制限制的方法.我正在编写的应用程序需要能够区分用户，并且只允许他们订阅某些主题.当前的解决方案看起来是通过配置文件完成的.是否有可扩展的解决方案来解决蚊子的访问控制限制?如果不是，您是否知道存在的mqtt经纪人?
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?
推荐答案
即使这可能不再与您有关，其他人也会发现它很有用.我在这里关注mosquitto的手册页.
Even if this might not concern you anymore, others could find it useful. I am following here mosquitto's man page.
有两个配置文件，一个是普通配置文件，例如mosquitto.conf，另一个是ACL(访问控制列表)，配置文件是acl.conf.
There are two configuration files, a general one, say mosquitto.conf, and an ACL (Access Control List) one, say acl.conf.
mosquitto.conf启用acl.conf文件进行访问控制:
mosquitto.conf enables the acl.conf file for access control:
acl_file acl.conf
acl.conf定义访问控制行为:
# 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/+
我们执行mosquitto -c mosquitto.conf以使用配置文件运行mosquitto.
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.
示例:Alice想要订阅，以便可以在此处阅读私人消息.她将她的凭据与现时N1一起发送给in.此外，她还使用N1作为用户名订阅主题out/N1.模式read out/%u允许这样做.
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.
以adminWithSecretName连接并订阅主题in的第三方服务器应用程序收到Alice的消息.它验证其真实性，然后生成一个新的随机数N2并将其发布到爱丽丝已订阅的out/N1.
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.
从现在开始-至少对于该会话来说-out/N2是常规主题，在这里，Alice和此处的设备将分别接收消息.因此，爱丽丝取消订阅并断开表单out/N1的订阅，并订阅了out/N2.第三方服务器应用程序将属于Alice的所有新消息发布到主题out/N2.
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.
其他注意事项:人们可能还想对安全性的其他方面进行思考，例如TLS和/或按消息加密.根据目标安全性/隐私的等级，此处讨论的配置可能还需要TLS.另一方面，如果对消息进行单独加密，则可能会过时.夏娃说，如果她可以访问有线/WiFi流，则可以拦截(甚至订阅！)消息，因为她会看到秘密用户名是纯文本.但是:当一个人已经可以访问数据流时，他/她仍然可以截取字节.它们使用TLS或按消息加密的任何一种方式进行加密.另外，流量分析可以同时应用于这两种方法.
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.
我建议使用TLS或按消息加密.两者都应正确实施和应用，才能达到可比的安全性.
I would suggest to use either TLS or per-message encryption. Both should, correctly implemented and applied, lead to comparable security.
这篇关于以编程方式在mosquitto中设置访问控制限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！