Apache Superset Keycloak Integration
An apache superset keycloak integration links your analytics app to your central identity provider. You set up an OpenID Connect client in Keycloak and map roles in Superset. Most data teams build this link to centralize user logins and group roles. Still, broad role mappings often give users too much power over production data. Once a user logs in, they can run wide queries across connected databases. How an apache superset keycloak integration works Superset relies on Flask AppBuilder to ha
Keycloak: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An apache superset keycloak integration links your analytics app to your central identity provider. You set up an OpenID Connect client in Keycloak and map roles in Superset. Most data teams build this link to centralize user logins and group roles. Still, broad role mappings often give users too much power over production data. Once a user logs in, they can run wide queries across connected databases.
How an apache superset keycloak integration works
Superset relies on Flask AppBuilder to handle user logins and role checks. You start by creating a dedicated client inside your Keycloak realm. This client holds the secret key and redirect links for your analytics app. Next, you update the Superset setup file to use OpenID Connect for logins. You point the app to the Keycloak realm endpoints for tokens and user info.
When a team member opens Superset, the app sends them to Keycloak. Keycloak checks their password and two-factor code against your central user directory. After a good login, Keycloak sends a signed token back to Superset. This token carries the user email, name, and assigned Keycloak group names. Superset reads these group names and matches them to internal app roles.
A custom security manager in Superset translates Keycloak roles into local database rights. For example, a finance group in Keycloak maps to a finance role in Superset. That role decides which dashboards, charts, and data sources the user can open. Admins manage group memberships in Keycloak instead of editing single users in Superset. When someone leaves the team, revoking their Keycloak account blocks their Superset login.
What native role mapping solves and what it misses
Centralizing logins in Keycloak solves account sprawl across your analytics tools. You enforce strong passwords and multi-factor rules in one single place. Admins do not need to create or delete accounts inside Superset by hand. Role mapping also keeps dashboard permissions tied to your main team directory. This works well for basic view rules on pre-built charts and reports.
Still, identity setup only decides who can log into the web app. It does not inspect or limit the raw SQL queries running in flight. Superset connects to your backend databases using a single shared service account. Every query from SQL Lab runs under that same database user credential. Your database logs only show the shared Superset account, not the Keycloak user.
Keycloak: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
If an analyst gets SQL Lab access, they can query raw tables. Native Superset roles do not mask sensitive fields in custom SQL results. Exposed columns like emails, phone numbers, card numbers, or national IDs return in plain text. You need controls at the database layer to inspect queries and rewrite results.
Best practices for managing analytics roles and data
Keep your Keycloak groups narrow and tied to specific job tasks. Do not map a default company group to an admin role in Superset. Separate dashboard viewers from power users who run raw queries in SQL Lab. Most team members only need to view charts, not write custom SQL.
Sync roles on every login so group changes take effect right away. Test your role mappings in a staging realm before updating production settings. Audit which database accounts Superset uses to read your core data tables. Give those database accounts read-only rights on the specific schemas needed for charts. Combine identity checks with query-level controls to protect sensitive customer records during analysis.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How does Superset map Keycloak groups to internal roles?
Keycloak sends user group names inside the login token claims. Superset reads those claims during login and matches them to local role names. You can enable role syncing on every login to keep permissions fresh.
Can users still log in with local Superset accounts after setup?
When you switch Superset to OpenID Connect, the login page uses Keycloak. Local database accounts in Superset are bypassed during the normal web login flow. Admins manage all user passwords and access inside Keycloak instead.
Does Keycloak restrict which SQL queries a user can run in SQL Lab?
No, Keycloak only handles the login step and passes group names to Superset. Once inside SQL Lab, the user runs queries through Superset's shared database credentials. You need database-level controls to block risky statements or mask fields like emails.