Superset - Clarification regarding support for multiple tenants

[user1500177]

I am using superste version 6.0.0 (ready to upgrade to later stable versions if needed) , is there a concept in superset which make the app to support multiple tenants ?

We have a platform where a single user can belong to and switch context between multiple client organizations (e.g., switching between Organization A and Organization B via a dropdown or application state).When a user is acting within the context of "Organization A", they should only see dashboards and data relevant to Organization A.
Out of 10available dashboards, 9 are global/common across all organizations.1 dashboard is hyper-specific to Organization A and should only be visible when the user's active context is set to Organization A.

What i looked into :

RLS is enabled so only the specific customer data at a time the charts and dashboards would be showing , when user chages between multiple customer , but as said some dashboards are specifically made for a customer organization - so in that case when the user is in that context only i need him to see that dashbord or chart. (The RLS is already enabled.)

I looked into using User Group-based Access Control and DASHBOARD_RBAC. While I could create a static group/role per organization and assign users to them, it does not fully solve our problem because a single user belongs to multiple organizations at the same time.If we give them all roles statically, they see everything simultaneously, ruining the specific organizational context we need to isolate

.My Questions to the Community:Is there an out-of-the-box or native feature in Superset 6.0.0/ later versions that allows passing or setting an active organizational/customer context dynamically at the user session level?

[dosubot[bot]]

This is essentially the same question you asked in discussion #42242, and the core answer hasn't changed: Superset does not have a native "active organizational context" concept that dynamically shows/hides dashboards based on a session-level tenant switch. However, you can get close by combining features you're already using.

The gap you've identified is real: RLS filters data inside charts but doesn't control dashboard visibility. And DASHBOARD_RBAC controls dashboard visibility but works via static role assignments — it doesn't understand a dynamic "active context" [1].

What can work today:

1. Per-customer roles + DASHBOARD_RBAC — Create a role per organization (e.g., org_a_role, org_b_role). Assign each role only to the dashboards that organization should see. Common dashboards get all roles; org-specific dashboards get only their org's role. When DASHBOARD_RBAC is enabled and a dashboard has roles assigned, only users with a matching role can see it [1].

2. The multi-role problem you described — Yes, if a user has both org_a_role and org_b_role simultaneously, they see everything from both. Superset has no mechanism to "activate" only one role at a time per session. To work around this, your application layer would need to dynamically manage role assignments (add/remove the active org's role via the PUT /api/v1/security/role/{pk}/ API when the user switches context). This is non-trivial but doable with automation.

3. Embedded Superset approach (more elegant) — If you can embed dashboards, guest tokens solve this cleanly. When the user switches to Organization A, your backend issues a guest token scoped to only Organization A's dashboard UUIDs + RLS rules. The user literally cannot see or access dashboards not listed in the token [2]. This is the pattern most multi-tenant Superset deployments use.

4. Upcoming: Subject model (PR feat: introduce Subject model and entity editors/viewers #38831) — An open PR introduces user groups as first-class access subjects with a viewers concept. This would let you assign groups (rather than roles) to dashboards, but it still doesn't add a dynamic "active context" switch natively [1].

Bottom line: There's no out-of-the-box session-level org context in Superset 6.0.0 (or later). The cleanest path is the embedded guest token approach, where your platform backend controls which dashboards and RLS rules each token grants. If embedding isn't an option, you'd need to build the context-switching logic in your application layer by dynamically managing role assignments via the API. As @rusackas mentioned in your earlier thread, multi-tenancy in open-source Superset is doable but non-trivial.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[FrancescoCastaldi]

In Apache Superset 6.x, multi-tenancy where a single user dynamically switches organization context is achieved through one of two proven architectures:

Architecture 1: Embedded SDK with Scoped Guest Tokens (Recommended)

If users access Superset embedded inside your host application portal, the host application manages the active organization context.
When the user switches organizations in your application's dropdown:

1. Your backend issues a guest token (/api/v1/security/guest_token/) scoped specifically to:
   • The active dashboard IDs allowed for that organization.
   • An explicit Row Level Security (RLS) clause restricting data queries to that organization:

   {
     "user": {"username": "john.doe", "first_name": "John", "last_name": "Doe"},
     "resources": [{"type": "dashboard", "id": "<dashboard_uuid>"}],
     "rls": [{"clause": "organization_id = 'ORG_A'"}]
   }

2. Your frontend calls embedDashboard() with the new token.
3. Dashboards and data from other organizations remain completely inaccessible, and context switches happen seamlessly without modifying global user roles.

Architecture 2: Custom Security Manager with Dynamic Session Context (Standalone UI)

If users log directly into the standalone Superset web interface:
Superset does not have an out-of-the-box organization switcher in its top navbar, but its security layer is fully extensible via CUSTOM_SECURITY_MANAGER in superset_config.py.

1. Store Active Context in Flask Session:
   Implement a custom view or API endpoint /set_tenant/<org_id> that stores session["active_tenant_id"] = org_id.

2. Dynamic RLS Filter Injection:
   In superset_config.py, write a custom Jinja macro that injects the active tenant ID into dataset queries:

# In superset_config.py
from flask import session

def get_active_tenant():
    return session.get("active_tenant_id", "DEFAULT_ORG")

JINJA_CONTEXT_ADDONS = {
    "current_tenant": get_active_tenant
}

In your datasets, add a filter clause:

organization_id = '{{ current_tenant() }}'

3. Dashboard Visibility via DASHBOARD_RBAC:
   Enable DASHBOARD_RBAC: True in FEATURE_FLAGS. For the 1 dashboard specific to Organization A, assign a dedicated role Role_Org_A. In your custom security manager, dynamically append Role_Org_A to g.user.roles only when session["active_tenant_id"] == "Org_A".