Access Control#
Superset's resource access model has two distinct layers:
- Capability grants — which API actions a user can invoke, managed by Flask-AppBuilder (FAB) roles and permission-view pairs (PVMs). See Role and Permission Management.
- Resource assignments — who can view or edit a specific dashboard, chart, or dataset. This article focuses on the latter.
Two models coexist in the codebase, depending on which version you are working with:
- Owner /
DASHBOARD_RBACmodel — the current production model on themasterbranch. - Subject / Editor / Viewer model — the upcoming replacement introduced in PR #38831, targeting
masteras a breaking change.
Current Model: Owner-Based Access + DASHBOARD_RBAC#
Ownership#
Every resource (dashboard, chart, dataset, report) carries an owners many-to-many relationship to FAB users. For dashboards, this is the dashboard_user junction table defined on the Dashboard model.
Admins and owners bypass all further access checks. See raise_for_access in SupersetSecurityManager .
Default (Dataset-Based) Dashboard Access#
Without DASHBOARD_RBAC, a non-owner can access a dashboard if they have datasource_access to at least one datasource used by the dashboard — or if the dashboard has no datasources at all . This is the implicit dataset-permission model.
DASHBOARD_RBAC#
When the DASHBOARD_RBAC feature flag is enabled (default: False) , FAB roles can be assigned directly to a dashboard via the DashboardRoles junction table (dashboard_id, role_id).
Access logic in raise_for_access :
- If
DASHBOARD_RBACis enabled and the dashboard has roles assigned → access is granted when the dashboard is published and the user holds at least one matching role. - Dashboards with no roles assigned fall through to the regular dataset-based check.
Datasource bypass: When a user gains access via DASHBOARD_RBAC, they also bypass per-datasource permission checks for charts belonging to that dashboard . This lets role-holders see chart data without explicit dataset grants.
The same bypass applies to embedded guest users: when EMBEDDED_SUPERSET is enabled and the request carries a valid guest token, datasource checks are skipped for charts on the permitted dashboard .
Key Files (Current Model)#
| File | Purpose |
|---|---|
superset/security/manager.py | raise_for_access() — enforces dashboard and datasource access |
superset/config.py | DASHBOARD_RBAC feature flag (line 503) |
superset/dashboards/filters.py | List-view filters for dashboard access |
superset/commands/dashboard/update.py | Ownership enforcement on dashboard edits |
Dashboard Access Flow (Current Model)#
Note on
DASHBOARD_RBAC+ unpublished dashboards: Thepublishedcheck only applies in the RBAC branch. The regular dataset-based check does not require the dashboard to be published, intentionally allowing creators to share work-in-progress dashboards with datasource-authorized viewers .
Upcoming Model: Subject / Editor / Viewer (PR #38831)#
PR #38831 replaces owner-based and DASHBOARD_RBAC access with a unified Subject model. This is a breaking change at both the API and database schema levels.
Subject Model#
A new subjects table provides a unified reference to FAB users, groups, and roles :
| Field | Description |
|---|---|
type | 1 = User, 2 = Role, 3 = Group |
user_id / role_id / group_id | FK to the source FAB entity |
label | Display name |
Editors Replace Owners#
editors replace owners for all resources. Junction tables link subjects to resources :
| Resource | Editor table | Viewer table |
|---|---|---|
| Dashboards | dashboard_editors | dashboard_viewers |
| Charts | chart_editors | chart_viewers |
| Datasets | sqlatable_editors | — |
| Row Level Security | — | rls_filter_subjects |
The migration seeds data from legacy tables: 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 :
- 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 oldDASHBOARD_RBACdatasource-bypass behavior.
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 |
Subject Picker UI#
New frontend components live in superset-frontend/src/features/subjects/ :
SubjectPicker— async dropdown for selecting users, groups, or roles.SubjectPile— avatar display with distinct shapes (circle = User, rounded square = Group, octagon = Role).
The dashboard Access tab in PropertiesModal/sections/AccessSection.tsx uses SubjectPicker for both editors and viewers.
By default the picker surfaces Users + Groups only; roles can be re-enabled via SUBJECTS_RELATED_TYPES configuration keys .
Migration Notes (PR #38831)#
- Run
superset db upgradeto apply the migration that seeds subjects from legacy tables. - API clients must switch
owners→editors,dashboard.roles→viewers,rls.roles→subjects. - Alert/report executor types are renamed:
CREATOR_OWNER→CREATOR_EDITOR,MODIFIER_OWNER→MODIFIER_EDITOR,OWNER→EDITOR. - Downgrade is supported: the migration can recreate legacy tables from subject data if rolled back.
- Enabling
ENABLE_VIEWERSis incremental — resources with no viewers assigned continue using dataset-based visibility until a viewer is explicitly added.
Refer to UPDATING.md in the repository for the official migration guide.
Related Articles#
- Role and Permission Management — FAB RBAC schema,
sync_role_definitions, built-in roles - Permission Registration — how PVMs are created and synced at startup
- Embedded Dashboard Rendering — guest token flow and embedded access
- Anonymous Access Configuration — Public role and
AUTH_ROLE_PUBLIC - Dataset Access Control — datasource-level permission checks