mistercrunch opened a new issue, #28002:
URL: https://github.com/apache/superset/issues/28002
### [SIP] Proposal for Enhanced Data Access Permissions
#### Motivation
Superset's current permission model relies on Flask-AppBuilder (FAB) for
both app-level and data
access permissions, dictating what users can do within the app and what data
they can access
(e.g., databases, schemas, tables, rows). This proposal aims to decouple
data access permissions
from FAB, integrating them more directly into Superset's core models
(Database, Schema,
SqlaTables, RLS), thereby simplifying the management of these permissions.
**Note:** Throughout this SIP, "permissible objects" refers to Dashboards,
Datasets, Schemas,
Catalogs, RLS, and Databases.
Key differences between app-level and data access permissions include:
- **Dynamism:** App-level permissions are relatively static, changing slowly
and atomically with
deployments. Data access permissions, however, are highly dynamic and vary
significantly between
environments.
- **Scale:** Many Superset environments manage tens of thousands of
permissible objects.
- **Actions:** The nature of actions differs; app-level permissions include
capabilities like
viewing, exporting, deleting, and updating, whereas data access is
primarily binary (access or
no access).
- **Hierarchy:** Data access permissions are hierarchical, progressing from
Database to Catalog,
then Schema, Dataset, and finally RLS.
#### Current State
Currently, the creation, update, or deletion of permissible objects
necessitates corresponding
changes in FAB's permission model, where both a label and an ID are
captured. This model has
proven brittle and difficult to manage, leading to data sync issues and
posing security risks.
In larger environments, the permissions tables have become unwieldy, lacking
proper indexing, which
complicates both individual access requests and the generation of
user-specific dashboards lists.
#### Proposed Change
This proposal introduces a structured, normalized database model that links
objects directly through
many-to-many relationships with roles and defines the hierarchical
relationships between these
objects. We also propose a new "DataAccessVerbEnum" to clearly define the
permissions associated
with each role:
- Establish many-to-many relationships between FAB's Role and Dataset
(SQLATable), and between Role
and DatabaseConnection.
- Introduce a new Schema model with many-to-many relationships to both FAB's
Role and Dataset, and
a many-to-one relationship to Database.
- Develop a new model for Catalogs, applicable to specific database engines,
featuring many-to-many
relationships with FAB's Role, and many-to-one relationships to both
Schema and Database.
- Introduce `DataAccessVerbEnum` with initial verbs like READ, [eventually]
DENY, and possibly
GRANT (for future use in defining grant permissions).
- Enhance the existing many-to-many relationship with the Dashboard object,
making it standard.
- Include an action field in all many-to-many tables linking roles to
permissible objects.
#### New or Changed Public Interfaces
We plan to expand the SecurityManager interface while maintaining
compatibility with its existing
structure as much as possible.
New CLI methods will be developed to synchronize permissions objects and
identify orphaned entries
when underlying data objects are removed or modified.
#### New Dependencies
[Specify any required new NPM/PyPI packages, their maintenance status, and
licenses.]
#### Migration Plan and Compatibility
We will implement a comprehensive database migration to transition existing
permissions to the new
model.
#### Rejected Alternatives
[Detail any alternative approaches that were considered and why they were
not pursued.]
--
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-unsubscr...@superset.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org
For additional commands, e-mail: notifications-h...@superset.apache.org
