For the complete documentation index, see llms.txt. This page is also available as Markdown.

Access Control for Admin UI

Configure fine-grained access permissions for Admin UI features and operations.

Every page and operation in the Connectware Admin UI is backed by an HTTP permission. This means you can control exactly which features each user can see and interact with by assigning the appropriate HTTP permissions to their role.

How It Works

The Admin UI makes HTTP requests to the Connectware REST API on behalf of the logged-in user. Each request is checked against that user's permissions. If the user does not have the required permission for a given endpoint, the corresponding UI element — a page, a button, or a table — is hidden or disabled.

This means that:

  • A user with read-only HTTP permissions on /api/services can view services but cannot install, enable, or delete them.

  • A user with no permissions on /api/users does not see the User navigation item at all.

  • Access is additive — a user with multiple roles sees the union of all their roles' permissions.

Default Roles

The following built-in roles cover the most common access patterns:

connectware-admin — full access to all Admin UI pages and operations. Assign this role only to system administrators.

minimum-access — read-only access to a limited set of Admin UI pages. Users with this role can log in and view basic system information but cannot change anything. This role is a useful starting point for custom roles with limited scope.

For the complete list of pages accessible with minimum-access, see:

Admin UI Pages Available to Minimum Access Users

Designing Custom Roles

If the built-in roles do not fit your use case, create a custom role with exactly the permissions your users need. A common pattern is:

  1. Start with minimum-access as a baseline — copy its permissions into a new role using the Copy Permissions field in the Create Role dialog.

  2. Add the additional HTTP permissions for the features you want to enable.

  3. Assign the role to your users.

Common Patterns

Role type
Suggested permissions

Service operator (read-only)

minimum-access permissions + read on /api/services/#

Service operator (full)

minimum-access permissions + read/write on /api/services/#

User administrator

minimum-access permissions + read/write on /api/users/# and /api/roles/#

HTTP permissions use the same wildcard syntax as MQTT permissions. /api/services/# grants access to all endpoints under /api/services/. For full permission syntax, see Permissions. For the exact permission required by each page, see the reference below.

Full Permissions Reference

For a complete mapping of which HTTP permission is required for each Admin UI page and operation, see:

Admin UI Permissions

Last updated

Was this helpful?