Technical Tutorials

As data analytics becomes increasingly distributed across departments and external partners, exposing a single, monolithic dashboard to everyone is no longer viable. Apache Superset is a powerful, open-source data exploration platform, but its default security model is often too permissive for complex, multi-tenant environments. To scale effectively, organizations must enforce strict data boundaries and unify identity management. This guide walks you through the technical implementation of Row-Level Security (RLS) and Single Sign-On (SSO) integration, ensuring that each tenant sees only what they are authorized to access.

Understanding Multi-Tenant Security Requirements

In a multi-tenant setup, "tenant" can refer to different departments within a company or entirely different external clients. The core security challenge is preventing data leakage between these groups. While Superset provides role-based access control (RBAC) to manage *who* can access specific dashboards, it does not automatically restrict *which rows* of data those users can see within a shared database. This is where RLS becomes critical. Combined with SSO, you create a unified identity layer that propagates user attributes into security contexts, allowing for dynamic, attribute-based access control.

Implementing Row-Level Security (RLS)

RLS in Superset is implemented via filters that are automatically appended to SQL queries based on the user's group or claims. These filters are defined using Jinja templating, allowing them to be dynamic based on user attributes provided during authentication.

For example, if you are using an LDAP or SAML provider that includes a `department` attribute, you can create an RLS policy that restricts users to their own department's data. The following example demonstrates how to configure a dynamic RLS filter for a `sales` table:

# In the Superset UI: Settings > Listeners > RLS Policies
# Policy Name: Tenant_Only_Sales_Data
# Table: sales
# Filter Template:
region == "{{ user.attrs['region'] }}"

This ensures that when a user logs in with `region: 'APAC'`, the generated SQL query automatically appends `WHERE region = 'APAC'`, isolating their view. To manage these policies programmatically or in large environments, you can use the Superset REST API:

import requests
import json

# Configuration
BASE_URL = "http://your-superset-instance/api/v1"
HEADERS = {"Authorization": "Bearer ", "Content-Type": "application/json"}

# Define the RLS Policy
rls_policy = {
    "filter": "region == \"{{ user.attrs['region'] }}\"",
    "table_id": 42,  # ID of the 'sales' table
    "name": "Tenant Region Lock",
    "roles": [1, 5]  # IDs of the roles this policy applies to
}

# Create the policy
response = requests.post(f"{BASE_URL}/row_level_security", data=json.dumps(rls_policy), headers=HEADERS)
print(response.json())

Integrating SSO for Unified Identity

SSO integration is not just about convenience; it is the backbone of secure multi-tenancy. By integrating Superset with an Identity Provider (IdP) like Okta, Azure AD, or Auth0 via SAML2 or OpenID Connect, you centralize authentication. More importantly, you can map IdP attributes (groups, email domains, custom claims) to Superset roles and RLS contexts.

For instance, using the `superset` configuration file (`superset_config.py`), you can enforce that only users with the `superset-admin` claim in their IdP token can access the admin interface:

import os
from superset.extensions import db
from flask import g

class SupersetConfig:
    # SAML Configuration Example
    SAMLP = {
        "SAML_PATH": os.environ.get("SAML_PATH", "/saml"),
        "IDP_METADATA_PATH": os.environ.get("IDP_METADATA_PATH", "/path/to/idp.xml"),
        "SP_NAME": "Superset-Analytics",
        "SP_ENTITY_ID": "https://analytics.company.com",
        "SAML_ENABLED": True,
    }

    # Custom login required to enforce MFA or specific claims
    @staticmethod
    def login_required():
        # This hook can be extended to validate specific claims
        if not g.user:
            return False
        # Example: Block users from specific domains in production
        if g.user.email and g.user.email.endswith('@test.com'):
            raise Exception("Test accounts are blocked in production")
        return True

    # Map IdP Groups to Superset Roles
    @staticmethod
    def map_login_user(user, attrs):
        # 'attrs' contains the claims from the SSO token
        if 'data-analyst' in attrs.get('groups', []):
            # Dynamically assign roles based on IdP groups
            pass
        return user

Testing and Validation

Before deploying this configuration to production, it is critical to validate the RLS logic. Superset’s "SQL Lab" is an excellent tool for this, as it shows the generated query string. When executing a query as a test user, verify that the RLS filters are being injected correctly into the `WHERE` clause. Additionally, test with edge cases: users without the specific attribute, users belonging to multiple groups, and expired SSO sessions.

Conclusion

Securing Apache Superset for multi-tenant analytics requires a two-pronged approach: enforcing data isolation through Row-Level Security and centralizing trust through SSO. By leveraging dynamic RLS filters driven by SSO attributes, you create a scalable, auditable, and secure environment. This architecture not only protects sensitive data but also simplifies user management, allowing administrators to manage access through their existing Identity Provider rather than maintaining separate Superset user records. As your organization grows, this foundational security model ensures that your analytics platform remains both powerful and compliant.