Role-Based Access Control

Role-Based Access Control (RBAC) governs what a TBMQ user can do in the web UI and REST API — which broker features they can view versus change. Every TBMQ account is a broker administrator account; the assigned role decides whether that access is full or read-only.

RBAC controls administrative access to the broker. It is distinct from MQTT topic authorization, which decides what an MQTT client may publish to or subscribe from and is configured per client credentials.

TBMQ ships two predefined roles. They are built in and cannot be added to, edited, or removed — you assign one of them to each user.

Role	Access
Administrator	Full access — can create, read, update, and delete every broker entity and setting.
Viewer	Read-only — can view all broker data but cannot create, modify, or delete anything, nor perform administrative actions.

Permissions are evaluated per operation — create, read, write, delete. An Administrator is allowed every operation; a Viewer is allowed only read operations, so any attempt to change something is rejected with a permission-denied error. The model is operation-based: there is no per-feature or per-entity permission tuning beyond these two roles.

A role is assigned when you create or edit a user on the Users page. Each user has exactly one role.

When users sign in through OAuth 2.0 / SSO, their role is resolved from the identity provider using the role strategy configured on the OAuth 2.0 client:

• Static — every user who signs in through this provider is assigned one fixed role.
• Dynamic — the role is derived from a claim in the user’s token, mapping its values to Administrator or Viewer. If a value matches both lists, Administrator takes precedence; if nothing matches, the login is denied.

• Assign Administrator to team members who configure and maintain the broker environment.
• Assign Viewer to operations or monitoring staff who need visibility into broker state and client activity without the ability to make configuration changes.