[SIP-152] User Groups for Simplified User and Role Management

[dpgaspar]

[SIP-152] User Groups for Simplified User and Role Management

Motivation

Currently, Apache Superset assigns roles directly to users, allowing for flexible but sometimes cumbersome permission management. As organizations scale, security management and role assignment become increasingly complex, particularly with large user bases. Managing roles at the individual user level leads to inefficiencies and inconsistencies, making access control difficult to maintain and audit.

User and role management challenges become particularly evident in the following situations:

• Applying permission changes to roles associated with a large user set, as these users are not explicitly grouped together.
• Assigning a new role to a large user set without a clear mechanism for bulk updates.
• Managing temporary or project-based access where users need time-limited permissions that must be revoked later.
• Handling employee transitions.
• Synchronizing users with an Identity Provider (IdP) where roles are handled as groups.

This SIP proposes the introduction of User Groups, which will allow multiple users to be grouped together while also associating multiple roles with the group. This will streamline permission management, making it easier to manage access control across different user sets. By introducing groups, administrators can efficiently assign and modify permissions at scale, reducing administrative overhead while improving security and compliance.

Proposed Change

Introduction of User Groups

• A Group is a new entity that contains multiple Users and multiple Roles.
• Users within a group inherit all roles assigned to that group.
• Users can still have roles assigned directly, ensuring backward compatibility.
• A user can belong to multiple groups.
• Groups will be managed via the UI and API.

Changes to Data Model

Code changes

Apache Superset relies on Flask-AppBuilder (FAB) for authentication and authorization, and it is more natural to introduce User Groups at the Flask-AppBuilder level because:

• Model Definitions: Superset's user and role models are defined in Flask-AppBuilder, making it the right place to introduce group models (ab_group, ab_group_user, and ab_group_role).
• API Permissions and Authorization: Permissions are asserted at the Flask-AppBuilder level before Superset handles the request. Introducing groups at this level ensures API permission checks work seamlessly across all FAB-based applications, including Superset.
• Centralized Role Management: Since Flask-AppBuilder already provides role-based access control (RBAC), implementing groups here allows a more consistent and maintainable approach across multiple projects that use FAB.

A POC is already started here: dpgaspar/Flask-AppBuilder#2305

However, changes will also be required at the Superset level to ensure proper integration:

• Database Migration: Superset will need migration scripts to handle the new group-related tables and relationships.

• Data Access Assertions: Superset applies additional data access checks beyond those enforced by Flask-AppBuilder. These will need updates to consider group-based role inheritance.

UI & API Enhancements: FAB's UI and API must be updated to allow users to manage groups and assign roles accordingly.

Ownership authorization:

We have the concept of ownership on dashboards, charts, datasets and alerts & reports. SIP-126 proposed introducing group based entity ownership. This SIP is a step forward on this direction while maintaining (and improving) the current datasource implicit access.

POC screenshots:

Groups menus access:

List of users now with groups:

List of Groups:

New or Changed Public Interfaces

Flask-AppBuilder will introduce new database models a new ModelView and the following permissions:

• can list on UserGroupModelView
• can add on UserGroupModelView
• can edit on UserGroupModelView
• can show on UserGroupModelView
• can delete on UserGroupModelView

As well as the following REST APIs

• GET /api/v1/security/groups/ - List groups
• GET /api/v1/security/groups/<id> - Get group
• PUT /api/v1/security/groups/<id> - Change group
• POST /api/v1/security/groups/ - Add group
• DELETE /api/v1/security/groups/<id> - Delete group
• POST `/api/v1/security/groups//users/ - Add user(s) to group
• DELETE `/api/v1/security/groups//users// - Remove user from group
• POST `/api/v1/security/groups//roles/ - Add role(s) to group
• DELETE `/api/v1/security/groups//roles// - Remove role from group

Apache Superset will need the following changes:

