Access Control in Superset: Roles, Groups & Row-Level Security – SYNTASA™

A practical guide to how Superset manages who sees what — from built-in roles to fine-grained row filtering.

Built-in roles

Superset ships with four default roles, initialized at startup. They form a hierarchy from full system control down to anonymous guest access.

Role	Access level	What it can do
Admin	Full system	Manages users, roles, databases, and all data. Bypasses all RLS filters.
Alpha	Full data + create	Create and edit datasets, dashboards, charts, and SQL Lab. Cannot manage users or security.
Gamma	Read-only	View dashboards and charts only, scoped to explicitly granted datasets and schemas.
sql_lab	SQL Lab only	Access to SQL Editor, Saved Queries, Query History. Usually stacked with another role.
Public	Anonymous / guest	Used for unauthenticated or JWT-embedded (guest token) access.

Syntasa also provisions one additional custom role — Dashboard Viewer — assigned to Firebase/anonymous users for read-only dashboard access, more restricted than Gamma.

Syntasa roles and their Superset mapping

Syntasa maintains its own role system in the auth service database (ROLES table). Each Syntasa role has a SUPERSET_ROLE_NAME column that maps it to a Superset role, established via Flyway migrations.

Syntasa role	Superset role	Priority
System Admin	Admin	1
DataAI Admin	Alpha	2
Dashboards Viewer	Alpha	2
Dashboards User	Alpha	2
DataAI User	No mapping → defaults to Gamma
DonorAI Admin / User	No mapping → defaults to Gamma
Audience Admin / User	No mapping → defaults to Gamma
CCDP Admin / User	No mapping → defaults to Gamma

Priority resolution: When a user holds multiple Syntasa roles, the SUPERSET_ROLES priority table determines the winner. Admin wins at 1, Alpha at 2, Gamma at 5, and Public/sql_lab at 100 (lowest).

SSO login and role assignment

When a user logs in via SSO, the following steps determine which Superset role they receive.

User → GET /login?accessToken=<token>
         │
         ▼
  superset_config.py (FLASK_APP_MUTATOR / _sso_handler)
         │
         ▼
  POST auth-service/validateToken
         │
         ▼
  TokenResponse: { userName, supersetRole: "Alpha", ... }
         │
         ├── user exists? → login_user(user)
         │
         └── user new?  → sm.add_user(..., role=find_role(role_name))
                          then login_user(user

Firebase / embedded users always receive the Dashboard Viewer role, regardless of any token claims.

Row-level security (RLS)

RLS restricts which rows a user sees in a dataset at query time. It is managed under Security → Row Level Security in the Superset UI or via the API.

Filter types

Type	Behavior
Regular	Filter is applied when the user has one of the specified roles.
Base	Filter is applied to everyone except users with the specified roles. Use this to set a default restriction and exempt Admin.

Filter fields

Field	Required	Description
`name`	Yes	Unique identifier for the filter
`filter_type`	Yes	Regular or Base
`tables`	Yes	Which dataset(s) this filter applies to
`roles`	Yes	Superset roles this filter targets
`clause`	Yes	SQL WHERE clause (supports Jinja2 templates)
`group_key`	No	Groups filters for OR/AND logic
`description`	No	Human-readable notes

Group key logic

Filters with the same group_key are OR'd together. Filters with different group_key values are AND'd together

Example:

Filter A: clause="region='US'",    group_key="region", roles=["US_Analysts"]
Filter B: clause="region='EU'",    group_key="region", roles=["EU_Analysts"]
Filter C: clause="tier='premium'", group_key="tier",   roles=["PremiumOnly"]
User with US_Analysts + PremiumOnly roles sees:
  WHERE (region='US') AND (tier='premium')
User with EU_Analysts alone sees:
WHERE (region='EU')

Filters with no group_key each apply independently (all AND'd).

Admin bypass pattern

To let Admin see all data while restricting everyone else:

filter_type: Base
clause: "status = 'active'"
roles: [Admin]   ← Admin is EXCLUDED from this filter

Result: everyone except Admin only sees status = 'active' rows.

Jinja2 Template Support in Clauses

RLS clauses support Jinja2 templating, for example:

user_id = {{ current_user_id() }}
org_id = {{ get_user_attribute('org_id') }}

Dashboard RBAC

Beyond RLS (which restricts rows within a dataset), Superset's DASHBOARD_RBAC feature flag allows restricting which roles can access an entire dashboard. Owners assign specific roles under the dashboard's Edit → Access tab — adding a coarse-grained, dashboard-level gate on top of the row-level data controls.

{[{category.name}]}