Role-based access control (RBAC)

Heads up!

In the future System and Custom Roles will be merged to just Roles.

Trivore Identity Service (TIS) utilises Role-Based Access Control (RBAC). The basic building blocks in RBAC are roles and permissions. Permissions allow a principal to perform some action like editing user accounts. 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 users see in the Main Menu and can access, depends on assigned roles and permissions at any particular time. Also views will only allow users read-only access if the users do not have the required permission to manage the objects.

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 do their work.

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.

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. The System Roles still work, but should no longer be used as giving Custom Roles through groups is considered a better option.

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 at all possible.

Custom roles through groups
Custom roles through namespace default account policy (special case, gives roles to all accounts within a namespace)
Direct Custom roles (deprecated)
Direct System roles (deprecated)
Direct permissions (deprecated)

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.

Image below shows the different paths from Permissions to Accounts.

The new 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.

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.

Click here to expand...

Role classes and the special roles

Roles are divided into two main classes: Admin and Auditor. In addition there are two special roles: Multi-namespace and Developer.

System Roles

System Roles are designed to cover 99 % of use cases. This is why getting to know the System Roles is important. The full list of these roles is below in section 6.3. Next we will discuss the most important System Roles, and the difference between the two classes.

Admin class roles have the right to view, create, modify and remove objects.
Auditor class roles have the right only to view objects.

In general, Admin class has full read-write access to its objects, and Auditor class has only read-only access.

For roles Namespace Admin and Namespace Auditor the object in question is the namespace and its settings.

For roles Account Admin and Account Auditor the object in question is a user account and user account policies.

For roles Role Admin and Role Auditor the objects in question are the role definitions in a namespace and on each user account in the namespace.

For roles Group Admin and Group Auditors the object is a group, which may have different kind of members (user accounts, other groups, or contacts, which are covered in a later chapter). Group Admin is able to manage groups, and Group Auditor is able to review the current state and settings.

Custom Roles

If the selection of built-in system roles does not serve the technical and business requirements of your organisation, it is possible to create custom roles which may have virtually any set of permission.

Before creating a custom role you should think extremely carefully what the custom role is supposed to do. Custom Roles should always be well-designed and also documented because using Custom Roles alter the built-in security design. It is also possible to create a dysfunctional custom role. The Professional Services division of Trivore offers checking and validation service for custom roles.

Special Roles

Multi-namespace is a special role. It allows for the role holder to switch from a namespace (usually same as a tenant) to another for convenient management of multiple namespaces and the user accounts, groups, and roles in those namespaces. The Multi-namespace role itself does only allow for switching namespace. Other roles are required for actual management. On the user interface, the switching is done by selecting the namespace name on Namespace Menu on the Top Bar. This is a very powerful role, and the holders of this role are always considered trusted persons.

Developer is another special role. It is reserved for application developers. Developers may manage Management API clients and OpenID Connect clients. Those are external applications utilising TIS platform. The API Guide explains the use of external applications in more detail.

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. 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 are hundreds 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.

A role is actually a collection of permissions. Some permissions, like listing user accounts, are required by many roles, so there is a lot of 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 Role for some reason, you need to understand Permissions, as you are essentially assigning Permissions to a Custom Role, and then later via Group to a user Account.

Role assignment (outdated)

Role assignment

There are multiple pre-defined roles and rules on how each role can be assigned to a user account or group. The following table contains this information in one place for System Roles. Custom Roles follow the same schema.

#	Role or permission to be assigned	Current required roles on the assigner	Assignment scope/validity	Required roles on the assignee
1	Group Admin + Auditor	Namespace Admin	Single namespace	None
2	Role Admin + Auditor	Namespace Admin	Single namespace	None
3	Account Admin + Auditor	Namespace Admin	Single namespace	None
4	Authorisation Admin + Auditor	Namespace Admin	Single namespace	None
5	Contact Admin + Auditor	Namespace Admin	Single namespace	None
6	Location/Site Admin + Auditor	Namespace Admin	Single namespace	None
7	Target Admin + Auditor	Namespace Admin	Single namespace	None
8	Incident Admin + Auditor	Namespace Admin	Single namespace	None
9	Single sign-on Admin + Auditor	Namespace Admin	Single namespace	None
10	Namespace Admin	Namespace Admin -or- Portal Admin and Security Admin	Single namespace	None
11	Namespace Auditor	Namespace Admin	Single namespace	None
12	Portal Admin	Portal Admin	System ( platform level)	None
13	Portal Auditor	Portal Admin	System ( platform level)	None
14	Security Admin	Portal Admin, Security Admin	System ( platform level)	Portal Admin
15	Security Auditor	Portal Admin, Security Admin	System ( platform level)	Portal Admin or Auditor
16	Multi-namespace	Portal Admin, Security Admin	Multiple namespaces	None
17	Context Admin + Auditor	Portal Admin, Context Admin	System ( platform level)	None
18	License Admin	Portal Admin, License Admin	System (platform level)	Portal Admin
19	License Auditor	Namespace Admin -or- Portal Admin, License Admin	Single namespace	None

