mistercrunch commented on issue #28021:
URL: https://github.com/apache/superset/issues/28021#issuecomment-2059996571
Wondering if it's easier to alter this SIP or start over from scratch to
make sure everything is captured. Let me give it a quick shot with GPT here:
-----
# SIP-127: Federated Model for RBAC/ABAC/ACL in Apache Superset
## Motivation
Current implementations of RBAC/ABAC in Apache Superset are managed through
various models and permissions systems, primarily leveraging Flask-AppBuilder
(FAB) for app-level permissions. This split approach introduces complexity in
managing data access permissions and results in user interface clutter,
inefficient permissions synchronization, and scaling issues. A unified,
centralized policy manager is proposed to address these challenges by
consolidating all aspects of RBAC, ABAC, and ACL within Superset.
## Goals
- Federate all access control mechanisms under a single, centralized policy
manager within Superset.
- Replace the rule-checking mechanisms currently utilizing FAB with a
native, more scalable and flexible Superset system.
- Ensure forward compatibility and extensibility for a wide range of
entities and actions.
## Proposed Changes
### 1. **Central Policy Manager**
- Implement a centralized authority within Superset for all access
controls, replacing the current systems that depend on FAB.
- Define and manage permissions using a structured, normalized model for
granular control from databases to rows.
### 2. **Hierarchy-Aware Access Control**
- The policy manager will inherently understand and utilize the
hierarchical nature of data access:
- **Atomic Entities**: Each entity like Dashboard, Database, Schema,
Dataset, and RLS will be considered an atomic unit.
- **Hierarchies**: Entities will be organized in a hierarchy, with
explicit parent-child relationships where access permissions can inherit or
override based on the hierarchy.
- **Verbs/Actions**: Define specific actions (CRUD for app models and
binary for data access) applicable at each level of the hierarchy.
- **Set-Definitions/Pattern-matching**: Create sets or groups of
entities, either as named groups or based on pattern/attribute matching
- **User groups**: Bring user groups as a core concept. Roles are
collections of groups and/or individual users
### 3. **Integration with Existing Frameworks**
- Evaluate and integrate with frameworks like Casbin and OPA for backend
policy management.
### 4. **Migration from FAB**
- Transition from FAB-based controls to the new centralized policy
manager while ensuring backward compatibility.
### 5. **User Interface Enhancements**
- Develop a new UI to support the centralized, hierarchy-aware policy
manager.
### 6. **Implementation Details**
- Detail the required database schema changes.
- Develop API endpoints and internal methods for the policy manager.
- Implement synchronization mechanisms to maintain data integrity across
user and group changes.
## Migration Plan and Compatibility
- Comprehensive database migration strategies will be implemented to shift
existing permissions to the new model.
- CLI tools will be provided to help admins migrate permissions and verify
the integrity of the new system.
## Rejected Alternatives
- **Continued use of FAB for data access controls**: Rejected due to lack of
scalability and complexity.
- **Separate models for each entity type and permission**: Considered too
fragmented and challenging to manage.
## Request for Comments
- Integration of the groups model: Should it remain in FAB or be integrated
into Superset?
- Should we use a single secondary table with an entity field for different
objects, or separate tables per object?
- Use of UUIDs for easier rule migration and management.
- Considerations for direct vs. inherited access in the hierarchy.
- The feasibility of adding more sophisticated permissions management, such
as conditional access based on attributes.
This SIP aims to significantly overhaul how permissions are managed in
Apache Superset, simplifying the user experience, enhancing security, and
providing a framework that can scale effectively in large and dynamic
environments.
--
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]
