...
TIS has two roles classes: built-in static System Roles and flexible , dynamic 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 picture below describes the relations between Permissions, Roles, Group Policies, Groups and Accounts. This is the current functionality for platform versions before 2.8.
Image Removed
Starting version 2.8 the Group Policy is omitted from the flow, and the following scheme will be used.
Image Removed
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.
For comprehensive picture on how RBAC is implemented in TIS, please see the image below.
Image Removed
Later sections of this chapter elaborate on role-related issues.
Role classes and a the special roles
...
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.
Image Added
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.
| Expand |
|---|
| title | Role assignment (outdated) |
|---|
|
Role assignmentThere 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-namespaceIt is important to understand: 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. |
| Expand |
|---|
| title | Role to Permission matrix (outdated) |
|---|
|
Role to Permission matrixThe 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.
Image Removed
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.
...