Role assignment matrix.

There are few limitations on role assignment and especially removal. This is to avoid lock-out situations.

There must be at least one user account in the system which has both roles Portal Admin and Security Admin. The last user account with these roles can not be removed and neither of the roles can be removed from that user account. Instead an informative error message is shown.
There must be at least one user account in the system which has role Context Admin. The last user account with this role can not be removed and the role can not be removed from that user account. Instead an informative error message is shown. Last Context Admin must first be moved to another account by first assigning it role Portal Admin, and then Context Admin role.
There must be at least one user account in the system which has role License Admin. The last user account with this role can not be removed and the role can not be removed from that user account. Instead an informative error message is shown. Last License Admin must first be moved to another account by first assigning it role Portal Admin, and then License Admin role.

Assigning namespace for account with role Multi-namespace

It is important to understand:

Namespace assignment is a separate task from Multi-namespace role assignment.
The other namespaces may be assigned to account with role Multi-namespace separately by:
- another account having role Multi-namespace, where the assigner may only assign (and remove for that matter) those namespaces where (s)he is currently assigned to (primary use case), or
- a highly privileged account which has roles Portal Admin and Security Admin for any currently existing namespace (this a very rare use case).

Results from above are:

Accounts with role Multi-namespaces control the managed namespaces in peer-to-peer fashion rather independently, and
the few user accounts with both Portal Admin and Security Admin roles are the supervisors and highest level controllers.

Tip: Familiarise yourself with information in section below.

Role to Permission matrix (outdated)

Role to Permission matrix

The table below discusses the relationship between the roles an account has, and the permissions the account is then given as a result.

#	Roles account is holding	Permissions given to account
1	Multi-namespace, Account Admin	May switch to each assigned namespace. May manage user accounts and assign policies to user accounts. May not assign roles to user accounts (Role Admin required for that).
2	Multi-namespace, Group Admin	May switch to each assigned namespace. May manage groups and assign policies to groups. May not assign roles to groups (Role Admin required for that).
3	Multi-namespace, Role Admin	May switch to each assigned namespace. May manage custom roles in the future. May assign roles to user accounts (if also holding role Account Admin), and roles to groups (if also holding role Group Admin).
4	Multi-namespace, Namespace Admin	May switch to each assigned namespace. May manage namespace level settings. May also manage policies, but not assign them (other roles needed for assignment, see above).
5	Account Admin	May assign policies to user accounts. May not assign roles to user accounts (Role Admin required for that).
6	Group Admin	May assign policies to groups. May not assign roles to groups (Role Admin required for that).
7	Role Admin	May manage custom roles in the future. May assign roles to user accounts (if also holding role Account Admin), and roles to groups (if also holding role Group Admin).
8	Namespace Admin	May manage namespace level settings. May also manage policies, but not assign them (other roles needed for assignment see above).
9	Multi-namespace, Namespace Admin, License Auditor	May switch to each assigned namespace. May manage namespace level settings. May also manage policies, but not assign them (other roles needed for assignment see above). May view licenses for each assigned organisation.
10	Multi-namespace, Namespace Auditor, License Auditor	May switch to each assigned namespace. May view namespace level settings. May also view policies, but not assign them (other roles needed for assignment see above). May view licenses for each assigned namespace.
11	Namespace Admin, License Auditor	May manage namespace level settings. May also manage policies, but not assign them (other roles needed for assignment see above). May view licenses for each assigned namespace.
12	Namespace Auditor, License Auditor	May view namespace level settings. May also view policies, but not assign them (other roles needed for assignment see above). May view licenses for each assigned namespace.
13	Namespace Admin, Account Admin, Group Admin, Role Admin	May manage: namespace level settings, policies, user accounts, groups, and do role assignments.
14	Namespace Admin, Account Auditor, Group Auditor, Role Admin	May manage: namespace level settings, policies. May only view user accounts and groups.
15	Portal Admin, Security Auditor	May act on portal level settings and view settings which are only manageable with role combinarion “Portal Admin, Security Admin”.
16	Portal Admin, Security Admin	This is the highest privilege. May assign all other roles either directly or indirectly.

Role to Permission matrix.

The table above could be expanded with more examples. Send us feedback if we should..

NOTE: Trivore ID Documentation has moved to https://trivoreid.com

The content on this site IS OUT OF DATE!

This space has been archived!

Please go ahead to the new site!