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 (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.
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
- 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.
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.
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.