- Team name: The old farts
- Team members: Kevin, Cedric, Remy (founders)
This project highlights the Role Based Access Control (RBAC) feature that allows the administrator to have granular control over what a regular user can and cannot do such as hiding certain features or workspace. The RBAC is essential for promoting security and reducing unauthorised access. It covers UI and API levels and includes a new screen for administrators to control the visibility of export features, the view password buttons in the grid/sidebar/quick access, the in-form menu, and the user workspace at first.
Q1. What is the problem that we are trying to solve?
Currently there is no option for an administrator to define what a regular user can do or not. For example it is not possible from the administrator workspace to hide the import or export buttons, or hide the entire user workspace for regular users, etc…
Q2 - Who is impacted?
Administrators that want to have granular control over role based access.
Q3 - Why is it important and/or urgent?
It is requested under multiple threads on the community forum.
- Disable export of passwords for user
- As an admin I do not want my users to see all users on the platform
- Users have access to view passwords
- As a user I should be able to disable the in-form menu in the settings
Additionally, RBAC is a must-have in any platform that promotes security, since it ensures that users only have access to the resources and information necessary for their roles. This reduces the risk of unauthorized access to sensitive data or systems.
Q4 - What is your proposed solution?
We propose to introduce a new role based access control system that will allow an administrator to control actions provided by the application, whatever these actions can be operated on the clients or the API. This system will cover for example the following two use cases:
- UI level: how the clients should behave, which features they should show or hide from the end users.
- API level: which API endpoint can be called for which role.
We propose to introduce a new screen for the administrators to control the visibility of the export feature, the view password buttons in the grid/sidebar/quick access, the in-form menu, and the user workspace at first.
Additional scope definition
Dynamic rules
Rather than sticking to Yes or No options, we propose to offer a more comprehensive and extensible solution where logical policies can be defined. Of course “Yes” and “No” will be included as supported policies for right resolution, but we will support others rules, for example for the right to delete comments, the current policy is “Yes if the user owns the comment” for the user role and “Yes for all comments” for the admin. We could imagine other rules, such as for example: “Yes if the user is also a group manager” or even more complex one “Yes if X or Y is met”, e.g. rules that could be composed from other rules and that could be used in other contexts. These dynamic rules will allow the community to define new strategies that are not just linked to the role, but also the surrounding context.
Excluded scope
The first part will not allow defining which API endpoints can be called for which role. For example to prevent users from creating folders at the API level.
In part 2 we’ll migrate the API endpoints to use the new RBAC system to resolve whether the given user role is allowed to perform the operation. We’ll first implement the original configuration, e.g. encode the current policies in the new RBAC system, then allow administrators to customize it for the user role.
Moreover in this first version it will not be possible to create other roles than the defaults, e.g. user and admin. This feature will not allow changing the default roles for administrators (they will still be able to do everything).
Here’s the documentation: RBAC - Functional and Technical - PUBLIC
Share your thoughts and ideas below:
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)