Implementing RBAC on web.

[peterMuriuki]

Goals:

• [ ] Hide modules that logged in user should not have access to.
  • Partly implemented
• [ ] Hide components in modules that would result in sideEffects that the user is not authorized to perform. e.g user can see list of users but is not allowed to delete them.

Not in Scope:

• ABAC Attribute based Access control - implemented on server side using practitioner details

Considerations:

• we need not rely on keycloak as the authN layer.
• Modules on the web usually work with a single resource enpoint but sometimes a module can make use of several other resources that might have their own permission wants.
• Conditionally rendering components/JSX in views based on permissions can lead to wierd code. Adds extra context that a dev needs to think about everytime they are adding features to existing or new views. There is a real risk that a dev can totally miss to add permission checks when adding new views.
  • Conditional rendering patterns that make a bit sense for this usecase:
    • HOCs
    • hooks

[peterMuriuki]

Implementation plan.

High level

External packages involved

• gatekeeper
• session Reducer

Process

• Gatekeeper kicks off authN, this gets the user information and IAM-centric roles information.
• Define an internal syntax to represent permissions on web.
• Add an adapter (configurable via envs) that specifies how to translate IAM-centric roles into the permission system mentioned above.
• Enhance session reducer to also be able to store the derived permissions of the logged in user in the redux store.
• Create a Watchman HOC component that can conditionally render nested children components if the logged in user has the required permissions.

Details

How permissions will be defined internally.

• Granular, single permission for each CRUD action, composable (ability to create composite permissions), easily verifiable that a composite permission contains a child permission.
  • For the CRUD operations, we can assign each operation a unique bit position in a 4-bit binary representation, with the value 1 indicating that the permission is granted and the value 0 indicating that it is not.
  • We can create an object that holds a reference to a resource type and the CRUD permissions that apply to that resource, the resources representation will be similar to that of CRUD operations in the bullet point above, the only difference is that we'll probably need a bit binary representation that is n long, where n = number of resource types.

The Watchman HOC.

• Watchman HOC will have access to the store context, and takes at least one prop that denotes what permissions are needed for the nested component tree to render.
  • <Watchman has={canViewUsers}><UserList>...</UserList></Watchman>

[peterMuriuki]

Notes:

• User management resources also need to be included, but are served from keycloak.
  • This then raises the question: If we are to use something other than keycloak for IAM, how would user management be affected, it would definitely break the module views, since the knowledge that we use keycloak as an IAM is assumed in the code

[peterMuriuki]

What part do scopes play in rbac?

[pld]

What part do scopes play in rbac?

@ndegwamartin do you have info on this?