Page Comparison

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.

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.