Access Control Lists (ACLs) control what topics a given username/password pair is allowed to publish and subscribe on. ACLs should be designed with a 'principal of least privilege' model while also considering device management and maintenance. For example gateways and devices in the field should be limited to publishing and subscribing only on the topics for which they should be expected to. The same should be true of 'consumer' applications that will be either sending commands to devices in the field or consuming data coming from those devices.
| It is important to note that a username is not limited to a single MQTT client. You will need to create separate users for each publishing and/or subscribing client, such as MQTT Transmission and MQTT Engine, if each one has a different Read/Write requirement. |
If you are new to MQTT topics, the Eclipse Foundation's Paho project provides good information here on the basics of wildcards.
For subscriptions, two wildcard characters are supported:
ACLs are defined by the following format: [R|W|RW] topic where:
R = Read or 'subscribe' privileges
W = Write or 'publish' privileges
RW = Read and Write (subscribe and publish) privileges
topic = The topic or wildcard topic representing the scope of the privilege
RW #
R #
W #
| ACLs are case sensitive. This means that setting a users ACL to R spbv1.0 will not allow a user to subscribe to spBv1.0/# topics |
W spBv1.0/GroupID/+/EdgeNodeID/#
R STATE/PrimaryHostID, R spBv1.0/GroupID/+/EdgeNodeID/#
W device_one/temp/#,R state/#
RW spBv1.0/GroupID/+/EdgeNodeID/#, RW spBv1.0/STATE/PrimaryHostID
RW STATE/PrimaryHostID, RW spBv1.0/STATE/PrimaryHostID, RW spBv1.0/GroupID/+/EdgeNodeID/#
When creating an Access Control List (ACL) for MQTT Engine client, there must be RW privilege's for the MQTT Sparkplug™ B STATE message topic spBv1.0/STATE/primary_host_id Review Changes to the STATE message in the Sparkplug v3.0.0 Specification for details on the legacy STATE client topic |