Apache Superset Keycloak
You set up apache superset keycloak by linking both apps with OpenID Connect. This link lets your team log in to charts with one shared account. Most teams map group names from the login tool to chart roles. If those roles are too broad, users can read tables they should not touch. How the apache superset keycloak flow works The sign-in flow starts when a user opens the chart app. The chart app sends the browser to your login server. The user types a name and password on that login page. Your
Keycloak: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up apache superset keycloak by linking both apps with OpenID Connect. This link lets your team log in to charts with one shared account. Most teams map group names from the login tool to chart roles. If those roles are too broad, users can read tables they should not touch.
How the apache superset keycloak flow works
The sign-in flow starts when a user opens the chart app. The chart app sends the browser to your login server. The user types a name and password on that login page. Your login server checks the user and sends back a signed token.
That token holds the user email, name, and group list. The chart app reads the token and creates a local user profile. Next, the chart app matches the token groups to its own role list. A user in a data group gets an analyst role right away.
To make this work, admins create a client record in the login server. They set the return URL so the browser goes back to the right page. Then they update the chart app settings file to trust the login server. They also turn on role sync so group changes update on each sign-in.
How role mapping shapes data permissions
Inside the chart app, roles control what screens and menus a user sees. An admin role lets a user add data sources and change system rules. An alpha role lets a user read all added data sources and build charts. A gamma role blocks all data sources until an admin shares specific views.
When you link groups from your login tool, you pick which role fits best. Many teams map a whole department to the alpha role to save time. That choice skips the hard work of building small, strict role lists. It also means every person in that group shares the exact same data rights.
The chart app connects to your databases with one shared service account. When a user runs a chart, the app sends SQL through that single account. The database sees the chart app account, not the single person who logged in. Your login server knows who signed in, but the database does not know.
Keycloak: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native sign-in solves and what it misses
Linking these two tools solves the problem of scattered passwords across your team. When someone leaves the company, you turn off their account in one place. They lose chart login rights right away without extra manual cleanup work. You also get multi-factor checks if your login server enforces them.
Still, this setup only checks who enters the front door of the app. It does not check what individual SQL queries do once the user is inside. If you turn on the SQL editor, users can write custom queries against tables. A user with broad role rights can query raw customer tables at any time.
Native role sync cannot rewrite query results to hide sensitive text in flight. If a table holds emails, phone numbers, or card numbers, the query returns them. The chart app shows those raw values on the screen to the user. Admins also struggle to match a slow database query back to one user.
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 do I sync groups to chart roles on every login?
You enable role sync in the chart app settings and map group names. Each time a user logs in, the app reads their token and updates roles.
Why do users get a redirect error during sign-in?
This happens when the return URL in the login server does not match. Check that both tools use the exact same web address and protocol.
Does the login server filter rows inside my database tables?
No, the login server only handles sign-in and sends basic group names. You must set up row rules inside the chart app or at the database layer.