Someone gets locked out of Superset again. Slack lights up. Screenshare starts. Another fifteen minutes of “who has admin rights?” Later, the dashboard works, but everyone feels a little less secure. That’s the pain SAML Superset exists to solve.
Superset handles visualization and data storytelling. SAML, short for Security Assertion Markup Language, handles identity and trust exchanges between applications and an identity provider like Okta, Azure AD, or Google Workspace. The two complement each other: Superset tells data stories, SAML keeps the storytellers authorized. Getting the integration right means no more guessing who’s allowed inside, only clean, verifiable sessions.
The typical workflow looks like this. Your identity provider authenticates users using single sign-on (SSO). Superset receives the signed SAML assertion containing user attributes such as email and group membership. Those attributes map to Superset roles, granting access based on predefined policies. Once configured, Superset no longer stores passwords locally, relying entirely on federated authentication. Every login is both faster and auditable.
Mistakes during setup usually stem from mismatched metadata XML files or inconsistent entity IDs. Make sure your IdP-generated metadata matches the exact callback URL Superset expects. Rotate your SAML certificates regularly, and verify clock sync between Superset and the IdP to prevent assertion expiry errors. For tight RBAC mapping, use group claims to assign data source roles automatically. This prevents broad permissions that can lead to accidental exposure of sensitive metrics.
How do I connect SAML and Superset?
You import the IdP metadata into Superset’s configuration, define trusted domains, and specify the SAML certificate. Once saved, Superset requests authentication from the IdP every time a user attempts login, enforcing identity without manual account creation. That connection point becomes your secure boundary.