Overview
Snapdragon Guardian restricts what a user can see and do using three building blocks:
- Permission — a named bundle of Authorities (e.g.
command.locate,device.write) representing a job function. - Permission Group — a team of users. It is assigned one or more Permissions and scoped to one or more Device Groups.
- Device Group — a collection of devices that a Permission Group can be scoped to.
A user's access is the union of every Permission Group they belong to. Superusers bypass all of this and have unrestricted access to every device and operation — only Superusers can create Permissions and Permission Groups.
Any member of a Permission Group can automatically browse (read) all devices in that group's scoped Device Groups, regardless of which Permissions the group has. Only command/write operations require an explicit Permission.
This page covers Authorities and Permissions — the building blocks of what a user can do. See Device / Permission Groups for who gets those Permissions and which devices they apply to, and Known Issues / Limitations for current workarounds.
Endpoints
1. List available Authorities
Authorities are the atomic, built-in actions in the system. They are seeded and read-only — you cannot create, rename, or delete them. Use this to decide which Authorities a Permission should bundle.
Request:
GET /qrms/authoritiesResponse (200):
[
{
"id": 2,
"name": "device.write",
"description": "Create/Update device information",
"value": 2
},
{
"id": 3,
"name": "command.read",
"description": "View command history and status",
"value": 3
},
{
"id": 4,
"name": "command.locate",
"description": "Execute locate command",
"value": 4
},
{
"id": 10,
"name": "command.reset",
"description": "Execute reset command",
"value": 10
},
{
"id": 24,
"name": "event.read",
"description": "View stored events",
"value": 24
}
]There is no device.read authority — read access to devices is implicit for any member of a Permission Group scoped to that device's Device Group.
2. Create a Permission
A Permission is a named, reusable bundle of Authorities (e.g. Operate, FullAccess). Superuser only.
Request:
POST /qrms/permissions{
"name": "Operate",
"description": "Can locate and reset devices",
"authorityIds": [4, 10]
}Response (200):
{
"id": "a1b2c3d4-e5f6-4a1b-8c2d-3e4f5a6b7c8d",
"name": "Operate",
"description": "Can locate and reset devices",
"authorities": [
{
"id": 4,
"name": "command.locate",
"description": "Execute locate command"
},
{"id": 10, "name": "command.reset", "description": "Execute reset command"}
]
}Save the returned id — it's used to assign this Permission to a Permission Group (see Device / Permission Groups). PUT /qrms/permissions/{id} is also Superuser-only and takes the same body shape to update name/description/authorities.
3. Delete a Permission
Superuser only. Deleting a Permission also removes it from every Permission Group it was assigned to (cascade).
Request:
DELETE /qrms/permissions/a1b2c3d4-e5f6-4a1b-8c2d-3e4f5a6b7c8dResponse (200):
{
"success": true
}4. Configuring Superusers (Entra ID)
Superusers can be promoted and revoked using directory group membership. For this we need to update configuration on the User Management (UM) service, not a Snapdragon Guardian endpoint. Set the following environment variable on the UM service to the name of our company's Entra ID group whose users we want to become superusers:
| Environment Variable | Value |
|---|---|
SUPERUSER_QGROUP | <entra-id-group-name> |
UM automatically syncs membership of that Entra ID group on a regular interval — every current and future member of the group is granted the Superuser role with no manual step per user. Removing someone from the Entra ID group revokes their Superuser role on the next sync.
See Known Issues / Limitations for the sync delay this introduces.