Access Management
Access management is one of most important features of Trivore Identity System (TIS). It allows defining which users has access to which features and what kind of objects they are allowed to manage and view.
TIS access control was designed to be flexible to meet the needs of most organisations. The user role and permission management is based on the principle of Role-based access control (RBAC). The main idea behind RBAC is that permissions are part of a role and the roles are then given to users. This makes 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 role has a set of permissions attached to them. The roles are then attached to groups and users belonging to the group gain the permissions in the role.
TIS also has built-in system roles. They currently work, but are considered deprecated and may be removed in the future. Their use is not recommended. The recommended way of giving roles to users is to first create the role dynamically if it does not exist already, then create a group where the role is attached to. After that the user should be added to the group.
Users may have a set of roles and permissions from various sources. Users can gain permissions directly, or through roles or groups with roles.
Most Management API endpoints can be accessed by external applications by using OpenID Connect. In this case, it is the user who is authorising the client to perform actions on the users' behalf. In this flow, both the user and the client are responsible for the actions performed by the client. The user has to authorize the client to perform actions by approving client's requested scopes while signing in.
Management API Client access management
Management API Clients have an owner and are tied to namespaces. If the user is allowed to administer multiple namespaces, then the Management API Client may also have multiple namespaces. The namespaces can be chosen for the client in the Web UI’s Management API Client view.
Like users, also Management API Clients have permissions. The clients don't have roles or groups, but instead the permissions are directly attached to them. Permissions can be given to the client in the Web UI's Management API Client editor.
Users are only able to give Management API Clients permissions they have. For example, if a user wants to give a Management API Client a permission to modify user accounts, then the prerequisite is that the user has the permission to modify user accounts.
Entity access control lists
Some entities have additional more fine grained Access Control Lists (ACL). The ACLs are needed when only a subset of users or Management API Clients should be allowed to access certain objects. The ACLs in TIS can be roughly categorised into two different groups. The core functionality is very similar and the only noteworthy difference is that in some entities the ACLs are predefined and re-used and other entities have ACLs that only exist within that entity.