feat(security): add built-in Public role for anonymous dashboard access

[rusackas]

SUMMARY

This PR adds a new built-in "Public" role to Superset, designed for anonymous/unauthenticated users who need to view dashboards. The Public role is more restrictive than Gamma and provides sensible defaults for public-facing dashboard deployments.

Background: In #36025, it was identified that using PUBLIC_ROLE_LIKE = "Gamma" grants excessive permissions including write and delete capabilities that are inappropriate for public access. Rather than documenting a complex set of manual permissions, this PR creates a new built-in role with sensible, secure defaults.

Key changes:

• New PUBLIC_ROLE_PERMISSIONS set defining minimal dashboard viewing permissions
• New _is_public_pvm() method to determine Public role permissions
• Public role is now created during sync_role_definitions() alongside Admin, Alpha, Gamma, and sql_lab
• Users can set PUBLIC_ROLE_LIKE = "Public" to use these safe defaults

The Public role includes:

• Dashboard and chart viewing (can_read on Dashboard, can_read on Chart)
• Interactive dashboard filters (can_read/write on DashboardFilterStateRestApi)
• Dashboard and chart permalinks (can_read on DashboardPermalinkRestApi, can_read on ExplorePermalinkRestApi)
• Embedded dashboard support (can_read on EmbeddedDashboard)
• Annotations on charts (can_read on Annotation, can_read on AnnotationLayerRestApi)
• Datasource metadata for chart rendering (can_get, can_external_metadata on Datasource)
• CSS templates for styling (can_read on CssTemplate)
• API access for chart rendering (can_time_range, can_query_form_data, can_query on Api)

The Public role explicitly excludes:

• Write permissions on dashboards, charts, datasets
• SQL Lab access
• Share functionality
• User profile/admin features
• Menu access to most features
• Any all_datasource_access or all_database_access permissions

Important notes:

• The built-in Public role only activates when PUBLIC_ROLE_LIKE = "Public" is explicitly set. If unset (None), the Public role remains empty, preserving existing/legacy behavior.
• When using with DASHBOARD_RBAC feature flag enabled, anonymous users only see dashboards where the "Public" role has been explicitly added as an owner.
• The Public role permissions sync on Superset startup. Manual permission edits may be overwritten during upgrades/restarts.
• Data access must still be granted separately by adding datasets to the Public role.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

N/A - This is a backend role/permission change.

TESTING INSTRUCTIONS

1. Run superset init to sync role definitions
2. Verify the new "Public" role exists in Security > List Roles
3. Check the Public role has the expected minimal permissions (see list above)
4. Test setting PUBLIC_ROLE_LIKE = "Public" in config and verify anonymous users can view dashboards but cannot:
   • Edit dashboards or charts
   • Access SQL Lab
   • Share content
   • Access admin menus

ADDITIONAL INFORMATION

• Has associated issue: docs: Add minimal set of permissions required for public dashboards #36025
• Required feature flags:
• Changes UI
• Includes DB Migration
• Introduces new feature or API
• Removes existing feature or API

🤖 Generated with Claude Code

[Parvezkhan0]

Public is given several permissions that Gamma does not have:

can_read → CssTemplate

can_read → SecurityRestApi

can_get → MenuApi

can_get → OpenApi

can_external_metadata_by_name → Datasource

Because of these, public_perm_set - gamma_perm_set is not empty, so test_public_role_more_restrictive_than_gamma will fail. Either remove these permissions from Public or update the test, but both cannot be true at once.

[rusackas]

Thanks for catching that... I'll take 'em out.

[rusackas]

Actually, I added CssTemplate can_read to Gamma :D

[sfirke]

I am really pleased you're taking this on! I went through many comments related to frustrations with everyone who tried to figure this out on their own trial and error. I think this is a huge win for the project!

I shared thoughts and additional info in the comments below.

[sfirke]

I have a Public role in production. I set it up around 2022 so many versions ago. Here I compare this PR's list to the list I'm using, both ways.

An original artifact of the list I used was this gist: https://gist.github.com/byk0t/bd6e9c3839967b4ac28a8da30f468b2a its comments have a couple of useful clues.