• A database migration that will create the new tables
• Add previously described new permissions to the admin roles
• Change security/manager methods that assert data access to include groups

A POC is already started here: #32121

New dependencies

No new dependencies will be added, Superset will require flask-appbuilder > 4.6.0.

Migration Plan and Compatibility

Implementation plan on 3 phases:

Phase1, backward compatible:

• Add Group entities to flask-appbuilder and release
• Bump flask-appbuilder on Superset and adapt datasource authorization

Phase2 SIP-126 (Breaking Superset 6.0)

• replace all owner references with the new Subject model that can be a User, Group or Role. This covers Dashboards, Charts, Datasets and Alerts & Reports.
• introduce the Viewer property to Dashboard and Chart entities (for Alerts & Reports having a Viewer is not very useful). During the migration we map all Dashboard RBAC roles as Viewers and remove the DASHBOARD_RBAC feature flag.

Phase 3 (Breaking Superset 6.0 or 7.0):

• Remove datasource access permissions. Map Roles that have implicit access to Dashboards and Charts to their respective Viewer property, and remove the implicit dashboard/chart access control logic. However, for Dashboards that are in Draft state we leave the Viewer property empty.
• Remove the "published" property from the Dashboard model, and remove the Draft/Published pill (good riddance!).

This proposed feature is backward compatible.

Rejected Alternatives

Keeping the current direct role assignment model but improving UI bulk assignment tools.

[villebro]

This is a really nice improvement! Some thoughts:

Group properties

• LDAP typically has human readable name (cn) that may change over time to complement the main constant "technical name" (uid or gidNumber for groups). So it may be a good idea to have an additional field label that is displayed in the dropdown lists.
• Having an optional description field would be helpful for adding extra context. Text in this field can be displayed in the dropdown as subtitle, and also be used to filter values. We're doing something similar in the dataset dropdown, where the database name is displayed as the subtitle.

Entity ownership

SIP-126 proposed introducing group based entity ownership. This would benefit deployments where charts/dashboards are expected to be owned per group, rather than per person.

Introduce viewer property

SIP-126 also proposed adding a Viewer property to Dashboards and Charts. By being able to define Viewers, we could remove the current "implicit" access model, where dashboards are viewable if

1. You have dataset access to any chart in the dashboard.
2. The dashboard is Published.

By being able to define Viewers, we could remove the Draft/Published pill, which would make dashboard access explicit. This would also make it possible to remove the Dashboard RBAC feature flag, which was really just a workaround for Group access, but using Roles as a proxy.

[michael-s-molina]

Thanks for writing this SIP @dpgaspar. I think users groups will indeed offer more flexibility.

@villebro's points extracted from SIP-126 are a nice complement to the proposal.

Optional changes:
We have the concept of ownership on dashboards, charts, datasets and alerts & reports. This proposal does not include changes on object ownership, yet we should consider adding group ownership to these resources.

I think this is essential for the proposal, so I wouldn't make it optional. The big win of having user groups is to eliminate the tedious task of individually assigning users to assets. I also agree that we should support both groups and users as asset owners/viewers. This is important for backward compatibility but also to offer the necessary flexibility to users.

As well as the following (optional) REST APIs
GET /api/v1/security/groups/ - List groups
GET /api/v1/security/groups/ - Get group
PUT /api/v1/security/groups/ - Change group
POST /api/v1/security/groups/ - Add group
DELETE /api/v1/security/groups/ - Delete group

We need to be able manage these relationships using the API so this is also not optional for me. At Airbnb, we have an external system that manages users, roles and groups and we'll need to sync that system with Superset using the APIs. @dpgaspar are we missing the endpoints to associate users and roles with groups or will these be achieved through the listed endpoints?

List of Groups:

I understand that it's easier to create the groups list following the same pattern as the users and roles lists. The problem is that it will be another screen that we'll need to convert to the SPA project. Given that this is a new feature, maybe this is the opportunity to create the groups list using React as we did for the Row Level Security screen and set the foundations to later migrate users and roles.

