[SIP-72] dataset RBAC

[SIP-72] Proposal for dataset RBAC

Motivation

When bringing either department level databases or Trino into Superset, it’s hard to share the database itself to any role contains user out of that department (e.g., 100+ users want to use a dataset via superset, but they can not get database access at all). which means it will push any dataset owner to share dashboard (Thanks to DASHBOARD_RBAC) only without exposing underneath dataset or chart.

Proposed Change

improve this UI/workflow by adding the dataset access control directly on the dataset edit modal, so that the owner of this dataset can decide who can access this dataset.

Creates a new feature flag DATASET_RBAC similar to the feature flag DASHBOARD_RBAC, it will enable a dataset creator/owner to grant read-only access to roles via dataset properties dialog.

It will use the existing FAB RBAC model so such access grant could be overridden by those who has edit role access.

When a dataset is granted to role Gamma, any user belongs to this role will be able to see this dataset from the dataset list view.

New or Changed Public Interfaces

It will add a new dropdown box named ACCESS to the SETTINGS tab of the dialog Edit dataset dialog, where it allows dataset owner to select roles who have read-only access to this dataset.

New dependencies

None.

Migration Plan and Compatibility

When using FAB RBAC model, it doesn’t need new models. it supports backward compatibility via the feature flag DATASET_RBAC.

Rejected Alternatives

1. It can ask user to request for database access within superset, so that they can get access to all datasets out of this database. but usually it’s not feasible since database level access means a user can explore any table/schema of this database under stored database access.
2. Ask database admin to create user access individually or enable impersonation rules like that in Trino. This is not feasible if existing database doesn’t support such process, or a superset user needs to create their own database connection in superset, which brings even more work to a superset admin who needs to create roles to grant database access individually.

[junlincc]

@shawnzhu would you like to send an email to dev, to drive more discussion and move this forward?

[amitmiran137]

I just want to this to the broader discussion of Access

Prerequisite - Generic Data Access Control

To achieve the sip goals, prevent and reduce conceptual and design complexity, a generic data access objects mechanism is required. There is no need reusing the code for dashboards access mechanism, or decuple security mechanism to concrete data objects. Those mechanism includes three parts:

1. Create data access objects - permissions objects
2. Granting permissions objects to others
3. Permission validations

Currently superset achieve it by depending on FAB View/Api security models and mechanisms of access control. The big dilemma is the data access control should be separated from FAB View/Api access control. Our suggested solution suggests that from the designer perspective, both are the same. Thus by modifying some definitions and defining new ones, The FAB access control can be transformed to be a “Resource Access control” and control access for all the cases without complicating it. Resource Access control can be integrated directly into Fab or alternatively alter and customise it under the superset layer.

Definitions

Resource - View is resource, API endpoint is resource too so any kind of data objects can be seen as resource too as well (This is REST by definition). Data objects - Dashboard, Chart, Dataset, Database and etc’ - can be seen as specialization of resources. Operation - specific operation on resources like a read, write, delete and so on. Operator - Role , Owner and etc’ - entities who operate on resources. Permission - a right to operate specific operation on resource Access control rule - the operations on a resource, an Operator can do Security permission objects - the objects represent resources, permissions and permission owning as rules

Model Specifications

1. There are several operations on each resource as (read/access, edit/update. delete/remove, grantor, export and etc )
2. Resources can be drilled down (dashboard can be drill down to specific dashboard)
3. There are “Operators” who can have permission to do several (or all) operations on same resource
4. There are “Operators” who can have the same permission for all the drilled down resources example - I have permission to all dashboards or simply represent it by “dashboard” or specific resource.
5. There are group of operators who have common permissions (Role)
6. There are use cases which a grantor operator would like to grant permission to other operators
7. There are use cases that require some several permissions for several different resources - example fetching a specific dashboard - there is need an access permission for “GET DASHBOARD” endpoint resource, read permission for the specific dashboard.

As can be deduced, the terms changed a bit, so for easy adapting the new terms, the same diagram with the old terms is

table diagram for proposed solution