How to Set Up Keycloak SSO for Apache Superset (OpenID Connect)

When organisations need full control over identity, Keycloak is a natural fit—whether for on-premise

deployments, regulated environments, multiple upstream directories, or an entirely open-source stack.

Apache Superset fits right in, with Flask-AppBuilder providing a built-in Keycloak handler that makes

integration a configuration task, not a coding project.

But there’s one silent trap to watch for. 🔍 Keycloak’s default client configuration doesn’t include the groups claim that FAB uses to map users to Superset roles. The result? Logins succeed, but everyone gets the default role. No obvious error—just incorrect access.

This guide fixes that in Step 1, before it catches you off guard.

Already familiar with Superset SSO? Our Okta guide covers the shared essentials, including authentication, reverse-proxy settings, and break-glass access. Here, we focus exclusively on what makes Keycloak integration different.

Tested with Superset 4.x and Keycloak 24, with compatibility for Keycloak 17 and later—the versions that no longer use the /auth URL prefix.

Read The Complete Technical Guide

How to Set Up Microsoft Entra ID (Azure AD) SSO for Apache Superset

 

Apache Superset SSO with Microsoft Entra ID

If your organisation uses Microsoft 365, Microsoft Entra ID (formerly Azure Active Directory) already manages employee identities and access. Integrating Superset with Entra ID lets you centralise authentication instead of maintaining separate passwords. Flask-AppBuilder provides a built-in Azure OAuth handler, making configuration possible without custom code.

This guide complements our Okta SSO guide, focusing on Entra-specific app registration, role mapping, and common authentication errors. General authentication mechanics, reverse-proxy settings, and break-glass procedures remain unchanged.

The configuration covers Apache Superset 2.1 through 4.x, with examples based on version 4.x.

Groups or app roles?

Entra can put either the user’s group memberships or their app roles into the token. Flask-AppBuilder’s Azure handler reads the roles claim, which is app roles, and uses it as the list of keys to match against AUTH_ROLES_MAPPING.

App roles are also the better design for Superset:

• No overage problem. Entra stops emitting the groups claim when a user is in more than a couple of hundred groups and replaces it with an overage indicator. Large organisations hit this routinely. App roles are specific to your application and never overflow.

• Assignment lives on the application. You assign a group or a user to an app role in the Superset enterprise application. The Entra admin sees exactly who can reach Superset and as what, without decoding group names.

• Role names are yours. Superset.Admin, Superset.Analyst, Superset. Viewer are clearer than a security group created five years ago for something else.

So this guide uses app roles. If you must use groups, the section near the end explains what to change.

Curious How It Works? →

Superset RBAC Design for a 500-User Enterprise: Roles, Data Access and Dashboard Permissions

 

Apache Superset Permissions: Smarter Access Control -

Apache Superset offers flexible permissions, but default role configurations often lead to excessive

privileges and manual dataset access management.This guide explores scalable permission design for

multi-department deployments in Superset 3.x and 4.x.

Understanding Superset Permissions

Superset uses Flask-AppBuilder’s security model, built on three concepts:

Permission: Actions such as can_read, can_write, can_export, and schema_access.

View Menu: The resource being accessed, such as a Dashboard, Chart, Dataset, or SQL Lab.

Permission View: The combination of an action and a resource, grouped into roles assigned to users.

Key principles: Roles are composable, combining capabilities and data access, but there is no deny

override—any role granting dataset access makes that access available.

Dataset vs. Schema Permissions

Superset creates dataset-specific permissions automatically, expanding the permission list as the catalogue grows.

Schema-level schema_access provides a scalable alternative, covering all current and future datasets

within a schema.

Explore What’s Possible →

Multi-Tenant Row-Level Security in Embedded Superset: Three Patterns and When Each Fails

Embedding a Superset dashboard is easy. Making sure each tenant sees only its own data—across every

chart, filter, drill-down, and cached result—is where things get serious. A weak tenant boundary can turn

embedded analytics into a security incident.

Superset supports three main approaches to enforce tenant isolation: RLS clauses in guest tokens, Superset RLS rules using Jinja and token attributes, and separate schemas or databases for each tenant. Each approach works differently and has specific limitations.

This guide breaks down all three patterns, explains where each can fail, and shows how they can be combined for stronger isolation. It also includes a practical test plan to help you verify tenant isolation instead of simply assuming it works.

Your Complete Guide Starts Here →

Superset Plugin Compatibility: What Breaks Between 3.x and 4.x and How to Migrate a Plugin

 

A custom chart plugin is compiled into the Superset frontend bundle. That is what makes it fast and

first- class, but it is also why a Superset upgrade can break it: the plugin is built against specific

versions of @superset-ui/core, @superset-ui/chart-controls, and related frontend APIs.

The jump from 3.x to 4.x changed enough that some plugins need more than a simple rebuild—they

may require updates to dependencies, APIs, query handling, or TypeScript code.

This guide is the practical checklist we use when migrating a custom plugin from Superset 3.x to 4.x. It covers the key compatibility checks across index.ts, buildQuery.ts, controlPanel.ts, transformProps.ts, and the React visualization component, along with plugin registration in MainPreset.js. The goal is simple: identify what changed, update only what is necessary, rebuild cleanly, and verify the plugin in Explore and dashboards.

One caveat up front: the exact breaking changes depend on the two Superset versions you are moving between. Always check UPDATING.md and the release notes for every version between your current release and the target. This guide highlights the most important compatibility issues to check when crossing the 3.x to 4.x line.

Explore the Details →

How to Set Up Okta Single Sign-On for Apache Superset

Password logins are the first thing an auditor asks about and the last thing anyone wants to manage by hand. If your team already uses Okta for everything else, Superset should not be the exception: one identity, one place to offboard, and roles that follow the person rather than the login.

Apache Superset supports this out of the box through Flask-AppBuilder (FAB), the framework Superset is built on. The pieces are all there. What is missing is a single, current walkthrough that covers the Okta side, the Superset side, the role mapping, and the handful of reverse-proxy and cookie settings that turn a working configuration into a redirect loop. This is that walkthrough.

By the end, you will have:

•  Okta as the only login path for Superset, with the local password form gone.

•  Users created automatically on first login, with their Okta groups mapped to Superset roles.

•  Role changes in Okta reflected in Superset at next login.

•  A troubleshooting table for the errors this setup produces in practice.

The configuration shown here applies to Superset 2.1 through 4.x. The examples were written against Superset 4.x with the Flask-AppBuilder 4 series it ships with.

See It in Action →

How to Build a Custom Chart Plugin for Apache Superset 4.x

Apache Superset ships with more than fifty chart types, and for most dashboards, that is plenty. But what happens when you need something more specific—a bullet chart against a target band, a Sankey with a custom node order, a map layer the built-in deck.gl charts do not offer, or a KPI tile that colours itself against three thresholds instead of one?

At that point, you have two options: bend an existing chart until it almost fits, or build a plugin that fits your needs. Plugins are how Superset itself is built.

Every chart in the Explore view, from the humble table to the ECharts time series, is a plugin registered through the same ChartPlugin API you are about to use. A custom plugin is not second-class. It gets the same query layer, the same control panel framework, the same dashboard filters and cross-filters, and the same theming.

This guide builds a small but complete plugin for Superset 4.x. The chart is deliberately simple: a bar per category with a configurable highlight threshold, keeping the focus on the plugin mechanics. Once the plumbing is in place, swap the rendering for ECharts, D3, or deck.gl.

Explore the Complete Guide →