How Apache Superset SSO decides who signs in and what they can see
If you are replacing local Superset accounts with corporate sign-in, the work comes down to two decisions: how Superset authenticates users, and how the groups your identity provider issues become Superset roles. Superset is built on Flask-AppBuilder, and SSO is configured through that framework's settings in superset_config.py. You can connect OAuth2 or OpenID Connect providers, LDAP directories, or remote user headers set by a reverse proxy. Access control happens in the group-to-role mapping defined by AUTH_ROLES_MAPPING, so that mapping deserves as much review as the login flow itself.
This is harder than it looks because the two halves fail differently. A user can complete sign-in successfully and still land with the wrong role, or with no role that lets them see the dashboards they need. Superset stores users, roles and their assignments in the metadata database, so a sign-in does not reset or re-derive permissions on its own unless your configuration tells it to. A mapping that drops a group name, misspells a role, or maps an admin group too broadly can grant or remove access without any error in the logs. Test each mapping with accounts from every group you expect to see, and confirm the resulting roles in the Superset interface rather than assuming the configuration did what it says.
Teams usually need this level of control when they operate in regulated environments, when joiner, mover and leaver processes depend on the identity provider, or when auditors ask who could see which data and why. In those cases, the identity provider should be the single source of truth for membership, and Superset should reflect it predictably. Ask your identity team which groups already exist, who owns them, and how quickly removals in the directory must take effect in Superset. Those answers determine whether you need a scheduled role sync, a stricter session lifetime, or a manual review step. Note that DeployOpen prepares configuration and evidence for compliance assessments but does not issue audit reports or certifications.
Before go-live, agree on a short list of decisions: the protocol for each user population, the attribute that carries group membership, the default role for a first sign-in, and who may change the mapping after deployment. Changes to the mapping should go through the same review and staging test you apply to Superset upgrades, because a single edited line can change what hundreds of users see. Confirm with your provider exactly which claims or attributes it returns, since group claims are often optional or limited in size, and verify the behavior against your own tenant rather than a sample.
Which Superset settings and components carry identity
Login and access in Superset are decided by a small set of components and settings that sit between your identity provider and the metadata database. Knowing which piece reads which setting, and where a user's role actually gets stored, is the starting point for any SSO design.
Flask and React application
Superset is a Flask application with a React front end, and both are served from the same web tier. Every login, session and permission check passes through this application, so it is the component your identity provider must reach over HTTPS. Confirm which callback URLs your chosen provider needs for the version you deploy, because the redirect path is set by the application and must match exactly.
Metadata database user and role tables
Superset stores its users, roles and the assignments between them in the metadata database. Even when a provider authenticates the user, a local user record is created or updated there, and that record drives what the user can open. Plan for the metadata database as the place where identity state persists, and confirm the supported PostgreSQL and MySQL versions for your release before you design around it.
Flask-AppBuilder authentication layer
Superset is built on Flask-AppBuilder, and that layer reads the authentication settings at startup and applies them to every request. It decides how users authenticate and how group claims or directory memberships become Superset roles. Changes to authentication configuration usually require a restart, so test each change in staging before it reaches production.
Authentication type and provider definitions
The authentication type setting selects the method, such as database, OAuth, LDAP or remote user. OAuth providers are defined in a separate configuration block with client credentials, endpoints and scopes for each provider. Confirm the exact setting names and provider options against the Configuring Superset documentation for your target version, because they differ between releases.
LDAP and remote user settings
LDAP connection settings cover the server, bind account, search base and user attributes Superset uses to find a directory entry. The remote user header setting trusts a header injected by a reverse proxy after it has authenticated the user. The remote user option is only safe when the proxy strips that header from external requests, so verify that behavior in your own network before enabling it.
AUTH_ROLES_MAPPING and role names
AUTH_ROLES_MAPPING translates group claims or directory groups from the identity provider into Superset role names. The mapping only works when the role names on each side match what Superset expects, and unmapped groups receive no access. Review the mapping with your access model owner, and confirm the mapping behavior and role name requirements for your version in the Configuring Superset documentation.
Choosing between OAuth2, OIDC, LDAP and remote user headers
This table compares the four ways Superset can authenticate users and what each one asks your team to run and maintain. Read each row against your existing identity stack, since the cheapest option is usually the one that reuses a directory or gateway you already operate. The main takeaway is that every method moves trust somewhere: to an identity provider, a directory service account, a proxy, or a local password you must still manage.
| Option | When it fits | Operational cost and who maintains it |
|---|---|---|
| OAuth2 or OIDC with a corporate identity provider | Your organization already runs a cloud identity provider that issues group claims and supports the authorization code flow, such as Google or Azure as Superset's documented examples. | Platform or identity team registers the Superset application, manages client secrets and redirect URIs, and maintains group claims. Superset team maps claims to roles through AUTH_ROLES_MAPPING and tests logins after each change. |
| LDAP or Active Directory bind | Users and groups live in an on-premises directory, and no modern identity provider sits in front of it. | Directory team provides a bind account with read-only scope and maintains its password rotation. Platform team manages TLS trust to the directory, searches for user and group entries, and tests failover to each domain controller. |
| Remote user headers from a reverse proxy or gateway | A gateway or proxy already authenticates users and passes an identity header, and no direct login to Superset is required. | Gateway team owns authentication and must strip client-supplied identity headers. Platform team must restrict Superset so it only accepts traffic from the proxy. Any misconfiguration lets a user impersonate another, so the trust boundary needs testing. |
| Local accounts managed in Superset | Small pilots, air-gapped environments without a directory, or emergency access when SSO is unavailable. | Superset administrators create, disable and review accounts by hand. Password policy, offboarding and access reviews fall to the owning team, and those steps recur for every user who joins or leaves. |
| Primary SSO with a documented local administrator fallback | You want SSO for daily use but need a way in if the identity provider or directory is down or misconfigured. | Fallback accounts need a strong credential stored under dual control, a named owner, and periodic testing. The trade-off is that each fallback account is a standing login that bypasses your primary controls and must be monitored and reviewed. |
| Group to role mapping through AUTH_ROLES_MAPPING | Your access model already groups people by team or function in the directory or identity provider. | Superset team writes and reviews the mapping. Identity team keeps group names stable, since a renamed group silently removes access. Confirm the exact mapping keys and behavior for your Superset version before relying on them. |
| Certificate and TLS trust | Any option that calls an external identity service or directory over the network. | Platform team installs and renews certificates or the internal certificate authority chain used by Superset. Expired or untrusted certificates cause login failures that often look like application errors. |
| Session and user lifecycle | Users change roles, leave the company, or need access removed quickly. | Identity team controls deprovisioning at the source. Superset may keep local user records after SSO removal, so confirm how your chosen method handles deactivation and plan a recurring access review. |
How AUTH_ROLES_MAPPING turns directory groups into Superset roles
AUTH_ROLES_MAPPING is the point where your directory's group memberships become Superset permissions. The identity provider or directory sends the user's group membership with the login, Superset compares those group names against the mapping dictionary, and every matched Superset role is assigned to the user for that session. Nothing in the chain is a manual grant inside Superset, so the quality of the result depends on the group names your identity team issues and on the mapping you write against them. Treat the mapping as a security control with an owner, not as a convenience setting.
Two behaviors follow from the model and should shape how you run it. First, roles are refreshed at login rather than granted once. A user moved out of a group receives the change on the next sign-in, not at the moment the directory changes, so you should confirm with your identity team how long existing sessions remain valid and whether session lifetimes match your access review cycle. Second, removing a user from every mapped group does not necessarily remove all of their Superset access. Roles that were assigned by hand in the Superset user interface, or by an earlier mapping, can remain on the account. Ask your Superset administrators to list any roles held outside the mapping for each user as part of cutover testing, and confirm the exact refresh behavior for your Superset version and chosen authentication method against the Superset configuration documentation.
The design work happens before the first mapping is written. Agree a group naming scheme with the identity team so that each group name states the application, the environment and the role it grants, for example a group naming convention that separates production from staging. Keep the role model simple: a small set of business-level roles that map cleanly to groups is easier to review and audit than one group per dashboard. Decide in advance which built-in Superset roles administrators must never receive through mapping, such as the Admin role, and enforce that by review rather than by trust in the directory. Administrative access should come from a deliberately small, separately approved group.
Document every mapping in version control. The mapping file, the group names it references, the owner of each group and the reason each role is granted should live in a repository with reviewed changes, so that a change to access is traceable to a request and an approver. This also lets you rebuild the mapping in a new environment and compare it against production during upgrades. Ask your implementation partner to deliver the mapping as a reviewed artifact with tests that confirm which roles each sample group receives, and confirm that your identity provider can produce the group claims Superset expects in staging before anything reaches production.
The role model itself is designed in the implementation plan topic, which covers how Superset roles and data access are structured for your rollout. If your identity integration needs custom logic beyond the standard mapping, such as transforming group names or handling roles that the standard path cannot express, that work is covered in the customization topic, where custom security manager changes are discussed with upgrade implications. This section assumes the role model is settled and focuses on how the mapping is built, refreshed and governed.
Configuring Apache Superset SSO step by step
This sequence takes Superset from an agreed login design to a production configuration that maps identity groups to Superset roles. Each step ends with a check you can record, so a failed login or a wrong role is caught in staging before any user depends on it. The output is a tested SSO configuration, a documented local fallback path and a rollback plan for production.
Agree the login method and group model
The identity team and the Superset owner decide which protocol applies: OAuth2 or OIDC with a provider such as Google or Azure, a custom OAuth2 server using the code flow, LDAP, or remote user headers passed by a reverse proxy. They also agree which directory or provider groups exist, which of them grant Superset access, and which Superset role each one should receive. Record this as a short table. The step is done when both teams sign the table and every group in it has a named owner who approves membership changes.
Register the application or confirm directory access
For OAuth2 or OIDC, register Superset as an application with the identity provider and store the client secret in your secrets manager. For LDAP, confirm the bind service account, its read-only permissions, the search base and the attribute that carries group membership. Confirm the Superset host name that the callback will use. The step is done when a directory or provider administrator confirms the registration in writing and a test lookup returns the expected user and group membership.
Set redirect URIs or directory settings in staging
Stand up a staging Superset instance with its own host name, separate from production. Register its callback address with the provider, or point the LDAP settings at a staging directory or test tenant. Keep staging and production redirect URIs separate so that a staging sign-in cannot be replayed against production. The step is done when the provider accepts a sign-in attempt from the staging host and the response returns to Superset without error.
Configure authentication and keep secrets out of source
Set the authentication type and provider definitions in the Superset configuration file or environment, following the Flask-AppBuilder settings in the configuration documentation for your chosen method. Load client secrets, the LDAP bind password and the SECRET_KEY from a secrets manager or injected environment variables, and keep them out of version control. Superset requires a user-specified SECRET_KEY to start. The step is done when Superset starts cleanly, the login page offers the expected provider and a scan of the repository finds no credentials.
Define AUTH_ROLES_MAPPING from agreed groups
Translate the signed group table into AUTH_ROLES_MAPPING, mapping each group name exactly as the provider or directory emits it to one or more Superset roles. Check spelling, case and any prefix character by character, because a small mismatch can leave a user with no role. Keep the mapping in the same managed configuration as the other settings. The step is done when a review of the mapping against the table shows no group that should have access is missing and no role is granted without an owner.
Test one account per group in staging
Sign in with one test account from each group in the table. Add one account from a group that is not mapped and one account with no group membership at all. For each sign-in, record the role list shown on the Superset user record and compare it with the mapping. Confirm how Superset treats an account with no mapped role under your settings. The step is done when every test account receives the expected roles, the unmapped accounts get the agreed result and each attempt appears in the logs.
Verify role removal and test the fallback
Remove a test account from a mapped group in the directory, then sign in again and confirm the role list no longer includes the removed role. Confirm how long an existing session stays valid under your settings, since access may persist until the session ends. Separately, decide whether a local admin account remains available if the identity provider is down, who may use it, where its credentials are held and how its use is logged. Test that fallback in staging. The step is done when removed access is confirmed on the next login and the fallback sign-in works and produces a log entry.
Promote to production with a rollback plan
Apply the same configuration to production through your normal change process. Inject production secrets from the production store and register the production redirect URIs with the provider. Before the change, back up the metadata database and write down how to restore the previous configuration and reach the local fallback account if sign-in fails. The step is done when one administrator signs in through the production provider, the role list matches the mapping and the rollback steps have been reviewed by the owner.
How SSO setup differs across single node, HA and Kubernetes
On one host, SSO setup is mostly a matter of registering one callback URL with the identity provider, setting the Superset configuration to match, and terminating TLS in front of the application. Because only one web process holds sessions, there is no cross-node consistency to verify. The main design question is whether a reverse proxy sits in front of Superset and whether Superset is allowed to trust the headers it forwards.
- Callback URL: register the exact HTTPS address users see in the browser, including the path Superset uses for the OAuth redirect.
- TLS: terminate HTTPS at the proxy or on the host and confirm the redirect scheme Superset generates is https, not http.
- Proxy headers: decide whether Superset should honor forwarded host, protocol and client address headers, and restrict which proxy addresses can set them.
- Remote user headers: if you use header-based authentication, confirm that only your proxy can write the header, because any client that reaches the application directly could otherwise impersonate a user.
- Secrets on disk: keep the client secret and SECRET_KEY in a file or secret store readable only by the service account.
Before go-live, sign in with a user from each group you map, confirm the redirect returns to the correct host, and check that a request sent directly to the application port is refused or ignored.
With multiple web nodes behind a load balancer, every node has to behave as the same application. Each node needs the same identity configuration, the same client secret and the same SECRET_KEY, otherwise a login started on one node may fail or a session issued by one node may be rejected by another. The OAuth callback must also use the public address the users reach through the load balancer, not an internal node name.
- Shared configuration: deploy identical identity settings and secrets to every web node, and treat any drift as a defect.
- Callback address: register the load balancer's public hostname as the redirect target, and confirm the identity provider accepts it.
- Forwarded headers: configure the load balancer's forwarded host and protocol so Superset builds the correct callback and cookie scope.
- Session behavior: test a login, then repeated requests routed to different nodes, and confirm the user stays signed in and role mappings apply on every node.
- Logout and expiry: verify that logout and session timeouts behave the same regardless of which node handles the request.
A useful test is to pin a session to one node, stop that node, and confirm the user is redirected and re-authenticated cleanly rather than receiving errors. Confirm the cache and worker components that support this model with the Superset architecture documentation and your own load balancer's session settings.
On Kubernetes, SSO settings are not edited directly on a pod. They are passed through the install method, so the decision about how configuration and secrets reach the running containers shapes the SSO setup. The Superset 6.1.0 documentation describes installs with the official Helm chart, while the current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator, which is in alpha with a v1alpha1 API whose schemas may change between releases. The chart or operator decision itself is covered in the Kubernetes topic.
- Injection path: confirm how each method passes the identity configuration into the Superset configuration, whether through values, a custom configuration file or a custom resource field.
- Secret handling: confirm whether the client secret and SECRET_KEY are read from Kubernetes Secrets, mounted as files or written into plain values, and who can read them.
- Callback address: match the redirect URL to the ingress hostname and TLS certificate in use.
- Replicas and rollouts: confirm that every replica receives the same settings after an upgrade or secret rotation, and that a rolling restart does not invalidate sessions unexpectedly.
- Version pinning: record the chart or operator version, because configuration keys can change between releases.
Before relying on either method, ask the vendor or project documentation how each one injects identity configuration and secrets, and test a rotation in a non-production namespace first.
In an air-gapped environment, the identity provider or directory is inside the same isolated network, and nothing can call out to a public identity service or a public certificate authority. This removes the usual external callback path and makes the internal trust chain the critical part of the design. Login depends on the Superset host reaching the internal identity provider or LDAP server over addresses and ports your security team has approved.
- Reachability: confirm the Superset host can reach the internal identity provider or directory endpoints, including any discovery and token endpoints, and that firewall rules are documented.
- Certificate trust: install the internal root and intermediate certificates into the trust store Superset uses, and verify the full chain for every identity endpoint.
- No external callbacks: make sure the redirect and any metadata fetches resolve to internal names, and that nothing depends on a public URL.
- Certificate renewal: plan how internal certificates will be renewed and how the trust store is updated without an external download.
- Directory queries: for LDAP, confirm the service account, search bases and group attributes that role mapping depends on.
Before go-live, test login from a clean browser, break the trust chain on purpose in a test environment to confirm the failure is clear, and confirm that updates to packages or certificates follow your offline process.
What drives SSO effort and cost
This table lists the factors that most change the size of a Superset SSO project and shows how to keep each one under control. Read each row as a question to answer before requesting a quote, since the answers decide who does the work and how much of it recurs after go-live.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Identity sources and federation | Each separate directory or federated source adds claim mapping, testing and a second place where users can log in | Use one authoritative identity provider for Superset and federate other directories into it before integration starts |
| Groups and roles to map | AUTH_ROLES_MAPPING entries grow with every group, and each mapping needs a review of the Superset role it grants | Keep one authoritative group source, a small set of Superset roles, and a written map from group names to roles |
| Environments needing separate registrations | Development, staging and production usually need their own redirect URIs, client secrets and test users | Use a single staging tenant or registration for testing and template the configuration so only secrets and URLs change per environment |
| Team experience with OIDC or LDAP | Teams new to OAuth2 code flow or LDAP bind behavior need more time to debug claims, token lifetimes and group attributes | Ask the implementer to name the protocol engineers on the work and agree which parts the client's team will own |
| Login paths that must coexist | Keeping a fallback local login or LDAP path alongside SSO doubles the access controls to test and document | Decide early whether a break-glass local admin is required, limit it to named accounts and test both paths in staging |
| Identity provider change control and lead time | Application registrations, claim changes and group edits often need tickets and approvals on the identity team's schedule | Name an identity-side owner, agree a change window in advance and batch requested claim or group changes |
| Compliance evidence requests | Assessors may ask for configuration exports, access reviews and proof of MFA enforcement, which adds documentation work | Ask early which evidence the assessor expects and capture it during testing rather than after go-live |
| Deployment models | Running on a single host, high availability nodes or Kubernetes each changes how secrets, callback URLs and session storage are set | Agree one target deployment model for the SSO work and treat any later model as a separate change |
Securing the login path: headers, groups and fallback accounts
Single sign-on moves trust decisions out of Superset and into the identity path around it. The controls below cover the proxy, the directory, the secrets, the group-to-role mapping and the local accounts that together decide who can sign in and with what authority. Superset's SECRET_KEY, row-level security and HTTPS settings are covered in the security hardening guidance and are not repeated here.
Trust remote user headers only from the gateway
When Superset takes identity from a remote user header, any client that can reach the application directly can send that header and claim any identity. Place Superset behind the reverse proxy or gateway that sets the header, block direct access to the application port from clients and other networks, and strip any incoming copy of the header at the edge. Test this with a request sent straight to the application to confirm it is refused.
Validate TLS for provider and directory
Superset's connections to the OAuth or OIDC provider and to the LDAP directory must verify server certificates and the full chain up to a trusted root. Disabling verification to get a connection working hides misconfigured trust stores and opens the path to interception of credentials. Confirm the chain includes any internal certificate authority your directory uses, and set the trust bundle explicitly in the deployment rather than relying on the container's defaults.
Keep client secrets and bind credentials out of files
The OAuth client secret and the LDAP bind password are credentials that grant access to your identity system. Store them in your organization's secrets store and inject them at runtime through environment variables or mounted secrets, not in superset_config.py or in version control. Confirm who can read the secrets store entries, and plan a rotation procedure that updates Superset and the provider together.
Give the directory account read-only access
The LDAP bind account needs only enough rights to search for users and groups under the base DN Superset queries. Grant read-only search access, exclude write and password-reset permissions, and avoid reusing an administrator account. Ask your directory team to confirm which attributes the account can read, since group membership and mail attributes are what Superset relies on for mapping and user records.
Restrict which groups map to admin roles
AUTH_ROLES_MAPPING translates directory or provider groups into Superset roles, so any group mapped to Admin grants full control of the instance and its data source connections. Map only the smallest set of groups that need administrative rights, and keep the list of mapped groups in version control so changes are reviewed. Schedule a periodic review with the group owners to remove membership that no longer matches an operator's duties.
Control local fallback accounts
Superset can keep local database accounts alongside federated sign-in, and an unused local administrator becomes a standing password target outside your identity controls. Decide whether a break-glass account is needed at all, and if it is, store its credentials in a secrets store with restricted access, enable MFA where the platform supports it, and record every use. Confirm with your identity team how the account is disabled after an incident.
Log sign-in events for audit
Audit review needs a record of who signed in, through which provider or account, from where, and when sign-in failed. Confirm which authentication events Superset writes to its own logs and which are only visible at the identity provider or proxy, then forward both to your central logging platform with retention that matches your policy. Test the trail by performing a sign-in, a failed sign-in and a role change, and checking that each appears.
How to test Superset SSO logins, group mapping and failure modes
The purpose of this test plan is to prove, before go-live, that every way a person can reach Superset produces the access your access model intends. Positive tests confirm that each group listed in AUTH_ROLES_MAPPING lands the expected Superset roles after sign-in. Start with one test account per mapped group, then add one account that belongs to several groups at once. That account should receive the combined set of roles, not only the first match or the last one processed. Record the role list for each account so the result can be compared later with the identity provider's group membership, which is the source of truth. Negative tests check what must not happen. An account that belongs to no mapped group should be refused or should sign in with no useful access, depending on how your configuration handles default roles. Confirm which of those two behaviors you have, because a default role that exposes dashboards is a finding even if it is intended. Next, remove a test account from its group in the identity provider, then sign in again. The account should lose the removed role on that next login, not keep it because an old session or cached role persists. Last, disable the account in the identity provider and attempt to sign in. The attempt should fail at the identity provider or at Superset, and no new session should be created. Failure tests show how the integration behaves when parts of the chain break. Make the identity provider or directory unreachable, for example by pointing Superset at a wrong endpoint in staging, and confirm the user sees a clear error and no partial session. Present a wrong or untrusted certificate and confirm the login is rejected. Change the redirect URI so it does not match the registered value and confirm the flow stops. For header-based or remote user setups, send a request that carries the user header directly to the Superset application, bypassing the reverse proxy, and confirm it is ignored or rejected. In every failure case the expected result is the same: a clear error, no session with partial identity or roles, and no privilege escalation. Any case that leaves a session behind is a blocking defect. Capture evidence as you go so the results can be reviewed by security and audit stakeholders. Keep the list of test accounts with their group memberships, the role lists before and after each change, the exact test steps and timestamps, and the relevant log entries from Superset, the reverse proxy and the identity provider. Do not rely on screenshots alone. Run the full plan in a staging environment that mirrors production configuration, following the same discipline used for Superset upgrades: back up the metadata database, change one thing at a time, and record the result. Repeat the suite after any Superset upgrade, any change to AUTH_ROLES_MAPPING or any identity provider change, because a version change can alter how roles and sessions are handled.
Confirm details that depend on your own environment instead of assuming them. Check the exact names of the groups your identity provider emits, the claim or attribute that carries them, and whether group names are case sensitive in your mapping. Confirm the session lifetime and whether a removed role is enforced at the next login or only after the session expires. Ask the identity provider vendor and the Superset release notes for your version how disabled accounts and token revocation are handled.
What to monitor, document and review after SSO goes live
Once Superset signs users in through your identity provider, the risk shifts from setup errors to drift: expiring credentials, role mappings that no longer match your groups, and upgrades that change authentication behavior. The cards below cover what to watch, what to record and what to re-test so that access stays aligned with your identity model over time.
Failed sign-ins and role changes
Collect authentication failures from Superset and your identity provider in a log destination you review regularly. Sudden spikes in failed sign-ins can point to a broken redirect, an expired secret or a directory outage. Separately, watch for abrupt changes in the roles assigned to users, since a mapping error can silently grant or remove access. Confirm which monitoring tools and log destinations you will use with your own security operations team.
Expiry dates for credentials and certificates
Record expiry dates for OAuth client secrets, LDAP bind credentials and the TLS certificates that front Superset and the identity provider. An expired client secret or bind password usually stops all sign-ins at once, so assign an owner and a reminder well before each date. Confirm with your identity team how each provider handles secret rotation, since the procedure differs between providers.
Scheduled review of role mapping
Review the AUTH_ROLES_MAPPING configuration and the group memberships it reads on a fixed schedule agreed with your access governance owner. Groups get renamed, people change teams and stale groups keep granting dashboard or data access. Compare each mapped group against its current purpose and remove mappings that no longer serve a business need. Keep a dated record of each review and its outcome.
Version control and change records
Keep the Superset configuration that defines authentication, provider settings and role mappings in version control, with each change tied to a request, a reviewer and a date. This makes it possible to see who changed a mapping and to roll back a faulty change. Store secrets outside the repository in your approved secrets manager, and reference them from configuration rather than committing their values.
Test accounts, fallback and ownership
Document the test accounts used to verify each login path, the fallback procedure for when the identity provider is unavailable and the named owner for each component, including the provider, the Superset configuration and the directory. Store this record where operations staff can reach it during an outage, not only in the team's own tools. Confirm with your security team how fallback administrator access is granted, controlled and audited.
Re-testing after each Superset upgrade
After every Superset version upgrade, re-run your SSO verification cases in staging before production, covering login, logout, group-to-role mapping and denied access for users without a mapped group. Read the release notes and UPDATING.md for authentication changes, since defaults and configuration keys can change between versions. The current Superset release history is published on its releases page, so plan this check into every upgrade window.
Backups of the metadata database
The metadata database stores Superset's user and role records, so a corrupted or lost database means users and their role assignments must be rebuilt. Back up this database before each upgrade and on your normal schedule, and test restoring a backup in a non-production environment. Follow the upgrade guidance for running database migrations, and confirm backup frequency and retention with your database and recovery owners.
Apache Superset SSO questions buyers ask before hiring help
How much does Apache Superset SSO integration cost?
The cost depends on the work involved, not on a standard price, and DeployOpen does not publish one. The main cost drivers are the number of identity sources (for example, one OIDC provider versus an OIDC provider plus LDAP), how many groups must map to Superset roles through AUTH_ROLES_MAPPING, how many environments need the integration (development, staging and production each need testing), and the fallback design for when the identity provider is unavailable. The identity team's time is often the largest variable, because provider configuration, app registrations and group changes need their approval and review. Your cost is one-time for the build and recurs only if you buy ongoing support. Ask any partner for a written, fixed-scope quote that lists each identity source, environment, group mapping set and handover item separately.
How long does Superset SSO setup take to deliver?
The timeline depends on how quickly your team can provide the inputs, more than on the Superset configuration itself. Main factors: how many identity sources are involved, whether group definitions already exist in your identity provider or must be designed first, how many environments must be tested before production, how fast your identity team can register the application and approve changes, and whether a change window is needed for go-live. Delays most often come from unclear group ownership and waiting on administrator access. Ask for a schedule in the written scope that shows which milestones depend on your team's responses and approvals.
What does the client need to provide for an SSO engagement?
Plan to provide the following before work starts:
- Identity provider admin access or a named administrator who can register the Superset application and configure claims or groups
- Group definitions that map each business role to Superset roles, with a named owner for each group
- Test accounts in each environment covering every role that will sign in
- Certificate and secret handling rules, including who issues client secrets or certificates, where they are stored, and how they rotate
- A named approver who signs off on the group mapping, the fallback design and go-live
Confirm the storage and rotation method for secrets with your security team before the build starts, because it affects the design.
Can our internal team set up Superset SSO without a partner?
Often yes, when the scope is narrow. A team with OIDC or LDAP experience can usually handle a single identity source, such as one OIDC provider, with a modest set of group mappings. Check these first: whether someone on the team has done OIDC or LDAP configuration against your identity provider in production, whether you can register applications and manage groups without a long approval chain, whether your Superset metadata database and staging environment are already running, and whether you have a tested rollback plan. Multiple identity sources, complex group hierarchies or strict audit requirements usually add enough work that an outside review or partner becomes worth comparing.
Does SSO setup make Superset compliant with audit frameworks?
No. SSO supports compliance evidence, but it does not establish compliance on its own. It can show how users authenticate, how group membership drives role assignment and how access is removed when people leave, if those controls are configured and logged. Auditors and certification bodies assess the controls across your whole environment, including access reviews, logging, change management and the rest of the platform. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
What does DeployOpen hand over at the end of an SSO engagement?
Handover is defined in the written scope, but a typical SSO engagement should leave your team with the working configuration and the records needed to run it. Confirm that the scope includes: the configuration deployed in each environment, a documented group-to-role mapping with owners, the fallback and break-glass procedure, test results from each environment, step-by-step runbooks for adding users, groups and rotating secrets, and a record of the decisions made. Ask whether knowledge transfer sessions with your identity and platform staff are included and how many. Since Superset is Apache-2.0 software with no paid edition, the handover should also explain how your team will track upgrades that change authentication behavior.
How DeployOpen scopes, builds and hands over Superset SSO
DeployOpen plans, builds, tests and documents Apache Superset SSO inside your own infrastructure, so the identity provider, group model and Superset roles are agreed before any configuration changes. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- Inventory the identity provider, protocol (OAuth2, OIDC, LDAP or remote user headers) and the groups that must reach Superset.
- Document the group-to-role mapping for AUTH_ROLES_MAPPING and who approves changes to it.
- Confirm the Superset version, metadata database and hosting model that the SSO configuration will target.
- Record the written scope, deliverables and timeline before any work starts, with ongoing support offered as a retainer.
How we build
- Configure the chosen authentication backend in Superset's configuration with secrets held outside source control.
- Map identity provider groups to Superset roles and test each role against its intended dataset and dashboard access.
- Test login, logout, session expiry and access denial for users without a valid role in a staging environment first.
- Confirm a user-specified SECRET_KEY is set, since Superset requires one to start, before SSO goes live.
How we hand over
- Provide the configuration files, role mapping table and a record of the identity provider settings used.
- Document the test cases run, their results and the known limits of the chosen protocol and group mapping.
- Walk your identity and platform teams through how to add a group, change a role mapping and roll back a change.
- Deliver a runbook covering how to rotate client secrets and what to check after each Superset upgrade.
How we support
- Review SSO configuration whenever Superset is upgraded, checking UPDATING.md for changes that affect authentication.
- Support changes to identity provider groups, certificates and client secrets under a retainer agreed in writing.
- Re-run agreed login and role tests after upgrades and after identity provider changes, then report the results.
- Scope any further work such as custom security managers as a separate written engagement.