[dpgaspar]

This is a really nice improvement! Some thoughts:

Group properties

• LDAP typically has human readable name (cn) that may change over time to complement the main constant "technical name" (uid or gidNumber for groups). So it may be a good idea to have an additional field label that is displayed in the dropdown lists.
• Having an optional description field would be helpful for adding extra context. Text in this field can be displayed in the dropdown as subtitle, and also be used to filter values. We're doing something similar in the dataset dropdown, where the database name is displayed as the subtitle.

Entity ownership

SIP-126 proposed introducing group based entity ownership. This would benefit deployments where charts/dashboards are expected to be owned per group, rather than per person.

Introduce viewer property

SIP-126 also proposed adding a Viewer property to Dashboards and Charts. By being able to define Viewers, we could remove the current "implicit" access model, where dashboards are viewable if

1. You have dataset access to any chart in the dashboard.
2. The dashboard is Published.

By being able to define Viewers, we could remove the Draft/Published pill, which would make dashboard access explicit. This would also make it possible to remove the Dashboard RBAC feature flag, which was really just a workaround for Group access, but using Roles as a proxy.

Totally agree! Added label and description to groups.

Also love the idea of Entity ownership using Subjects with links to user, groups or roles. We have 2 possible paths here:

• We can limit the scope of SIP-152 to just Group entities applied to FAB permissions and datasource access, this would pave the way for SIP-126 (maybe we can reopen it?).

Or:

• We can merge SIP-126 into SIP-152 and define a path forward, here's a draft:

  • Introduce Group entities that apply to FAB permissions and datasource access
  • Introduce Entity ownership using subjects (User, Groups, Roles) that can be viewers and editors of dashboard, charts, datasets, Alerts & Reports.
  • Remove datasource access permissions?

[dpgaspar]

Thanks for writing this SIP @dpgaspar. I think users groups will indeed offer more flexibility.

@villebro's points extracted from SIP-126 are a nice complement to the proposal.

Optional changes:
We have the concept of ownership on dashboards, charts, datasets and alerts & reports. This proposal does not include changes on object ownership, yet we should consider adding group ownership to these resources.

I think this is essential for the proposal, so I wouldn't make it optional. The big win of having user groups is to eliminate the tedious task of individually assigning users to assets. I also agree that we should support both groups and users as asset owners/viewers. This is important for backward compatibility but also to offer the necessary flexibility to users.

-Regarding SIP-126, we can merge it's concept into this SIP or consider this one a first step for it, a bit more detail here: #32116 (comment)

As well as the following (optional) REST APIs
GET /api/v1/security/groups/ - List groups
GET /api/v1/security/groups/ - Get group
PUT /api/v1/security/groups/ - Change group
POST /api/v1/security/groups/ - Add group
DELETE /api/v1/security/groups/ - Delete group

We need to be able manage these relationships using the API so this is also not optional for me. At Airbnb, we have an external system that manages users, roles and groups and we'll need to sync that system with Superset using the APIs. @dpgaspar are we missing the endpoints to associate users and roles with groups or will these be achieved through the listed endpoints?

Makes sense added the missing endpoints.

List of Groups:

I understand that it's easier to create the groups list following the same pattern as the users and roles lists. The problem is that it will be another screen that we'll need to convert to the SPA project. Given that this is a new feature, maybe this is the opportunity to create the groups list using React as we did for the Row Level Security screen and set the foundations to later migrate users and roles.

• Regarding SIP-126, we can merge it's concept into this SIP or consider this one a first step for it, a bit more detail here: [SIP-152] User Groups for Simplified User and Role Management #32116 (comment)

There's an ongoing effort to migrate these views, I agree this should be a part of that effort @geido do you agree?

[villebro]

We can limit the scope of SIP-152 to just Group entities applied to FAB permissions and datasource access, this would pave the way for SIP-126 (maybe we can reopen it?).

