villebro opened a new issue, #28021: URL: https://github.com/apache/superset/issues/28021
### Motivation For the main entities, like charts and dashboards, Superset employs an implicit access control model, where access is granted if the user has access to the underlying datasource. While this makes sense from a data access perspective (=you shouldn't be able to view a chart if you can't access the underlying table), it has the following drawbacks: - Users that have access to lots of datasources face a lot of clutter in the form of seeing all charts and dashboards (I'm ignoring the publishing flag on dashboards here for simplicity) - It's impossible to publish a dashboard to user A only if user B has access to the same datasource. This is especially problematic in a context where multiple orgs have access to the same database, but analyze the data from different perspectives. Think sales vs internal audit, where it can be very problematic if salespeople see how internal audit is tracking their activity. In addition, other than via Roles, Superset doesn't have a concept of groups that multiple users can belong to. This makes it difficult to manage collective ownership of assets, as each asset has to be explicitly owned by users. While [SIP 51](https://github.com/apache/superset/issues/10408) proposed a solution for this, it utilized the Role model for non-permission based access controls, which is a deviation from what FAB Roles are originally intended for. This user-centric access control model becomes particularly challenging in large organizations, where users routinely flow in and out of teams, or become absent, like when a user resigns. In these cases an admin usually has to step in and manually re-assign ownership of an asset to another team member. For this reason, it would be practical to be able to assign ownership of assets to a group or groups, rather to one or many users. ### Proposed Change To introduce granular access controls to Superset entities, and clarify access controls, we propose the following changes: #### 1. Introduce concept of Editors and Viewers These new properties will replace the current "Owner" property and implicit access model as follows: - Editor: similar to Owners, Editors are able to change the objects. - Viewer: Viewers are able to view, but not change entities. The properties are added to the following models: - Dashboard - Chart - Alerts & Reports - Row Level Security For Alerts & Reports and RLS we only introduce Editor for now. The list views are updated to only show entities that the user has access to, either via Editors or Viewers. #### 2. Add a Group model The Group, similar to the Role model, will make it possible to group multiple users together. This can be used to create arbitrary groups, e.g. "Finance", "Marketing", "USA", "Finland" etc. Typically, membership to these would be synced from some upstream source, like LDAP, and id token or similar. #### 3. Add a Subject model The Editor and Viewer properties would reference a new Subject model, which in turn would reference one of three models: - User - Group - Role The Editor/Viewer dropdowns would thus make it possible to assign editorship/viewership not only to Users, but also Groups or Roles. By default, only Users and Groups would be displayed in the dropdowns, but for backward compatibility with `DASHBOARD_RBAC`, it would be possible to also reference Roles as a subject. Exposing Roles would be done via a query filter (disabled by default). ### New or Changed Public Interfaces - The `Subject` model is introduced, that has an entry for each `User`, `Group` and `Role` - The affected models (dashboard, chart etc) introduce new reference fields for `editors` and `viewers` that are linked to the `Subject` model via link tables. - A new React component is introduced that references the `Subject` model, which makes it possible to choose Subjects for the Editor and Viewer properties. ### Migration Plan and Compatibility 1. A database migration would introduce the new Subject, Group and link tables that connect the entity tables to the Subject table. 2. A cli command would be introduced that migrates existing Owners to the new Editors property 3. A SQLAlchemy event listener would keep the Subject model in sync with the User, Grooup and Role tables whenever changes are made to those entities. ### Rejected Alternatives We considered enabling the `DASHBOARD_RBAC` flag. However, this didn't solve the ownership issue. Also, the Role model is not designed for non-permission based groups. Therefore, it felt more intuitive to introduce a new model that can be directly linked with existing enterprise ACL solutions, like LDAP. ### Screenshots It would be possible to assign subjects (Users , Roles or Groups) to both the Viewers and Editors property. Notice, how both users and groups can be referenced: <img width="886" alt="image" src="https://github.com/apache/superset/assets/33317356/57598813-0289-4d33-b7fb-8cedaec649f8";> On the list view, you would only be able to see the entities that you have access to, either via the Editor or Viewer property: <img width="1380" alt="image" src="https://github.com/apache/superset/assets/33317356/a8fd7ecf-07f7-4d9e-92e4-f2e53a0e2261";> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
