WIP

OVERVIEW

Add three new System-scoped roles to the product: Junior Admin, User Manager and Console Viewer.

GOALS

1. -

2. -

3. -

SCOPE

In:

• gate System Console sections and subsections access

• gate config.json settings management

• gate API methods.

Out:

• defining define custom roles

• support plugins permissions

SPECIFICATIONS

Requirements

...

TERMINOLOGY

resources - they can be System Console sections/subsections, config.json settings, API methods.

SPECIFICATIONS

Requirements

• the goal is to add three new roles: User Manager, Console Viewer and Junior Admin (see https://www.notion.so/New-System-Roles-Special-Admins-be514029606545e3be3aa3e8c8ba507e
  for current requirements). These new roles will be defined at System scope. They will have access to the System Console - like the System Admin

• these new roles will possess specific rights on the following resources:

  • System Console sections and subsections.

  • config.json settings (through the API config.go get and set endpoints).

  • various API methods that support functionalities exposed in the System Console (e.g. display analytics, link, sync groups) - separate from config settings.

...

PERMISSION_READ_SETTINGS
PERMISSION_WRITE_SETTINGS
PERMISSION_CREATE_USER_ACCESS_TOKEN
PERMISSION_READ_USER_ACCESS_TOKEN
PERMISSION_REVOKE_USER_ACCESS_TOKEN
PERMISSION_EDIT_OTHER_USERS
PERMISSION_GET_PUBLIC_LINK
PERMISSION_LIST_USERS_WITHOUT_TEAM
PERMISSION_MANAGE_JOBS
PERMISSION_MANAGE_OAUTH
PERMISSION_LIST_PUBLIC_TEAMS
PERMISSION_LIST_PRIVATE_TEAMS
PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT
PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT
PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT_USERS
PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT_USERS
PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT_GROUPS
PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT_GROUPS
PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT_TEAMS
PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT_TEAMS
PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT_CHANNELS
PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT_CHANNELS
PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT_PERMISSIONS
PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT_PERMISSIONS
PERMISSION_READ_SYSCONSOLE_AUTHENTICATION

Note: For User Manager role above, for the “User Management” section we could have had only the PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT and PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT permissions. The reason we have more permissions assigned mapped to subsections , is that in the future we project to have variants of this role that will have some of their subsections WRITE permissions removed.

...

Since the newly-added permissions are by definition linked to the System Console sections, we need to map them to the config.json settings. To do that, we have reviewed the existing System Console settings and mapped them to the corresponding config.json fields:

...

First, the user needs to be in a role that gives them access to the System Console from the chat-facing side (READ_SETTINGS). Then, depending on the role, the user could can have read-only access to the sections (no WRITE_SETTINGS permission).The rules are as follows) or can have WRITE_SETTINGS but with some exceptions (basically breaking the permissions inheritance from the parent section).

The rules are as follows:

1. if the current user's system role does not have READ or WRITE permission on the resource, the section is hidden for the user. Example: User Manager does not have PERMISSION_READ_SYSCONSOLE_PLUGINS or PERMISSION_WRITE_SYSCONSOLE_PLUGINS so the Plugins section is hidden from view for a user in a User Manager role

2. if the current user's system role only has READ permission on the resource, the resource (section) is disabled. Example: User Manager has PERMISSION_READ_SYSCONSOLE_AUTHENTICATION so the Authentication section is disabled for a user.

3. if the current user's system role has a WRITE permission on a subsection, then no matter if he has READ or WRITE permission on the parent section, the resulting permission on the subsection is WRITE, basically, the WRITE on the subsection broke the permissions inheritance from the parent section.
   Example: User Manager has PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT_USERS on the Users sub-section but also PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT on the entire section, the resulting permission is WRITE on the sub-section.

...

1. if the current user's system role has a READ permission on a subsection, then no matter if he has READ or WRITE permission on the parent section, the resulting permission on the subsection is READ, basically, the READ on the subsection broke the permissions inheritance from the parent section (if not, by default, the subsection would’ve had the permission of the parent section).

Access to a setting in the config.json

Similar to the System Console, a user will need to be in a role that has the global READ_SETTINGS permission to fetch a setting and WRITE_SETTINGS to patch/update a setting. Beyond that, if the user only has READ access to a section setting, we are restricting update access to that setting. For example, since if User Manager has only would have PERMISSION_READ_SYSCONSOLE_AUTHENTICATION only, the user in this role will not be able to update the config.json fields mapped to the Authentication settings (see table above).

...

Most API calls that were previously gated by the MANAGE_SYSTEM permission are now gated by the READ_* permissions for the get() calls and WRITE_* permission for the create, patch and update calls.
If we need to have more granular access to an API method that corresponds to the functionality of a sub-section in the System Console (like in the User Manager case), we will gate those calls on a case by case (a single panel functionality in the System Console panel section/subsection can map to one or more API methods calls), using the system and non-system-scoped permission already assigned to the SystemAdmin for these operations.

Permissions

See changes detailed above

Schema

No schema changes

REST API

The following API methods will have their gating functionality changes, as follows:

Performance

No performance degradation expected.

Plugins

CREDITS

Thanks to