Access Control

Access Control in Superset#

Superset's resource access model operates at two levels: capability grants (which API actions a user can invoke, managed by FAB roles and permissions) and resource assignments (who can view or edit a specific dashboard, chart, dataset, etc., managed by the mechanisms described here).

There are two coexisting models in the codebase depending on the version/branch you're working with:

Owner/DASHBOARD_RBAC model — the current production model in the master branch at the time of writing.
Subject/Editor/Viewer model — the upcoming replacement introduced in PR #38831, currently open against master.

The sections below cover both. Engineers building features against the current main-line code should be aware that the Subject model is an in-flight breaking change.

Current Model: Owner-Based Access + DASHBOARD_RBAC#

Ownership#

Each resource (dashboard, chart, dataset, report) carries an owners relationship to FAB users via a junction table. For dashboards, this is the dashboard_user table; the ORM relationship is defined on the Dashboard model as owners.

Admins and owners bypass all further access checks in raise_for_access.

Default (Dataset-Based) Dashboard Access#

Without DASHBOARD_RBAC, a non-owner user can access a dashboard if they have access to at least one datasource used by that dashboard — or if the dashboard uses no datasources at all . This is the implicit dataset-permission visibility model.

DASHBOARD_RBAC#

When the DASHBOARD_RBAC feature flag is enabled (default: False, see config.py line 503), dashboard access can instead be controlled by assigning FAB roles directly to a dashboard.

The DashboardRoles junction table (columns: dashboard_id, role_id) stores these assignments. The ORM relationship lives on the Dashboard model as roles .

Access logic in raise_for_access:

When DASHBOARD_RBAC is enabled and the dashboard has roles assigned, access is granted if the dashboard is published and the current user holds at least one matching role.
Dashboards with no roles assigned still fall through to the regular dataset-based check.

Datasource bypass: When DASHBOARD_RBAC is active and a dashboard has roles, viewers are also exempt from per-datasource permission checks for charts belonging to that dashboard . This allows role-holders to see chart data without being granted explicit dataset permissions.

Key files (current model)#

File	Purpose
`superset/models/dashboard.py`	`dashboard_user`, `DashboardRoles` tables; `owners`, `roles` relationships
`superset/security/manager.py`	`raise_for_access` — dashboard access enforcement
`superset/security/manager.py`	`can_access_dashboard` — boolean wrapper
`superset/config.py`	`DASHBOARD_RBAC` feature flag (default `False`)

