Skip to main content

Access Management

Access management is one of the most important features of Trivore ID. It defines which users have access to which features, and what kind of objects they're allowed to manage and view.

Trivore ID's access control is designed to be flexible enough to meet the needs of most organisations. Role and permission management is based on Role-Based Access Control (RBAC): permissions are grouped into roles, and roles are given to users — making it easy and cost-efficient to manage permissions for a large user base.

User access management

Roles can be created dynamically based on the organisation's needs, each with a set of permissions attached. Roles are then attached to groups, and users belonging to a group gain the permissions in its roles.

Trivore ID also has built-in system roles. They currently work, but are considered deprecated and may be removed in the future — their use isn't recommended. The recommended approach is to first create a role dynamically (if one doesn't already exist), attach it to a group, then add users to that group.

Users may accumulate roles and permissions from multiple sources — directly, or through roles or groups with roles.

Most Management API endpoints can also be accessed by external applications via OpenID Connect, where it's the user authorising the client to perform actions on their behalf by approving the client's requested scopes while signing in. In this flow, both the user and the client are responsible for the actions the client performs.

Management API Client access management

Management API Clients have an owner and are tied to namespaces — if the owning user administers multiple namespaces, the client can be tied to multiple namespaces too, configurable in its Management UI editor.

Like users, Management API Clients have permissions — but no roles or groups; permissions are attached to them directly, in the client's editor. A user can only grant a Management API Client permissions they themselves already have — for example, granting permission to modify user accounts requires the granting user to have that same permission.

Entity access control lists

Some entities support additional, more fine-grained Entity Access Control lists (ACLs), for cases where only a subset of users or Management API Clients should be able to access certain objects.