Present here but not in my Public role

1. ("can_read", "EmbeddedDashboard") - makes sense to add

It surprises me that my Public role works without having these:
# Datasource metadata for chart rendering
2. ("can_get", "Datasource"),
3. ("can_external_metadata", "Datasource")

Present in my Public role but not this PR

I think we might want to add:

• can annotation json Superset - I would think this is needed for annotations to render on a Public-facing chart?
• can read Annotation - same
• can filter Superset - I don't know how this is different from the filter permissions you have above
• can read ExplorePermalinkRestApi - I think this was for permalinks to charts? I was trying to embed charts in webpages when I started using Superset for public facing.

I'm not sure about these - I have them but it's not obvious to me what they do and I don't remember why I added each:

• can favstar Superset - at least in Superset 1.5.0 this was needed to avoid the error message: "There was an issue fetching the favorite status of this dashboard"
• can get OpenApi
• can list FilterSets
• can queries Superset
• can read AdvancedDataType
• can read ExploreFormDataRestApi,
• can share dashboard Superset
• can slice json Superset
• can sql json Superset
• can validate sql json Superset
• can write DashboardPermalinkRestApi - maybe I had this because of Without "can write on DashboardPermalinkRestApi", a click on a anchor (tabs or header) redirect to login page #30004 which has been fixed?
• can write ExploreFormDataRestApi
• can write ExplorePermalinkRestApi

Probably only a fit for my use case:

• can csv Superset - maybe we note in the docs that if you want the public user to be able to download the data behind a chart, add this?

[rusackas]

Thanks for the thorough review @sfirke! Your feedback was incredibly valuable. I've pushed updates that address your concerns:

Changes Made

1. Config Logic Fix (Critical)

You were right to flag this! The original logic if not public_role_like or public_role_like == "Public" would have enabled the built-in Public role for ALL deployments by default (when PUBLIC_ROLE_LIKE is None).

Fixed: Now the built-in Public role only activates when explicitly set to PUBLIC_ROLE_LIKE = "Public". If unset (None), the Public role remains empty (preserving existing/legacy behavior).

2. Additional Permissions Added

• can_read on Annotation - For annotations on charts to render
• can_read on AnnotationLayerRestApi - For annotation layer metadata
• can_read on ExplorePermalinkRestApi - For chart permalinks (we already had Dashboard permalinks)

3. Documentation Updates

Added important notes covering:

• DASHBOARD_RBAC interaction: When enabled, anonymous users only see dashboards where "Public" role is explicitly added as owner
• Role synchronization: Clarified that permissions sync on startup and manual edits may be overwritten
• Data access requirement: Emphasized that dataset access must still be granted separately

Permissions NOT Added (and why)

• SQL-related permissions (can_queries, can_sql_json, etc.) - Public shouldn't have SQL Lab access
• Write permissions (can_write on permalinks, etc.) - Public should be read-only
• can_favstar - Anonymous users don't need favorites (and the error sfirke mentioned may have been fixed in newer versions)

Let me know if there's anything else you'd like me to adjust!

[rusackas]

Thanks for the thorough review @sfirke - all addressed!

[sfirke]

The content of this PR

Looking sharp! I have two suggestions on the docs, one of which requires you to test something out because I'm not sure what sentence is true there.

Related documentation fixes

I looked for related documentation and it's pretty woeful. Two suggestions:

1. I think this PR should update this section on the Security page about the Public role. suggesting they use Public instead of Gamma.
2. DASHBOARD_RBAC: DASHBOARD_RBAC seems to be pretty much undocumented. The closest thing is "Manage access to Dashboards" on the "Creating your first dashboard" page, which should be moved from "Using Superset" into the "Configuration" section of the docs.

On the Networking page we say it's needed to make a dashboard public:

These are in a circular loop of docs pointer links. The link in this screenshot takes you to the Feature Flags page:

Where there's a link "(docs)" that takes you back to the meager paragraph on the "creating your first dashboard" page:

