Heads up!
In the future System and Custom Roles will be merged to just Roles. New schema is shown at the end of this page.
Trivore Identity Service (TIS) utilises role-based access control. In practise it means what selections you see in the Main Menu, depends on assigned roles at any particular time. There are about 30 different pre-defined roles. Each user account may have several roles. What one can do in TIS is determined by the assigned Roles (and the Permissions tied to those Roles).
TIS has two roles classes: built-in System Roles and flexible Custom Roles. 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 picture below describes the relations between Permissions, Roles, Group Policies, Groups and Accounts. This is the current functionality for platform versions before 2.8.
Starting version 2.8 the Group Policy is omitted from the flow, and the following scheme will be used.
Image below shows the different paths from Permissions to Accounts.
For comprehensive picture on how RBAC is implemented in TIS, please see the image below.
Later sections of this chapter elaborate on role-related issues.
Role classes and a 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. In fact the permission related to Multi-namespace role is Switch-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 onePortal™ API Guide, (Doc ID 1001-188P) explains it 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
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
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..
New schema coming for version 3.0
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 flexibility is reduced after collecting and analysing customer feedback. You know, sometimes there can be too much flexibility, as it may reduce usability and learnability.