¶ Permissions and authorization
This guide explains how authorization is evaluated in IoT Cloud.
Scope of this page:
- instance/project/object structure/object authorization inside one instance
- user and device permission evaluation
- no DBM global/host/service administrative model
It is split into:
- quick overview for everyday users
- detailed flow for administrators and architects
For each action, the platform evaluates permissions in layers:
- Instance
- Project
- Object structure
- Object (when object authentication is enabled)
- User permissions are broader and include governance permissions (for example Architect, Role moderator, Admin).
- Device permissions are usually narrower and focused on object/data operations.
- Both are evaluated through role membership and defaults.
At project/object structure/object level, the key operational permissions are:
- Object manager
- Data analyst
- Data source
- Data manager
| Scope |
User assignable |
Device assignable |
Main permission families |
| Instance |
Yes |
No (instance-only bits) |
UserInstancePermissions, user governance extension |
| Project |
Yes |
Yes |
UserProjectPermissions (user), IndividualProjectPermissions (device) |
| Object structure (OT) |
Yes |
Yes |
IndividualTablePermissions (operational bits) |
| Object (O) |
Yes |
Yes |
IndividualTablePermissions (operational bits) |
See also: Permission Matrix for the programmer-oriented full matrix.
For users:
- Collect permissions from all user roles in the instance.
- Add default user permissions configured on the instance.
- Check required permission for the requested action.
For devices:
- Instance-level user extension permissions are not used directly.
- Device behavior is primarily controlled at project and lower levels.
- All projects access
- Group organizer
- Architect
- Role moderator
- Admin
For users:
- Collect role permissions granted on the project.
- Add project default user permissions.
- If All projects access is enabled, include instance-derived user permissions as part of effective project authorization.
For devices:
- Collect role permissions granted on the project.
- Add project default device permissions.
- Device project permissions use
IndividualProjectPermissions (they are not assigned only as IndividualTablePermissions).
Important:
- Users still need valid instance access.
- Devices are already inside instance context, so project access is the primary gate.
For users and devices:
- Start with effective project permissions.
- Add explicit role permissions granted on the object structure.
- Evaluate required operation permission.
If object authentication is enabled:
- Start with object-structure effective permissions.
- Add explicit role permissions granted directly on the object.
If object is private:
- explicit object permissions are required
If object is not private:
- object-structure permissions remain applicable
¶ Default permissions and role permissions
Both are always important:
- role permissions define delegated access by profile/group
- default permissions define baseline access in the given scope
This allows stable baseline access plus role-specific elevation.
- Basic
- Object manager
- Data analyst
- Data source
- Data manager
- Architect
- Role moderator
- Admin
- Group organizer (instance)
- All projects access (instance)
The following descriptions are aligned with enum comments in:
E:\wamp64\www\iot-node-manager\app\Shared\Model\Enums\UserInstancePermissions.phpE:\wamp64\www\iot-node-manager\app\Shared\Model\Enums\UserProjectPermissions.phpE:\wamp64\www\iot-node-manager\app\Shared\Model\Enums\IndividualProjectPermissions.phpE:\wamp64\www\iot-node-manager\app\Shared\Model\Enums\IndividualTablePermissions.php
- All projects access: equivalent to base project access on all projects during project authorization.
- Group organizer: can create groups.
- Architect: can modify table structures (create/edit/delete; includes deleted visibility but not force delete).
- Role moderator:
- instance scope: can manage user/instance permissions and defaults, invite users to instance, manage roles including devices, see instance users
- project scope: can manage role/project permissions and defaults, invite users to project, see project users, add role/table permissions except private objects
- Admin:
- instance scope: can manage projects and permissions, see details/history/deleted entities
- project scope: can see/use deleted project/tables/rows and read history details
- Private objects entrusted: can see all private objects.
- Task/file permissions also exist in this enum family, but they are not part of the standard object/data authorization path documented on this page.
- Object manager: can add/edit/delete object table rows; includes object-table operations and private-object access operations.
- Data analyst: can view and process data.
- Data source: can insert data and read last value.
- Data manager: can edit/delete data and read last value.
¶ Assignable permission sets by identity and scope
| Scope |
User permissions set |
Device permissions set |
Notes |
| Instance |
UserInstancePermissions + user governance extension (UserProjectPermissions) |
N/A for instance-only bits |
Devices are evaluated mainly from project and below. |
| Project |
UserProjectPermissions + inherited table/data bits |
IndividualProjectPermissions (inherits table/data bits) |
This is where device project rights are assigned. |
| Object structure (OT) |
table/data operational permissions |
table/data operational permissions |
Per-structure role grants refine project-level rights. |
| Object (O) |
table/data operational permissions |
table/data operational permissions |
Applied when object auth is enabled; private objects require explicit rights. |
Note:
- This page covers authorization inside instance/project/object scopes.
- DBM administrative permissions are documented separately in Admin permissions.
Usually missing:
- Object manager on object structure or object
Usually missing:
- Data source permission in the target scope
- or role binding on project/object structure/object
Usually missing:
- Role moderator or Admin in effective user permissions