Upcoming Model: Subjects, Editors, and Viewers (PR #38831)#

PR #38831 introduces a unified Subject model that replaces owner-based and DASHBOARD_RBAC-based access. This is a breaking change — the legacy owners, roles, and DASHBOARD_RBAC API/config semantics are removed.

Subject Model#

A new subjects table is a unified reference to FAB users, roles, and groups :

Field	Description
`uuid`	Stable identifier
`label`	Display name (e.g., `Alice Smith`, `Data Engineering`)
`type`	`1=User`, `2=Role`, `3=Group`
`user_id` / `role_id` / `group_id`	FK to source FAB model

Key source files introduced: superset/subjects/models.py, superset/subjects/types.py, superset/subjects/filters.py, superset/subjects/views.py, superset/subjects/sync.py .

Editors Replace Owners#

editors replace owners for all resources. Junction tables link subjects to resources :

Resource	Editor table	Viewer/subject table
Dashboards	`dashboard_editors`	`dashboard_viewers`
Charts	`chart_editors`	`chart_viewers`
Datasets	`sqlatable_editors`	—
Alerts & Reports	`report_schedule_editors`	—
Row Level Security	—	`rls_filter_subjects`

The migration seeds data from the legacy tables then drops them: dashboard_user → dashboard_editors, slice_user → chart_editors, dashboard_roles → dashboard_viewers, rls_filter_roles → rls_filter_subjects .

Viewers Replace DASHBOARD_RBAC#

The ENABLE_VIEWERS feature flag gates viewer-based access for dashboards and charts :

Viewers assigned: only explicitly assigned subjects (users, groups, or roles) can view that resource.
No viewers assigned: falls back to the implicit dataset-access model (backwards-compatible).
VIEWER_PROMISCUOUS_MODE = True: viewers bypass datasource RBAC checks, matching the old DASHBOARD_RBAC datasource-bypass behavior.

Subject Picker Defaults#

Subject pickers default to Users + Groups only. Roles are hidden by default (but remain effective for existing assignments). The default set can be overridden globally via SUBJECTS_RELATED_TYPES or per-entity via SUBJECTS_RELATED_TYPES_DASHBOARDS, SUBJECTS_RELATED_TYPES_CHARTS, SUBJECTS_RELATED_TYPES_RLS, SUBJECTS_RELATED_TYPES_ALERT_REPORTS . The rationale: roles should remain focused on capability grants, not resource membership.

API Changes#

Old	New
`owners` field	`editors` field
`dashboard.roles`	`viewers` (when `ENABLE_VIEWERS`)
`rls.roles`	`subjects`
`DASHBOARD_RBAC` flag	`ENABLE_VIEWERS` + `VIEWER_PROMISCUOUS_MODE`
`EXTRA_OWNERS_RESOLVER`	`EXTRA_EDITORS_RESOLVER`
`CREATOR_OWNER` / `MODIFIER_OWNER` / `OWNER` executor types	`CREATOR_EDITOR` / `MODIFIER_EDITOR` / `EDITOR`

Frontend Components#

New UI components live in superset-frontend/src/features/subjects/ :

SubjectPicker — async dropdown for selecting users, groups, or roles.
SubjectPile — display component with distinct avatar shapes (circle = User, rounded square = Group, octagon = Role).
SubjectSelectLabel — label rendering for individual subjects.

The dashboard Access tab in PropertiesModal/sections/AccessSection.tsx uses SubjectPicker for both editors and viewers .

Current Dashboard Access Flow#

The following diagram shows the current (owner/DASHBOARD_RBAC) dashboard access logic in raise_for_access:

Loading diagram...

With the Subject model (PR #38831), the DASHBOARD_RBAC branch is replaced by ENABLE_VIEWERS + viewer subject checks, and owners becomes editors.

Row-Level Security#

Row Level Security (RLS) filters are currently assigned to FAB roles (not individual users or groups). With the Subject model, RLS rules will use the rls_filter_subjects junction table, enabling assignment to users, roles, and groups .

Group-Based Dashboard Access (Ongoing Discussion)#

As of July 2026, a community discussion (#41684) raised the request to assign user Groups directly to a dashboard's access list without waiting for the full Subject model migration. The discussion traces through three prior design SIPs:

SIP-126 (#28021) — proposed a dashboard access model supporting Users, Groups, and Roles as "Viewers" (closed).
SIP-156 (#32116) — re-proposed the same (closed).
SIP-131 (#28377) — the ongoing redesign that became PR #38831.

This is relevant context for SSO/LDAP/OIDC deployments where groups are the primary identity unit: today they must create a FAB role per group as a workaround, which the Subject model resolves end-to-end .

Migration and Breaking Changes#

PR #38831 is not backwards-compatible at the API level . Key callouts for engineers:

Run superset db upgrade to apply the migration that seeds subjects from legacy junction tables and drops the legacy tables.
API clients must send/read editors instead of owners; viewers instead of dashboard roles; subjects instead of RLS roles.
Custom code using EXTRA_OWNERS_RESOLVER must migrate to EXTRA_EDITORS_RESOLVER.
Alert/report executor types (CREATOR_OWNER, MODIFIER_OWNER, OWNER) are renamed to CREATOR_EDITOR, MODIFIER_EDITOR, EDITOR.
Downgrade is supported: the migration can recreate legacy tables from subject data if rolled back.
Viewer adoption is incremental: enabling ENABLE_VIEWERS does not require immediately backfilling viewers onto existing resources — those resources continue using dataset-based visibility until at least one viewer is assigned.

Refer to UPDATING.md in the repository for the official migration guide .