In-policy roles & rules supporting complex use-cases

[anvabr]

Problem description

In the course of #2844 Guardian user roles and permission model has undergone a significant revamp. This tickeet addressed management of user permissions/capabilities when it comes to accessing policies. However, within the policies user permissions and roles are determined by the policies themselves. Current in-policy roles&rules definition capabilities have been found to be not sufficient for some of the identified use-cases. This ticket serves as a placeholder to collect such use-cases (in the "Requirements" section below), to inform the developers so appropriate enhancements to roles&rules functionality can be made.

Requirements

Enhance the in-policy roles&rules functionality such that the following use-cases become possible:

1. Setting a limit on the number of users that can fulfil a specific role in the policy. For example, if a policy has the roles of PROJECT_DEVELOPER, VERIFIER and OWNER, we'd like to be able to say that only two people (accounts) at most can "sign up" for the VERIFIER role and only one person (account) can "sign up" for the PROJECT_DEVELOPER role.
2. Manage permissions on the level of accounts+roles, not just roles. For example, consider a scenario where a project developer wants to have their project audited by two independent auditors. Both auditors, although fulfilling the same role in the policy (e.g., "AUDITOR"), should go through the entire "audit" workflow in parallel. Instead of the policy state for the AUDITOR workflow being determined on the level of the role, the policy state for the AUDITOR role should instead be determined on the level of the accounts (users) who fulfil that role, i.e., a policy role state for each user.

Definition of done

• The functionality is enhanced to address the requirements above
• Documentation is updated accordingly
• The corresponding API endpoints exist and documented

Acceptance criteria

Users are able to configure their in-policy user roles and rules of their authorisation and activity such that any (and all) of the use-cases in the Requirements section are covered.

[mattsmithies]

So I can understand the context further why is this needed at the Guardian level, and why not at a application level that decides the users that into a given system?

And more specifically, for particular users:

A traditional project developer (supplier) role with a particular policy enables the same consumption of a token with different projects, why is it needed to limit this group of users?

Currently, this only ends in the issuance of the same token, and can be circumvented through cloning a policy.

I suppose that point two would be useful, and currently the work around would either have 2 options (both managed from an external system):

• 2 Auditors with the same role, but an external system allows the first auditor to reach a certain portion, and when that is completed the second auditor would "assert" the decision with processing another block.
• This could potentially be streamlined by having multiple roles "AUDITOR" and "HEAD_AUDITOR"
• alternatively, if the particular agents so different problems, it may be appropriate to use role like "VALIDATOR" (pdd confirmation), "VERFIER/AUDITOR" for claim checkpoints.

These assumptions are using Guardian through an API where security concerns are solved with IP whitelisting, holistically how much control should the Guardian have?