I think the fix is to make the move I suggested above, from "creating your first dashboard" into the appropriate place in the Configuration documents. Then any/all these references to DASHBOARD_RBAC can point there.

[sfirke]

I've been thinking about this and I think a better recommendation would be:

To customize the permissions assigned to the Public role, make a copy of it via the "Copy Role" option available to admins in the Superset web UI and save it under a different name. Alter it as desired, then edit your config file to point to that copied role, e.g., PUBLIC_ROLE_LIKE = "Public_Custom".

[sfirke]

Wait, about this:

The Public role permissions are synchronized on Superset startup when PUBLIC_ROLE_LIKE = "Public".

Seems inaccurate -- are role permissions synchronized for Gamma, Alpha, etc.? I don't think this is accurate to say they're synchronized on startup when that value is set in the config. Instead either all roles are synchronized on startup (when superset init is run) or none, I would think.

[sfirke]

I think the content of this paragraph and the preceding one are correct, but I might streamline it into one thing. Along the lines of:

"The Public role only grants UI/API permissions. You must also grant access to specific datasets necessary to view a dashboard. As is the case for other roles, this can be done in two ways:

1. With DASHBOARD_RBAC feature flag set to False: <placeholder>. Grant access to specific datasets by editing the Public role in the Superset UI (Menu → Security → List Roles → Public) and adding the relevant data sources.
2. With DASHBOARD_RBAC feature flag set to True: Anonymous users will only see dashboards where the "Public" role has been explicitly added as an owner in the dashboard's properties. There will be no need to grant access to specific datasets, this cascading permissions check is handled by DASHBOARD_RBAC. This provides fine-grained control over which dashboards are publicly visible."

Where it says "placeholder" above I want to add: "the Public role can see all dashboards on the dashboard list. It can load them, but won't be able to see any of the charts without access to their datasets." But I don't know if this is true! Can you test this and fill in the placeholder with a sentence about what dashboards are visible in this case?

[sfirke]

I realized I didn't understand why my current config is working the way I want it. I found a line that seems to depend on a role named "Public"? Seems relevant to this PR. Sorry to generate so much followup!

[sfirke]

I think this needs to get folded into the DASHBOARD_RBAC discussion below. I currently use the Public role with DASHBOARD_RBAC = True and I don't have PUBLIC_ROLE_LIKE in my config and I don't plan to. Instead, I just assign the Public role to dashboards I want public.

I think this section should say you set PUBLIC_ROLE_LIKE = "Public" if you're not using DASHBOARD_RBAC. If you are using DASHBOARD_RBAC and want finer controls, simply grant the Public role to the dashboards you want.

Hold on... how does this work in my current deployment where I don't have PUBLIC_ROLE_LIKE but anonymous users get it assigned anyway?? I think I traced it to this block:

superset/superset/views/utils.py

Lines 107 to 110 in fb6f3fb

	def bootstrap_user_data(user: User, include_perms: bool = False) -> dict[str, Any]:
	if user.is_anonymous:
	payload = {}
	user.roles = (security_manager.find_role("Public"),)

If I'm correct, that's assigning a role called "Public" to anonymous users? That seems brittle, and maybe something to address here.

[sfirke]

I like that we can tell Superset to use a role for anonymous users, but should this be the role defined in PUBLIC_ROLE_LIKE and not hard-coded to "Public" - especially if there's now a stock role and people might want to point it to a customized other one?

[rusackas]

Thanks @sfirke! We'll get this dialed in before merging, obviously!

[codeant-ai-for-open-source]

CodeAnt AI is running Incremental review

---

Thanks for using CodeAnt! 🎉

We're free for open-source projects. if you're enjoying it, help us grow by sharing.

Share on X ·
Reddit ·
LinkedIn

[rusackas]

Thanks for the detailed review! I've pushed updates addressing all the feedback:

Documentation Improvements

Clarified PUBLIC_ROLE_LIKE is optional:

• Anonymous users get the Public role via AUTH_ROLE_PUBLIC (FAB config)
• PUBLIC_ROLE_LIKE only controls what permissions are synced during superset init
• If you're manually configuring permissions or using DASHBOARD_RBAC, you don't need to set it

