[Feature Request] Implement Dynamic ACL Rule Updates in TBMQ V 2.0.1 Without Broker Restart

[gaurav36]

Component

• UI
• Core

Description
We are currently using TBMQ V 2.0.1 in our production environment. Our use case involves multiple applications connecting to the broker, subscribing to topics, and communicating through these topics upon subscription.

A core requirement of our application is to support dynamic ACL rule updates for each client application. According to the Eclipse documentation, they offer a dynamic ACL feature (https://mosquitto.org/documentation/dynamic-security/). However, I could not find this feature in the Thingsboard TBMQ documentation or the TBMQ API documentation https://thingsboard.io/docs/mqtt-broker/api/

Could you please guide us on how to implement dynamic ACL rule updates without needing to restart our broker? If there is an API available for this purpose, could you please provide the details?

Environment

• OS: Debian 10 - Buster
• TBMQ: TBMQ 2.0.1
• Browser: Chrome - Latest

[dmytro-landiak]

Hi @gaurav36,

Thank you for reaching out with this valid question.

Currently, TBMQ does not provide direct support for dynamic ACL rule updates via its API. This means that if you update ACLs in specific MQTT client credentials, either the broker must be restarted or the client must reconnect for the changes to take effect. However, you can force a client to reconnect by using the admin call to disconnect the client in the session details tab.

We recognize the importance of this feature for use cases requiring real-time updates to access control rules without interrupting broker or client operations.

Dynamic ACL updates will be added to the roadmap as a potential feature for future TBMQ releases. Our team will explore approaches to implement this capability natively while ensuring it aligns with TBMQ's high performance and scalability standards.

Let us know if you have further questions.

Best regards.

[gaurav36]

Hi @dmytro-landiak , Thanks for this update.

However, you can force a client to reconnect by using the admin call to disconnect the client in the session details tab.

Could you share API/Information how to do so ? Will i loose any data while this reconnection is in progress ? I am using MQTT QoS 1

One update: I am able to update the ACL by using this API:

API Example :

curl --location --request POST 'http://localhost:8083/api/mqtt/client/credentials' \
--header "X-Authorization: Bearer $ACCESS_TOKEN" \
--header 'Content-Type: application/json' \
--data-raw '{
    "name": "testCreds",
    "credentialsType":"MQTT_BASIC",
    "credentialsValue":"{ \"clientId\": null, \"userName\": \"test_user\", \"password\": \"test_pass\", \"authRules\": { \"pubAuthRulePatterns\": [\"test\/.*\"], \"subAuthRulePatterns\": [\"my\/.*\"] } }"
}'

In this API, I am able to update "authRules" parameters.

I can see by executing this API, atuhRules are updating, that i can see in TBMQ GUI. Can you check and update, by doing like above it will really update the ACL without restarting the broker ? Because its updating the username and password.

On the other hand When i only subscribe to "topic3/sub/hello" then when same client publish "topic1/sub/hello4" then i receive this message. How it can be possible ? In broker i don't see any logs related to this.

My publish command output is following:

My current Authorization Rules looks like following:

[dmytro-landiak]

Could you please show me what subscriptions that client currently has?

To view a client's current subscriptions in the TBMQ GUI:

1. Navigate to Sessions.
2. Locate the session using the client_id.
3. Click on the session row.
4. Open the Subscriptions tab.
5. Send me screenshot.

For the API call: You can dynamically update MQTT credentials (username/password/ACL). However, these changes only take effect for newly connected or reconnected clients. Online clients already authenticated with the previous credentials will continue using those values.

[gaurav36]

Hi @dmytro-landiak , Here is the details:

1. Client Details:

2. Client Subscription:

I have 4 tab , where individual tab subscribing to their respective topics, for eg. first tab with same client id subscribe to "topic3/sub/hello" and second tab subscribe to "topic1/#" so on.. Normally Client should receive topic where they are subscribed to

But strange things is that this "topic1/pub/hello4" is not in this client Pub/Sub ACL rule.

However, you can force a client to reconnect by using the admin call to disconnect the client in the session details tab.

Could you also give information / Link of API how can i gracefully disconnect/reconnect the client ? I have python application (In one application, I am going to have multiple clients and these ACL rules need to be updated with those multiple clients), within that I need to perform this.

[dmytro-landiak]

hey @gaurav36 !

Based on the provided screenshot, the client has an active subscription to topic1/#, which allowed it to receive the message published to topic1/pub/hello4. Initially, the ACL likely permitted this subscription, and even after the ACL update, the subscription remained due to the client being persistent—this is indicated by the Clean session flag set to false in the session details.

If this subscription is no longer needed, you can manually remove it from the Subscriptions tab (as shown in the last screenshot).

You can use the following API to disconnect the client. The client should have proper reconnection logic in place to re-establish the session after the disconnection.

In order to programmatically retrieve the current details of the client by the client_id execute the next API:

p.s. As mentioned, we will consider the dynamic updates for online clients based on the changed ACL. This will also apply to removing present subscriptions of persistent clients once the ACL is changed and some subscriptions should be not valid anymore (the case with topic1/# subscription).

[gaurav36]

Hi @dmytro-landiak , Thank you very much for this information and considering dynamic updates Auth Rule as feature request. Its really very basic need for almost all IoT industry. Do you know approximately when are you going to release next TBMQ with this feature ?

I think earlier was a mess by using same client id across multiple tab.

Regarding session API, Its great. Thanks for this information.

Just for experiment i did following things:

1. I connected my clients to the broker for topic subscriptions (using the command line with mosquitto_sub). The client subscribed to multiple authorized topics, along with one additional topic that it wasn’t authorized to subscribe to, all in the same command.
2. The gateway published data to several topics.
3. The client only received the topics it was authorized to subscribe to, and did not receive the additional topic.
4. While the connection remained active, I updated the ACL rules via the "Credential Update" API, adding the previously unauthorized topic.
5. The ACL rule was successfully updated.
6. The gateway published data to the additional topic.
7. The client still did not receive that topic.
8. I used the Client Session API to disconnect the client session, which was successful.
9. However, the client remained connected, possibly because mosquitto_sub automatically re-established the session.
10. Data was published again to the additional topic.
11. The client successfully received it.

for the python i am using paho mqtt, and still need to do this experiment. Do you have information for proper reconnection ?

I think in my special usecase i do not need to use -c flag as i have dynamic topic subscription/un-subsribe/re-subscription/ need in my application.

[dmytro-landiak]

Hi @gaurav36,

The next minor TBMQ release (2.1.0) is planned for approximately the end of next month. However, it’s not yet confirmed whether this feature will be included in that release.

Based on the 11 steps you described, everything looks correct, and the result you’re seeing aligns with the current implementation. You’re right that the mosquitto_sub tool will automatically reconnect when disconnected, as this behavior is built into the tool.

As for the Paho MQTT Python client, it might be best to consult their official documentation for more detailed guidance, as we’re not experts in this specific library. Below are some hints that might help point you in the right direction.

https://pypi.org/project/paho-mqtt/

[gaurav36]

Thank you very much @dmytro-landiak for your insight.

Looking forward for your next release, I hope you will include this important feature :)