WIP
OVERVIEW
...
The new roles can have level of access to these sections (and some of their subsections) :
none, read, write, where their semantics is:
none - the section is not displayed to the User
read - the section is displayed but all of its components are disabled. For example, web links and sub-sections specifically exempted that have WRITE permissions on are not disabled. In some cases the page needed to access the main functionality is not disabled but the landing page components are - example: Edit Scheme is enabled, but the permission tree it leads to shown in the next page is disabled.
write - the section is (and its subsections) are fully accessible
Junior Admin
About - none
Reporting - read + write
User Management
Users - read+write (with the exception of not being able to reset other admin passwords and to edit new admin role permissions)
Environment - read + write
Site Configuration - read + write
Authentication - read+write
Plugins - read+write
Integrations read+write
Compliance - none
Experimental - none
...
About - none
Reporting - none
User Management - read+write
Users - read+write (with the exception of disabling the capability of resetting not being able to reset other admin 's passwords)
Groups - read+write
Team - read
Channel - read
Permissions - read
Site Configuration - none
Authentication - read
Plugins - none
Integrations - none
Compliance - none
Experimental - none
...
The config.json settings file roughly map to the same sections/sub-sections, but is a superset of the settings exposed in the System Console.
API methods
There are roughly two categories of API calls : get or create/patch/update. the get calls are gated by the READ permissions and the create/patch/update are gated by the WRITE permissions.
Permissions
To implement the requirements detailed above we will be define the following new permission sets:
...
Currently access to the System Console, managing the settings and invoking the functionality in the System Console, managing the settings in the config.json and gating the API calls - all these actions are being gated using the MANAGE_SYSTEM permission assigned only to the SystemAdmin role (with some exceptions). Since we need to give acess access to the System Console to the new roles and we also need read-only access to the System Console. Given these, we decided to create a new set of permissions that give a more granular access to the System Console and config.json.
| Code Block |
|---|
READ_SETTINGS, WRITE_SETTINGS |
Note: MANAGE_SYSTEM` is a System/GlobalAdmin role permission only. It is used to allow the SysAdmins to perform actions that are available only to them - for example, to
System Console per-section/sub-section permissions
...
There is a set of permissions that are used to gate specific tasks in the API and not covered by the MANAGE_SYSTEM permission, like PERMISSION_MANAGE_JOBS, PERMISSION_LIST_PRIVATE_TEAMS PERMISSION_JOIN_PRIVATE_TEAMS, PERMISSION_MANAGE_TEAM, etc.. These will be assigned to the new roles, depending on their specific requirements
Note that not all of them are system level permissions.
...
Finally, all these permission will be assigned to the existing roles and new roles as follows:
System Admin - add all the new section-specific roles (3.2 see above) to the existing set of permissions.
...
Note that, the assumption is that in order to have full access to a resource (section or sub-section) - that is, WRITE permission, the user implicitly needs READ permission, so we would not to assign the READ permission to a role, if the WRITE permission is already assigned (basically WRITE covers READ). That would work in the System Console, however for API calls, the get and set calls are split, so we need to have both READ and WRITE permissions on a role.
Config.json mappings to permissions
Since the newly-added permissions are set on the System Console sections, we need to map them to the config.json settings. In order to do that we have reviewed the existing System Console settings and mapped them to the corresponding config.json fields:
...
Note: there are settings present in the config.json that are not settable through the System Console. These settings are not captured by the sectionToPermission table and therefore are only gated at the higher level by the READ/WRITE_SETTINGS permission
Resource permission computation algorithms
...
Note, by design we will not define a case in which a role has WRITE access on a section and READ on a sub-section (the opposite can happen, see above).
...
Similar to the System Console, a user will need to be in a role that has the global READ_SETTINGS to fetch the settings 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 User Manager has only PERMISSION_READ_SYSCONSOLE_AUTHENTICATION, the user in this system role will not be able to update the config.json fields mapped to the settings.
...
Each API call that was previously gated by the MANAGE_SYSTEM permission is now gated by the READ_* permission for the get() calls and WRITE_* permission for the create/patch/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 (one panel functionality in the System Console panel can map to more than one API call).
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