[SIP-131] Superset Security Model Redesign about superset HOT 5 OPEN

The proposal for the Superset Security Model redesign focuses on creating a more intuitive, scalable, and manageable security framework. Key components include:

1. Introduction of a Structured Permission System: This aims to simplify the management of permissions, making them more aligned with user expectations and the actual architecture of Superset.

2. Implementation of a DSL for ABAC: A domain-specific language for attribute-based access control is proposed to allow for more granular and flexible access control policies, enhancing security measures like row-level security (RLS) and guest access.

3. Reducing Dependency on Flask App Builder (FAB): The redesign seeks to manage permissions, roles, and access checks within Superset more directly, moving away from reliance on FAB's models and methods.

4. Optimization of Permission Checks: By implementing efficient methods for permission checks, the proposal aims to improve performance and manageability of access control to various resources within Superset.

5. Adoption of a Hierarchical Naming Convention for Actions: This will help streamline the management of permissions and roles, making the system more intuitive and easier to navigate.

6. Establishment of a Governance Strategy: A strategy for creating, managing, and syncing roles and permissions is proposed to ensure that access control is both robust and flexible.

7. Development of a PolicyManager and UI: To facilitate the efficient management of policies and roles, including tools for creating, editing, and assigning roles and permissions, as well as visualizing access control policies.

8. Enhanced Security for Embedded and Guest Users: The proposal includes measures to ensure that embedded dashboards and guest users have restricted access based on predefined policies, improving overall security.

This summary encapsulates the main goals and strategies of the proposed Superset Security Model redesign, focusing on improving the system's intuitiveness, scalability, performance, and manageability.

To continue the conversation, mention @dosu.

from superset.

For the DSL and ABAC selectors in the context of Apache Superset's security model redesign, it's beneficial to look into Superset's existing Row Level Security (RLS) feature. This feature already incorporates elements of a domain-specific language (DSL) for attribute-based access control (ABAC), demonstrating the application of complex permission scenarios through conditions like equality, sets, logical operators, and efficient translation into SQLAlchemy .where() clauses. The RLS tests and implementation provide a practical example of how RLS filters can be defined with conditions and applied to SQL queries, showcasing the support for the required features in your ABAC DSL proposal.

The current RLS feature in Superset, as demonstrated in the integration tests, supports defining filters with various conditions, applying these filters based on user roles and dataset-specific rules, and translating these rules efficiently into SQL queries. This aligns with your goals for a DSL that supports equality, sets, negative flips, logical operators, and can be translated into efficient database queries.

Improving upon the current ABAC implementation could involve addressing any existing limitations, such as the complexity of maintaining the system, performance concerns with dynamic permission checks, limited attribute support, and integration challenges with external systems. Enhancing these aspects could lead to a more robust, efficient, and user-friendly ABAC system within Superset.

In summary, leveraging insights from Superset's RLS feature and addressing its limitations could provide a solid foundation for developing a new DSL and ABAC selectors that meet your objectives for a more intuitive, scalable, and manageable security framework.

To continue the conversation, mention @dosu.

from superset.

@dosu can you help summarize this proposal into a few paragraphs?

from superset.

@dosu can you do some research and suggest similar DSLs or frameworks we may want either use or take inspiration from around our DSL and ABAC selecrors?

from superset.

Unsorted NOTEs from 5/14/24:

• DENY always takes precedence over ALLOW (?) "UNLESS! zindex !important"
• Reverse lookup - who can perform this action on this resource?
• What's in the JWT - size restriction - SHA?
  -What's the set of starting resource attribute? ownership!
  • dashboard.is_published
  • dashboard.is_owner
• PolicyManager performance - cache using a global EPOCH? by resource type? by user?
• sizing largest/most complicated envrionments? CAN THIS WORK IN MEMORY?

from superset.