You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by GitBox <gi...@apache.org> on 2021/09/02 10:20:19 UTC
[GitHub] [superset] amitmiran137 commented on issue #16557: [SIP-72] dataset RBAC
amitmiran137 commented on issue #16557:
URL: https://github.com/apache/superset/issues/16557#issuecomment-911502003
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
--
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: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org