Trivore Identity Service (TIS) utilises Role-Based Access Control (RBAC). The basic building blocks or RBAC are roles, permissions and resources. Permissions allow a principal, such as a user, to access some specific resource or perform some specific action like editing user accounts, for example.

Roles consist of one or more permissions and can be simply thought to be a group of permissions. Users are then given one or more roles depending what kinds of tasks they need to perform. In practise, the views which a user sees in the Main Menu and can access, depends on assigned roles and permissions at any particular time. Also many views will only allow users read-only access if the users do not have the required permission to manage the objects.

TIS extends the basic RBAC model by introducing groups. In addition to giving users roles, roles can be added to a group so that all user members of that group will gain the roles. The  paths from permission to user will be covered in more detail later in this chapter.

Roles and permissions

Role is a management unit in TIS. Roles are preferably assigned to user groups, but may still be assigned to user accounts directly. This direct assignment is being phased away in a future release. TIS has two roles classes: built-in static System Roles and flexible Custom Roles. Most System Roles have two permission levels: Admin and Auditor, which are depicted in the role names. Admin may administrate and manage, Auditor may view.

If we look at the roles more carefully, we see there is an additional concept tightly related to a role, namely a permission. A permission is a detailed item. There is a large number of permissions in TIS each allowing a certain small thing to be done. If that permission is missing (example: list user accounts), the signed in user account is not able to do any task which requires that permission.

Some permissions, like listing user accounts, are required by many roles, so there is some overlapping. Due to the rather technical nature of permissions, they are not widely or often discussed, but it is important to understand they exist and they make the basis for roles to function. If you need to make a Custom Roles, you need to understand Permissions, as you are essentially assigning Permissions to a Custom Role, and then later via Group to a user Account.

The access model in TIS is very fine grained and there are over 130 different permissions in the core system alone. The business extensions may also introduce additional permissions to the system. Event though there is a large number of permissions, they are well organised and their structure is logical. There are about 30 different pre-defined roles, which makes it easy to give each user a functional set of permissions so that they can complete their tasks.

User permission paths

Users may gain permissions through multiple paths. The paths are listed below in order of preference. Directly setting roles, and permissions to user is deprecated and should be avoided if possible.

1. Custom roles through groups

2. Custom roles through namespace default account policy (special case, gives roles to all accounts within a namespace)

3. Direct Custom roles (deprecated)

4. Direct System roles (deprecated)

5. Direct permissions (deprecated)

The recommended role structure

From time to time it is necessary to refresh architecture, and now it is time for simpler and more understandable RBAC. Then new schema is shown below, and as you can see, it is more elegant.

Open

There are just Roles, and you can freely manage them in your namespace.

All Roles are assigned normally to a Group. There is one special use case, where groups are not used in name space, yet some roles and related permissions should be assigned to those all users. In this case it is possible to assign role(s) to the Default Account Policy, as it is applied to all users when they sign in.

The current complexity is being reduced after collecting and analysing customer feedback. You know, sometimes there can be too much flexibility, as it may reduce usability and learnability.

Namespaces can define a set of custom roles to be given to all user accounts in the namespace by adding one or more custom roles to the namespace default account policy.

Direct permission paths

As mentioned before, these permission paths are considered outdated and their use is not recommended. They are still documented and technically working for the sake of backwards compatibility and to allow smooth transition to the newer role structure.

The direct roles, both System and Custom Roles,  and permissions can be managed in the user account editor in the Web UI. The Management API also has endpoints to manage direct roles and permissions.

Open

Migrating to the newer role structure

When migrating to the new role structure, it can be done in small steps. There is no need to change all roles right away, but rather use the new role path when making changes to existing structures. For example, when assigning a new role to a user, instead of using the old system role, add the user to a group with a new role with same permissions as the old system role.

The Web UI provides some tools to ease the migration to the new role Within the Roles view is another view, where administrators can re-create the old system roles as new customisable roles.