RBAC Feature Requirement

[schwannden]

The following discussions are extract from emails between me and François. Just thought it would be a good idea to bring the issue to open discussion here:

From schwannden:
For RBAC needs, our company's product platform requires the support for the following 2 policies (using gcp's IAM terminology)

1. predefined policy
2. fine grained policy

Predefined policy corresponds to a set of fine grained policies, while fine grained policy defines what can be done on what resource. The MVP for us would be, to be able to define fine grained policy as string, and define predefined policy as sets of fine grained policy. Then under user schema, we are able to associate multiple policy (either type) to the user.

The following user stories apply:

1. As system admin, I should be able to setup my own fine grained policy.
2. As system admin, I should be able to create predefined policy as a set of fine grained policy.
3. As account manager, I should be able to assign/remove a predefined policy or fine grained policy to a user.
4. As a backend service, I should be able to extract a user's policies, and should be able to get the mapping from predefined policy to fine grained policy.

To further optimize this, it would be great if we have some sort of mechanism to optimize the IAM validation. I.e.

1. some sort of ordering that makes validating faster, for example when we want to know whether a resource.editor policy is greater than resource.viewer requirement, we can simply compare it.
2. some sort of optimization to make predefined rule validation fast, instead of needing to extract the whole set and comparing roles element by element.

[schwannden]

In our design of RBAC, we need fine grained access control for resources in different domain. For example, an accountant can edit all resource B, but can only read resource A, an IT can edit resource A, but can only read resource B. If roles is an array, we would ended up creating a long long list of access role. Suppose we have n kind of resources (A, B, ...etc), and m different operations (post, create, ...etc), then potentially we will be creating mn policies. The access check time could be O(mn)

In terms of policy check efficiency, it probably makes sense to have the 2 concept separated:

1. IAMDomain - specifies scope, like resource A, resource B
2. IAMPolicy - specifies operation, like post, delete, get, put, ...etc

And we will be able to manage user IAM roles by specifying a dictionary of type Dict[IAMDomain, List[IAMPolicy]]. This way would probably greatly help us setup fine grained domain by domain access rule faster, and also makes access control checking more efficient (O(m + n) instead of O(mn)).