Consolidated DASHBOARD_RBAC documentation:

• Added a new "Dashboard Access Control" section to security.mdx
• Explains both approaches: dataset-based access (default) vs dashboard-level access (DASHBOARD_RBAC)
• Updated networking-settings.mdx with two clear options for making dashboards public
• Streamlined creating-your-first-dashboard.mdx to link to the consolidated docs

Fixed "Role synchronization" section:

• Corrected: roles sync during superset init, not on startup
• Two options for customization: edit Public role directly (don't set PUBLIC_ROLE_LIKE), or use a custom role with both PUBLIC_ROLE_LIKE and AUTH_ROLE_PUBLIC updated

Streamlined data access explanation:

• Combined the two bullets into one with sub-bullets for with/without DASHBOARD_RBAC
• Without DASHBOARD_RBAC: dashboards only visible if user has access to at least one dataset
• With DASHBOARD_RBAC: dataset permissions not required, cascading check handled automatically

Bug Fix

Fixed hard-coded "Public" role in bootstrap_user_data:

• Changed security_manager.find_role("Public") → security_manager.get_public_role()
• Now respects AUTH_ROLE_PUBLIC config instead of being hard-coded
• This was a pre-existing issue that explains why your setup works without PUBLIC_ROLE_LIKE

[bito-code-review]

Code Review Agent Run #8f0e3a

Actionable Suggestions - 1

• superset/security/manager.py - 1

  • Role Name Inconsistency · Line 1268-1268

Additional Suggestions - 1

• docs/docs/security/security.mdx - 1

  • Doc inaccuracy on DASHBOARD_RBAC · Line 146-148
    The documentation claims that DASHBOARD_RBAC bypasses dataset-level checks and implicitly grants access to all charts and datasets in the dashboard. However, a GitHub issue (#31938) reports that this may not work as intended, potentially still requiring explicit dataset permissions. Consider updating to reflect this limitation or noting that users should verify the behavior.

Review Details

• Files reviewed - 9 · Commit Range: 07fd30f..cc7c30e

  • docs/docs/configuration/networking-settings.mdx
  • docs/docs/security/security.mdx
  • docs/docs/using-superset/creating-your-first-dashboard.mdx
  • pyproject.toml
  • superset/security/manager.py
  • superset/views/utils.py
  • tests/integration_tests/fixtures/__init__.py
  • tests/integration_tests/fixtures/public_role.py
  • tests/integration_tests/security_tests.py
• Files skipped - 1

  • RESOURCES/STANDARD_ROLES.md - Reason: Filter setting
• Tools

  • Whispers (Secret Scanner) - ✔︎ Successful
  • Detect-secrets (Secret Scanner) - ✔︎ Successful
  • MyPy (Static Code Analysis) - ✔︎ Successful
  • Astral Ruff (Static Code Analysis) - ✔︎ Successful

---

Bito Usage Guide

Commands

Type the following command in the pull request comment and save the comment.

• /review - Manually triggers a full AI review.

• /pause - Pauses automatic reviews on this pull request.

• /resume - Resumes automatic reviews.

• /resolve - Marks all Bito-posted review comments as resolved.

• /abort - Cancels all in-progress reviews.

Refer to the documentation for additional commands.

Configuration

This repository uses Superset You can customize the agent settings here or contact your Bito workspace admin at evan@preset.io.

Documentation & Help

• Customize agent settings
• Review rules
• General documentation
• FAQ

AI Code Review powered by

[bito-code-review]

Role Name Inconsistency

The set_role call uses a hardcoded "Public" string, but to match the AUTH_ROLE_PUBLIC config (which defaults to "Public" but can be customized), it should use self.auth_role_public. This ensures consistency, as the copy_role in the elif branch correctly uses self.auth_role_public.

Citations

• Rule Violated: AGENTS.md:86

Code Review Run #8f0e3a

---

Should Bito avoid suggestions like this for future reviews? (Manage Rules)

• Yes, avoid them