Revamp Guardian user/roles and permissions model

[anvabr]

Problem description

Current user/roles model in Guardian is somewhat simplistic, and often does not map perfectly on business operations. For example policy authors is a very different level of responsibility to policy reviewer/approver, and even more so to token issuance account/role. Currently all these responsibilities are mapped to the same Standard Registry role.

Requirements

• Fundamentally separate the concept of users, roles and permissions in Guardian
• Introduce granular concept of permissions which could be assigned to users, a user could then perform a specific function within the role if its assigned role 'contains' this permission. These should include (but not limited to):
  • Policy edit/submit for review
  • Policy view
  • Policy approval & publish
  • ...
• Introduce a "user admin" role, which allows:
  • defining new roles from permissions
  • assigning of roles to users
• Create a permissioning system which verifies actor role before any action has been taken throughout Guardian
• Package in suitable most-common role set into Guardian so it can be operated immediately 'out of the box' without the need for additional configuration
• Create a concept of 'delegation' where a user with a particular role/permission can explicitly 'delegate' this role/permission to another user
• Introduce the functionality to produce a report (page, download) which lists all users and their roles/permissions mapping in the system

Definition of done

• Roles/permissions functionality is created as specified above
• The new functionality is documented

Acceptance criteria

• Users are able to fine-tune the user/permissions/roles settings on their system at a granular level
• Guardian comes with an out-of-the box set of roles/permissions which allow immediate usage of the system in the most common generic use-cases
• It should be possible, for example, for an organisation to set up an SR and then invite multiple users to that SR account, which then will work in the same workspace on different policies but in the same instance
  • the same for project developers
  • the same for VVBs

[dubgeis]

@Neurone please add your thoughts cc: @sergmetelin @justin-atwell @prernaadev01 @anvabr regarding CURD operations

[dubgeis]

@anvabr Can we update to include the new user management via VCs enabled by the DID spec? cc @Neurone

[dubgeis]

This should be done via VCs and VCs should be revokable, which would be the key behavior we need to enable.

[anvabr]

Implementation plan and design (please review @dubgeis @Neurone @sergmetelin @justin-atwell):

Changes in the existing top-level roles (backward-compatible):

• SR (Admin) - no changes
• User (Consumer) - no changes

New roles:

Worker - a user who, like the User (Consumer) exists in the context of SR, which is given rights to perform certain actions from the arsenal of capabilities of its SR. This user has no pages until it's given permissions by its SR (Admin).

Changes in the UI:

• Login page - new 'Worker' role.
• SR (Admin) pages - none for existing pages.
• User (Consumer) pages - none.

New pages for SR (Admin)

• New pages to manage Roles. Roles are named groups of permissions.
• New pages to manage Workers' Roles (permissions).
• New pages allowing the change a treasury account (DID) which pays for system Policy messages (e.g. )

New pages for Workers

• Copies of all SR (Admin) pages but with reduced functionality (depending on the permissions)
• A page or set of pages which allow to temporarily delegate its role/account/DID to another Guardian user which would be able perform actions on the worker's behalf

Changes on the Back-End:

• Add dynamic roles
• Add temporary roles (to enable delegations)
• Change API access to make it roles/permissions-based
• New collection of messages and VC documents to do with Workers' permissions (granted/revoked)

Notes

• All SR documents (of all users in its 'context') are separated from another SR documents as it is now
• Hedera topic structure stay the same, all messages from Workers are posted into the corresponding SR topics
• All changes in the UI are limited to the static Guardian pages, policy-generated pages remains unchanged.

[anvabr]

List of permissions, grouped by type. The standard CRUD model is supported across most of the items. Other 'non-standard' permissions need to be processed and grouped into some generic one which can mean different things for different items.

Guardian Permissions.xlsx