There's a few initiatives brewing in the security space:

• [SIP-131] Superset Security Model Redesign #28377: When rolled out, this SIP will implement super granular permissions throughout the app. As datasource permissions are at the core of this, I propose deferring datasource permission control changes to that SIP.
• [SIP-151] The vision for a new Superset Plugins Architecture #31932: This SIP will eventually make everything pluggable. As security plugins are also covered (e.g. OPA plugin for managing access controls outside Superset), it's probably a good idea to steer clear of those changes here, too.

So my proposal is to do these as part of this SIP:

• We replace all owner references with the new Subject model that can be a User, Group or Role. This covers Dashboards, Charts, Datasets and Alerts & Reports.
• We introduce the Viewer property to Dashboard and Chart entities (for Alerts & Reports having a Viewer is not very useful). During the migration we map all Dashboard RBAC roles as Viewers and remove the DASHBOARD_RBAC feature flag.
• We map Roles that have implicit access to Dashboards and Charts to their respective Viewer property, and remove the implicit dashboard/chart access control logic. However, for Dashboards that are in Draft state we leave the Viewer property empty. Finally we remove the "published" property from the Dashboard model, and remove the Draft/Published pill (good riddance!).

What we DON'T do:

• Touch database/dataset access controls (these will be addressed by SIPs 131 and 151).

I'm really excited for this, can't wait to roll this out in 6.0! 🚀

[michael-s-molina]

Thank you for the fantastic suggestions, @villebro! In addition to introducing new features, these improvements will also contribute to a cleaner and more organized codebase.

[dpgaspar]

We can limit the scope of SIP-152 to just Group entities applied to FAB permissions and datasource access, this would pave the way for SIP-126 (maybe we can reopen it?).

There's a few initiatives brewing in the security space:

• [SIP-131] Superset Security Model Redesign #28377: When rolled out, this SIP will implement super granular permissions throughout the app. As datasource permissions are at the core of this, I propose deferring datasource permission control changes to that SIP.
• [SIP-151] The vision for a new Superset Plugins Architecture #31932: This SIP will eventually make everything pluggable. As security plugins are also covered (e.g. OPA plugin for managing access controls outside Superset), it's probably a good idea to steer clear of those changes here, too.

So my proposal is to do these as part of this SIP:

• We replace all owner references with the new Subject model that can be a User, Group or Role. This covers Dashboards, Charts, Datasets and Alerts & Reports.
• We introduce the Viewer property to Dashboard and Chart entities (for Alerts & Reports having a Viewer is not very useful). During the migration we map all Dashboard RBAC roles as Viewers and remove the DASHBOARD_RBAC feature flag.
• We map Roles that have implicit access to Dashboards and Charts to their respective Viewer property, and remove the implicit dashboard/chart access control logic. However, for Dashboards that are in Draft state we leave the Viewer property empty. Finally we remove the "published" property from the Dashboard model, and remove the Draft/Published pill (good riddance!).

What we DON'T do:

• Touch database/dataset access controls (these will be addressed by SIPs 131 and 151).

I'm really excited for this, can't wait to roll this out in 6.0! 🚀

Nice! added these to a possible migration/implementation plan. Created 3 phases for it.
If you all agree, do you think this is ready to Vote?
@villebro @michael-s-molina

[villebro]

If you all agree, do you think this is ready to Vote?

I think my points are all covered by the SIP, so happy to kick off the vote 👍

[michael-s-molina]

If you all agree, do you think this is ready to Vote?

Your edits addressed my suggestions too 👍🏼

[withnale]

We replace all owner references with the new Subject model that can be a User, Group or Role. This covers Dashboards, Charts, Datasets and Alerts & Reports

Is the intention during these changes to make the the new model resource type independent? There seems to be a lot of duplication in the code and database schema right now and this seems like a good opportunity to make this functionality more portable.