Content Comparison

...

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.

1. Custom roles through groups
2. Custom roles through namespace default account policy (special case, gives roles to all accounts within a namespace)
3. Direct Custom roles (deprecated)
4. Direct system roles (deprecated)
5. Direct permissions (deprecated)

...

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.

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

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.

...

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 explains the use of external applications in more detail.

Roles and Permissions

...

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 Removed

There are just Roles, and you can freely manage them in your namespace.

...

Account

...

.

...