Definition
RBAC (Role-Based Access Control) associates users with roles and roles with permissions to achieve fine-grained permission management. Device Management Platform uses RBAC to control access of different roles to devices, OTA, alarms, and other functions, along with Audit Log to record operations.
Models and Permission Granularity
Core elements of RBAC include users, roles, permissions, and resources. Permissions can be refined into functional permissions (such as OTA delivery, remote control) and data permissions (such as isolation by product, group, region). Device Management Platform typically defines roles like administrator, operations, read-only, and auditor; it supports role inheritance and combination to meet complex organizational structures. Data permissions can be implemented based on Device Grouping and tenant isolation, ensuring users can only access devices and data within the authorized scope.
Integration with DMP
The platform implements RBAC checks uniformly across APIs, the console, bulk operations, and other entry points. Sensitive operations (such as OTA issuance, device deletion, credential reset) may require secondary authentication or an approval process; Audit Log audit logs record who performed what operation at what time, supporting compliance and security audits. When integrated with identity sources such as SSO or LDAP, external users/groups need to be mapped to platform roles to achieve unified identity and permission management.
Use Cases
Applicable to multi-tenant SaaS platforms, multi-department collaboration within enterprises, scenarios where outsourced operations and internal audits are separated, and other situations. Fine-grained RBAC can minimize the exposure of permissions, reduce the risk of operational errors and privilege escalations, and meet compliance requirements such as MLPS (Multi-Level Protection Scheme) and ISO 27001.
How role, permission, and resource scope stack
Role-based access control separates who someone is from what they may do. A user joins roles. A role then carries feature permissions and a resource scope. Feature permissions decide whether remote control, upgrade, delete, and credential reset are visible at all. Resource scope decides which products, groups, tenants, or regions those entries apply to. Both layers are judged on the same request. Judging only the feature lets an operations role send commands to every device on the platform. Judging only the scope still lets a read-only account start an upgrade inside its own group, if that account was also granted the upgrade API.
A role should express a stable duty. It should not be cloned, almost unchanged, for every temporary project. Project differences belong in the resource scope: the same field-operations role sees only site A's group for people at site A, and only site B's group for people at site B. Keep inheritance short. Deep inheritance makes the effective permission set impossible to state aloud. A sensitive action, such as a bulk restart or credential revocation, should ask for a separate confirmation after the role already allows it. Record that confirmation in the audit. The confirmation step is not itself the role.
When a role remains valid after the organization changes
A role model stays usable over time only when staff changes in the identity source show up on platform accounts. If a departure, an expired contractor, or a merged department is disabled only in the personnel system, the platform account is still valid, and a finely drawn role does not stop the old session. When connecting an external directory, map groups to roles. Do not copy every person in the directory in as a platform administrator. The mapping table itself must be auditable: which external group corresponds to which platform role and which resource scope.
A temporary grant should carry an end time. Borrowed upgrade permission is withdrawn when it expires, rather than waiting for someone to remember to change it back. A shared account does not fit this model. The audit can see the account and not the person who acted, so it is later impossible to say who confirmed a remote control action. API calls and the console use the same decision. It must not be possible for the button to be hidden while a token can still call the write API. A batch task freezes the resource scope it had at creation time. Otherwise a task that is still queued keeps applying to a new device set after the operator has been reassigned.
When feature permissions are opened and data scope is not tightened
The usual slip is to give implementers a role with almost every menu, while the data scope is left empty and the system reads empty as unlimited. The screen can then search other tenants' devices, and export, upgrade, and work order dispatch all cross the contract boundary. An empty scope should mean deny, not everything. A role that truly needs the full set must select a platform-wide scope explicitly, and that choice needs its own approval.
Another mistake is to filter by group only on the query API, while the write API acts directly on a device identifier. Anyone who knows the identifier can change a device they do not own. The write path must check again that the identifier falls inside the caller's current resource scope. If copying a role also copies its scope, a new person inherits the previous person's site access. The configuration looks fine, but the scope was copied too wide. After a role change, old sessions must load permissions again. Otherwise a page that is already open keeps using the cached decision until the token expires.
After a permission change, spot-check a list of what is actually in effect, not only the role edit page. The list includes the write APIs that account can call, a sample of device identifiers it can see, and a sample from a neighboring tenant it must not see. If the neighboring sample still opens, the scope check never entered that API. Before deleting a role, list the accounts and unfinished tasks that still reference it. If a task froze the old scope, decide whether it finishes under that frozen scope or stops immediately. Without that step, deleting the role only makes new logins fail, while the old task keeps running outside its authority.