[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

Image

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: https://github.com/dpgaspar/Flask-AppBuilder/pull/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: Image

List of users now with groups: Image

List of Groups: Image

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/<id>/users/ - Add user(s) to group - DELETE/api/v1/security/groups//users// - Remove user from group - POST /api/v1/security/groups/<id>/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: https://github.com/apache/superset/pull/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.

Comment From: 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.

Comment From: 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.

Comment From: 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?

Comment From: 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: https://github.com/apache/superset/issues/32116#issuecomment-2643259484

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: https://github.com/apache/superset/issues/32116#issuecomment-2643259484

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

Comment From: 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: - #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. - #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! 🚀

Comment From: 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.

Comment From: 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:

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

Comment From: 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 👍

Comment From: michael-s-molina

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

Your edits addressed my suggestions too 👍🏼

Comment From: 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.

Comment From: villebro

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.

@withnale do you mean adding mixins like OwerMixin and ViewerMixin and the like? We've done something similar for AuditMixinNullable, and we'll probably do the same here to avoid duplication.

Comment From: withnale

It was more wondering about whether the methods and tables associated with ownership would continue to be per-resource based? At present there is a user mapping DB table per resource sqlatable_user, slice_user, dashboard_user. We have no dbs_user but we also have a pluralised dashboard_roles.

It seems that most of these will be affected by ability to associate user,group,role to owner/viewer attributes of a resource.

Comment From: villebro

@withnale as Superset is ORM based, having dedicated tables for these types of mappings is fairly natural, as the model needs to be queriable from a number of different perspectives, need to be highly performant and scale well. Also, as all of this is mostly abstracted away from end users (users should not directly interact with the metastore model, but via the API), this shouldn't really be a major concern for end users or admins. However, I'm sure we'll evaluate the pros and cons of each alternative during implementation before choosing the final design.

Comment From: drummerwolli

@dpgaspar have you considered the following alternative: roles can be superset of multiple other roles? i wonder why a new entity type has to be introduced here. also, why not drive the thought even further: your approach enables now better bulk permission roll out, yes, but i think the ultimate goal would be infitite grouping possibilities: a role (or in your case: a user group) can contain multiple roles (or user groups), and these roles again can contain multiple roles (or user groups), and so on. Why stop already at the first level? Would it be so super complicated to make the grouping level infinite?

anyways, very happy to see that Superset is tackling this problem in general, highly appreciated. either outcome, this will make maintenance life much easier! 💓

Comment From: villebro

@drummerwolli it's typical for Roles and Groups to be different concepts. If you consider LDAP, users will typically belong to groups, but what those groups allow them to do is a different matter, and is usually up to a centralized authorization system (e.g. OPA), or the individual applications. Having this separation will make it more straight forward to integrate Superset in typical enterprise contexts.

Comment From: geido

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

Confirmed. We are migrating FAB views as part of the theming effort

Comment From: michael-s-molina

Confirmed. We are migrating FAB views as part of the theming effort

Wohoo! Thanks for confirming @geido!

Comment From: michael-s-molina

@dpgaspar @rusackas Did we vote on this SIP? If not, can we submit it for voting?

Comment From: greg-om

Our organization is also really interested in this functionality 😄

Comment From: min-awm

I think can add sub-groups. Sub-groups will inherit roles from the parent group.

Comment From: rusackas

This just hit my stale radar... the SIP passed, so I'll close it since that part of the process is done ✅