🤝 Brainstorm Hours: share your ideas on how we should build the Role Based Access Control feature in Baserow!

Feedback
, ,
#1

Hi everyone, I’m excited to announce a new effort that we are going to try here at Baserow: Brainstorm Hours.

What this means is that we’re going to open a few threads (here in the Feedback channel) where we will ask you to participate in the brainstorming session and share your thoughts on how certain features should be built. We want to have direct collaboration between our community and the team.

This is going to be the first time that we’ve tried anything like these collaborative hours, so it will definitely evolve as time goes on. Perhaps most importantly of all, we want to hear from you if you like this kind of activity because we have a few more features in the pipeline where we plan to ask your advice. Comments are open to any kind of feedback :raised_hands:

And now let’s get started! Here is the first challenging feature for you to brainstorm about:

Next week we plan to start working on the so much awaited Role Based Access Control (RBAC).
Role-based access control refers to the idea of assigning permissions to users based on their role within an organization.

Be aware, role based access control will be an enterprise feature only.

We want to have proper planning before starting the development process. And for that, we want to hear your vision on how RBAC should work in Baserow. Share use cases, references, and just some ideas — we will collect and analyze every input from your side, and take into account all your comments and wishes.

Start sharing your ideas in the comments and go as bold as possible with the desired functionality :sweat_smile:

3 Likes
#2
#3
#4
#5

Some of the key use cases for me are:

I want to be able to with RBAC:

  1. Grant a particular user admin/cell edit/field edit/view/create/delete/comment rights only on some tables or databases.
  2. A user who doesn’t have view rights on a table can’t see it anywhere in Baserow, nor access it using the API directly.
  3. Assign rights to “roles” and grant those “roles” to users. A role is just a collection of permissions.
  4. Go to a table and see easily who/which roles has rights on that table
  5. Sync roles with ActiveDirectory and other external permission sources
  6. Set a default role new invites to the workspace get
  7. Select what role a user will get when inviting them to a workspace
  8. Specifically have permissions and control over which users can:
    1. Changing if a view can be shared publicly or not
    2. Creating/Deleting/Moving/Renaming a table/workspace/database
    3. Upload files
    4. Export/import perhaps
    5. Taking snapshots
    6. Commenting
  9. To be able to grant all of these permissions to API tokens themselves, and roles
  10. There should a quick button to click and invite someone (via email or a link) to view/edit/own a table. It’s fine if they are forced to signup first. I’d like to be able to control that link, disable it etc.

And questions I have are:

  1. Should there be a level of access which is “can only edit cells, but can’t delete/create rows, can’t modify fields”
  2. Should we provide “view” level permissions. For example can I grant view rights to a user/role for only one view? Meaning they can only do XYZ on rows shown in that particular view.
  3. Should we provide database and workspace level permissions like: edit all tables in workspace etc.
  4. Can I grant per row access levels? Perhaps in combination with a collaborator field? E.g., any collaborator listed in this cell can edit this row (excluding the collab field).
  5. How are permissions for restoring trashed items managed?
  6. Should I be able to make a public database anyone can join and edit?
2 Likes
#6

Thanks @nigel for the input :blue_heart:

@mahmouds12, @christian_ruiz, @mwesox, @bbuss you showed some interest in the role based access control feature in the past. Feel free to share your opinion on how it should work in Baserow by adding references or commenting on @nigel ideas :raised_hands:

#7

More technical thoughts:

  1. IMO You should be able to grant permissions to API Tokens, Users and Roles. This implies there should be some sort of PermissionHolder concept perhaps modelled by a table. A user or token or role can hold permissions. In the future we might want to attach permissions to some other resources and this abstraction will let us easily do that.
  2. We should very very strongly keep in mind how all of this will integrate with ActiveDirectory, LDAP etc. At the end of both this and SSO it should be possible to integrate Baserow with these technologies at both a login and permissions level.
  3. IMO We shouldn’t end up with different interfaces, one for api tokens and one for the new RBAC. They should be the same thing.
  4. Whilst working through all the endpoints enabling them with RBAC we should also add API Token support to them all. And importantly I don’t think we should not block the API Token work behind having to do the GUI work adding them to the user generated docs. IMO it is much better to support API tokens everywhere and only show some of the endpoints in the user generated docs than not having API token support everywhere but all endpoints that are supported being in the generated docs. Adding new endpoints to the user generated docs is slow and if we want to do it for all endpoints will take months of developer effort. Instead I think we should figure out an easy way of making the user generated docs just some markdown files and/or automatically generated from the redoc, instead of hand coding components for every new endpoint. Or just not having the generated user docs show something for every endpoint.
  5. We should very clearly define where permissions are checked. Actions? Handlers? Views? Jobs? Ideally we could consolidate all of this into one of these layers. If we did as jrmi suggested if Actions start Jobs we could then put all permission checking in the Action layer (to perform an action on Baserow first we check if you have permissions).