AWS Identity Center for Apache Superset SSO

Understanding AWS Identity Center and Apache Superset Integration

AWS Identity Center (formerly AWS SSO) is your centralized gateway for managing user access across AWS accounts and third-party applications. Apache Superset, the open-source business intelligence platform, supports industry-standard single sign-on protocols that let you authenticate users through Identity Center without managing separate Superset credentials. When you wire these two systems together, you eliminate password sprawl, enforce corporate identity governance, and reduce onboarding friction for analytics teams.

This integration matters because data teams at scale-ups and mid-market companies need production-grade authentication without the platform overhead of Looker or Tableau. D23 provides managed Apache Superset with production-ready infrastructure, and adding AWS Identity Center SSO turns your deployment into an enterprise-grade analytics platform that respects your existing security posture.

The core mechanism is OpenID Connect (OIDC), a layer on top of OAuth 2.0 that handles identity verification. AWS Identity Center acts as your OIDC provider, Superset acts as the relying party (the application), and your users authenticate once through Identity Center to gain access to dashboards and data exploration.

Why AWS Identity Center Over Self-Managed Authentication

Managing authentication yourself means maintaining user directories, handling password resets, auditing access, and enforcing multi-factor authentication policies. AWS Identity Center centralizes this work. Your IT team configures users and groups once in Identity Center, and those identities automatically propagate to connected applications—including Superset.

The business case is straightforward: fewer secrets to manage, faster employee onboarding, automatic offboarding when someone leaves, and audit trails that satisfy compliance teams. If you’re already using AWS for infrastructure, Identity Center is native to your environment. If you’re using it for other SaaS applications, Superset becomes one more app in your unified identity fabric.

Compare this to alternatives. Looker and Tableau require separate user provisioning or expensive directory sync connectors. Metabase and Mode offer SSO but often require additional configuration layers. Superset’s flexibility—combined with AWS Identity Center’s broad OIDC support—gives you a cost-effective path to enterprise authentication without vendor lock-in.

For engineering teams embedding self-serve BI into products, this setup is critical. Your end-users authenticate through your corporate identity system, not a separate Superset login. Your platform team manages one authentication layer, not two.

Prerequisites and Architecture Overview

Before you start, you need:

• An AWS account with AWS Identity Center enabled (available in all AWS regions)
• A Superset instance running version 1.5.0 or later (earlier versions have limited OIDC support)
• Administrator access to both Identity Center and your Superset deployment
• A domain for your Superset instance (e.g., analytics.yourcompany.com)
• Basic familiarity with OIDC flows and JWT tokens

The architecture works like this:

1. User navigates to your Superset instance
2. Superset detects no active session and redirects to AWS Identity Center
3. User authenticates (username, password, MFA if enabled)
4. Identity Center generates an ID token and returns the user to Superset
5. Superset validates the token, extracts user info (email, name, groups), and creates or updates the user record
6. User is logged in and can access dashboards based on their group memberships

This flow happens transparently. Once configured, users never see a Superset login form—they’re authenticated through Identity Center automatically.

Setting Up AWS Identity Center for OIDC

Start in the AWS Management Console. Navigate to AWS Identity Center (you’ll find it under “Security, Identity & Compliance” or search directly). If you haven’t enabled it yet, follow the setup wizard. AWS walks you through choosing an identity source (AWS Identity Center directory, Active Directory, or external IdP) and configuring MFA policies.

Once Identity Center is active, create a user group for your analytics team. This group will sync to Superset, allowing you to grant dashboard access based on group membership rather than individual user assignment. Go to Groups in Identity Center, create a new group (e.g., “Analytics Users”), and add team members.

Next, configure an application in Identity Center. This tells Identity Center about Superset and generates the credentials you’ll use for OIDC. In the Identity Center console:

1. Go to Applications
2. Click Add application
3. Choose I have an application I want to set up (not a pre-built connector)
4. Select SAML 2.0 or OIDC (choose OIDC for Superset)
5. Name it “Superset” or similar
6. Set the Assertion Consumer Service URL to your Superset instance: https://analytics.yourcompany.com/oauth_authorized/aws-oidc (the exact path depends on your Superset configuration, which we’ll cover next)
7. Configure the application name, description, and any other metadata

Identity Center will generate a Client ID and Client Secret. Store these securely—you’ll need them in Superset’s configuration.

Then, assign your analytics group to the Superset application. In Identity Center, go to Applications > Superset > Assign access, and add your analytics group. This ensures only group members can log in.

You’ll also need Identity Center’s OIDC discovery endpoint. This typically looks like https://identity-center-domain.awsapps.com/identity/oauth2/authorize. AWS provides the exact URL in the application details.

Configuring Apache Superset for OIDC Authentication

Superset’s authentication is built on Flask-AppBuilder, a Python framework that handles OAuth, OIDC, SAML, and custom auth schemes. The Flask-AppBuilder security documentation covers all available options, but we’ll focus on OIDC configuration here.

You configure Superset through environment variables or a superset_config.py file. If you’re running D23’s managed Superset, your deployment team can handle this configuration—but understanding the mechanics is valuable.

Here’s the core OIDC configuration:

from flask_appbuilder.security.manager import AUTH_OIDC

AUTH_TYPE = AUTH_OIDC

OIDC_CLIENT_SECRETS = '/path/to/client_secrets.json'  # or set via env var
OIDC_DISCOVERY_URL = 'https://identity-center-domain.awsapps.com/identity/oauth2/.well-known/openid-configuration'

The client_secrets.json file contains your Client ID and Client Secret from Identity Center:

{
  "web": {
    "client_id": "your-client-id-from-identity-center",
    "client_secret": "your-client-secret",
    "redirect_uris": ["https://analytics.yourcompany.com/oauth_authorized/aws-oidc"],
    "auth_uri": "https://identity-center-domain.awsapps.com/identity/oauth2/authorize",
    "token_uri": "https://identity-center-domain.awsapps.com/identity/oauth2/token",
    "userinfo_uri": "https://identity-center-domain.awsapps.com/identity/oauth2/userinfo"
  }
}

Replace the domain with your actual Identity Center domain. AWS provides these URLs in the application configuration.

Apache Superset’s authentication documentation has additional options for mapping OIDC claims to Superset user attributes. By default, Superset extracts the user’s email and name from the ID token. If you need custom claim mapping—for instance, mapping an ou (organizational unit) claim to Superset roles—you’ll need to customize Superset’s security manager.

Mapping AWS Identity Center Groups to Superset Roles

Here’s where the integration gets powerful. AWS Identity Center includes group membership in the ID token as a claim (typically cognito:groups or a custom claim, depending on your configuration). Superset can read this claim and automatically assign users to roles based on their group membership.

Superset has built-in roles: Admin, Alpha (power user), Gamma (viewer), and Public. You can also create custom roles for specific dashboard access. The mapping works like this:

• User logs in via Identity Center
• Superset receives the ID token with group claims
• Superset’s security manager extracts the groups
• Groups are mapped to Superset roles (e.g., “Analytics Users” → Gamma, “Data Engineers” → Alpha)
• User is assigned the corresponding role automatically

To implement this, you need to customize Superset’s security manager. The Apache Superset security manager source code shows the underlying implementation. You’ll create a custom security manager class that overrides the get_user_id or user_info_from_idtoken method to extract group claims and map them to roles.

Here’s a simplified example:

from superset.security import SupersetSecurityManager
from flask_appbuilder.security.manager import AUTH_OIDC

class CustomSecurityManager(SupersetSecurityManager):
    def user_info_from_idtoken(self, user_info):
        """
        Extract user info and group claims from the ID token.
        """
        # Get base user info
        user_info = super().user_info_from_idtoken(user_info)
        
        # Extract groups from the token
        groups = user_info.get('cognito:groups', [])
        
        # Map groups to Superset roles
        user_info['role_keys'] = []
        if 'Data Engineers' in groups:
            user_info['role_keys'].append('Alpha')
        elif 'Analytics Users' in groups:
            user_info['role_keys'].append('Gamma')
        
        return user_info

You then tell Superset to use this custom manager in your config:

CUSTOM_SECURITY_MANAGER_CLASS = 'path.to.CustomSecurityManager'

This approach scales well. As you add new groups to Identity Center, you update the mapping logic once, and all new users are automatically assigned the correct roles.

Handling User Provisioning and Deprovisioning

When you integrate Superset with AWS Identity Center, user provisioning becomes automatic. A user logs in once, and Superset creates their account. Subsequent logins use the same account. This is much simpler than manual provisioning.

Deprovisioning is where you need to be thoughtful. When you remove a user from Identity Center, they can no longer log in—but their Superset account and any saved queries or dashboards they created remain in the database. This is usually fine. If you need stricter cleanup, you can:

1. Periodically audit Superset users against your Identity Center directory and delete orphaned accounts
2. Set up a scheduled task that disables Superset accounts for users no longer in Identity Center
3. Use Superset’s API to programmatically manage user lifecycle

For teams embedding self-serve BI, this automatic provisioning is a huge win. Your customers authenticate through their corporate identity, and Superset handles the rest.

Configuring MFA and Session Management

AWS Identity Center supports multi-factor authentication (MFA) at the organization level. Once you enable MFA in Identity Center, it applies to all connected applications, including Superset. Users must complete MFA when they log in to Identity Center, and the resulting session is trusted by Superset. You don’t need to configure MFA separately in Superset.

Session management is also inherited from Identity Center. If you configure a session timeout in Identity Center (e.g., 8 hours of inactivity), that timeout applies when users access Superset. When the session expires, they’re redirected to log in again.

Superset also has its own session settings. In your Superset config, you can set:

SESSION_COOKIE_SECURE = True  # Only send over HTTPS
SESSION_COOKIE_HTTPONLY = True  # Prevent JavaScript access
PERMANENT_SESSION_LIFETIME = 3600  # 1 hour, in seconds

These are separate from Identity Center’s session timeout. If Identity Center’s session expires first, the user is logged out of Superset. If Superset’s session expires first, the user is logged out of Superset but remains logged in to Identity Center (and can re-authenticate quickly).

Testing and Troubleshooting the Integration

Once you’ve configured everything, test the integration end-to-end. Navigate to your Superset instance in an incognito browser window (to avoid cached sessions). You should be redirected to Identity Center’s login page. Log in with a test account that’s assigned to the Superset application.

If the redirect doesn’t happen, check:

1. OIDC discovery URL: Make sure it’s correct and accessible from your Superset instance
2. Client ID and Secret: Verify they match what you configured in Identity Center
3. Redirect URI: Confirm it matches exactly in both Identity Center and Superset (including protocol, domain, and path)
4. Network connectivity: Ensure your Superset instance can reach Identity Center’s endpoints

If you get an error after login, check Superset’s logs. Look for messages about token validation, claim extraction, or user creation. Common issues include:

• Invalid token signature: The token was signed with a key Superset doesn’t recognize. Make sure you’re using the correct OIDC discovery URL.
• Missing claims: The token doesn’t include expected claims (e.g., email, groups). Check your Identity Center configuration and token claims mapping.
• User creation failure: Superset tried to create a user but failed (e.g., duplicate email). Check Superset’s database and user management settings.

For detailed debugging, enable debug logging in Superset:

LOGGING_LEVEL = 'DEBUG'

This will print detailed information about the OIDC flow, token validation, and user provisioning.

Advanced: Custom Claims and Role-Based Access Control

As your analytics platform grows, you might need more sophisticated access control. AWS Identity Center supports custom attributes and claims. You can add custom attributes to users (e.g., department, cost_center, team) and include them in the ID token.

Superset can then use these claims for fine-grained access control. For example, you might restrict dashboard access based on department:

class CustomSecurityManager(SupersetSecurityManager):
    def user_info_from_idtoken(self, user_info):
        user_info = super().user_info_from_idtoken(user_info)
        
        # Extract custom claims
        department = user_info.get('department')
        
        # Assign roles based on department
        if department == 'Finance':
            user_info['role_keys'] = ['Finance Analyst']
        elif department == 'Sales':
            user_info['role_keys'] = ['Sales Analyst']
        
        return user_info

You can also use custom claims for row-level security (RLS) in Superset. If a user’s claim includes their team, you can filter dashboard data to show only that team’s metrics. This requires configuring RLS rules in Superset, which is a more advanced topic—but the foundation is the same: extract claims from the ID token and use them to control access.

Integration with D23’s Managed Superset

D23 provides managed Apache Superset with expert data consulting, AI-powered analytics via text-to-SQL, and MCP server integration for advanced workflows. If you’re using D23, AWS Identity Center setup is handled by your deployment team. You provide your Identity Center configuration (Client ID, Client Secret, discovery URL), and D23 wires it into your Superset instance.

This approach eliminates the operational burden of managing Superset infrastructure while giving you enterprise-grade authentication. Your data team focuses on building dashboards and exploring data, not maintaining auth systems.

D23 also integrates with your data consulting needs. As you scale your analytics platform, you might need help designing dashboards, optimizing queries, or implementing AI-assisted analytics. D23’s consulting team works alongside your team to build production-grade analytics without the platform overhead of Looker or Tableau.

Comparing AWS Identity Center to Alternative SSO Providers

AWS Identity Center is one option among several. If your organization uses Okta, Ping Identity, or Azure AD, those providers also support OIDC and integrate with Superset. Implementing OKTA SSO in Apache Superset follows a similar pattern: configure OIDC, extract claims, map roles, and you’re done.

The choice depends on your existing identity infrastructure:

• AWS Identity Center: Best if you’re already in AWS and want a native, cost-effective solution
• Okta: Best if you have a multi-cloud strategy or use Okta for other applications
• Azure AD: Best if you’re in the Microsoft ecosystem (Office 365, Azure, etc.)
• Ping Identity: Best for large enterprises with complex federation requirements

Superset supports all of these through OIDC or SAML. The configuration details vary slightly, but the underlying concepts are the same.

Security Best Practices for Superset SSO

Once you’ve integrated AWS Identity Center with Superset, follow these security practices:

1. Use HTTPS everywhere. Your Superset instance must be accessible over HTTPS only. OIDC tokens are sensitive, and HTTP exposes them to interception.

2. Rotate Client Secrets regularly. Identity Center lets you rotate your Client Secret. Do this every 90 days or when team members leave.

3. Monitor failed login attempts. Check Superset and Identity Center logs for repeated failed authentication attempts, which might indicate an attack.

4. Enforce MFA in Identity Center. Require MFA for all users, especially those with admin access to Superset.

5. Audit user access. Regularly review who has access to Superset and which roles they’re assigned. Remove access for users who no longer need it.

6. Use short session timeouts. Balance security with usability. A 1-hour timeout is reasonable for most analytics teams.

7. Separate identity from authorization. Identity Center handles authentication (proving who you are). Superset handles authorization (what you can access). Keep these concerns separate in your configuration.

These practices ensure your analytics platform remains secure as it grows.

Scaling and Performance Considerations

As your analytics team grows, the OIDC integration scales transparently. Each login triggers a token exchange with Identity Center, but these are fast (typically <500ms) and cached by Superset. Performance impact is negligible.

If you have hundreds or thousands of users, consider:

1. Group sync frequency. If you’re mapping Identity Center groups to Superset roles, groups are synced on each login. For large organizations, this is still fast, but you can optimize by caching group membership.

2. User provisioning. Superset creates users on first login. For very large deployments, you might pre-provision users via the API to avoid database locks during peak login times.

3. Token validation. Superset validates tokens using public keys from Identity Center’s JWKS endpoint. These keys are cached, but you can tune the cache TTL if needed.

Most analytics teams don’t hit these scaling limits. D23’s managed Superset handles scaling automatically—your team doesn’t need to worry about performance tuning.

Compliance and Audit Trails

AWS Identity Center provides detailed audit logs of all authentication events. You can export these logs to CloudTrail or a SIEM for compliance reporting. Combined with Superset’s audit logs (which track dashboard views, query execution, etc.), you have a complete picture of who accessed what and when.

This is critical for:

• SOC 2 compliance: Demonstrate that access is controlled and audited
• HIPAA: Show that sensitive data access is logged and reviewed
• GDPR: Prove that user access is governed and can be revoked
• Internal audits: Track who has access to financial or strategic dashboards

Superset’s audit logs are stored in the database. You can query them directly or export them to your data warehouse. Combined with Identity Center’s logs, you have a comprehensive audit trail.

Real-World Implementation Example

Let’s walk through a realistic scenario: a mid-market SaaS company with 150 employees, using AWS for infrastructure and Okta for identity (but wanting to consolidate to AWS Identity Center).

Week 1: Planning

• Audit current Superset users and their access patterns
• Plan group structure in Identity Center (Finance, Sales, Engineering, Marketing)
• Identify custom claims needed (department, cost_center)

Week 2: Identity Center Setup

• Enable AWS Identity Center in the primary AWS account
• Create user groups and populate them
• Configure custom attributes
• Create the Superset application in Identity Center
• Assign groups to the application

Week 3: Superset Configuration

• Update Superset config with OIDC settings
• Create custom security manager for group-to-role mapping
• Test with a pilot group (e.g., 5 people from Finance)
• Verify dashboards load correctly and data access is restricted properly

Week 4: Rollout

• Announce the change to all Superset users
• Migrate users in batches (by department)
• Disable old Superset authentication method
• Monitor logs for issues
• Provide support for users who encounter problems

Ongoing: Maintenance

• Review access quarterly
• Rotate Client Secrets every 90 days
• Monitor failed login attempts
• Update custom claims as business needs evolve

This timeline is realistic for a mid-market company. Larger organizations might take longer; smaller ones might move faster.

Troubleshooting Common Integration Issues

Issue: Users can log in but don’t have the expected roles.

This usually means group claims aren’t being extracted correctly. Check:

• The ID token includes group claims (use a JWT decoder to inspect the token)
• Your custom security manager is extracting the correct claim name (might be cognito:groups, groups, or something custom)
• The group names in Identity Center exactly match your role mapping logic (case-sensitive)

Issue: Redirect URI mismatch error.

The redirect URI in Identity Center must match exactly what Superset is sending. Check:

• Protocol (http vs. https)
• Domain (including subdomains)
• Path (including any URL prefixes if Superset is behind a reverse proxy)
• Query parameters (shouldn’t be included in the redirect URI)

Issue: Token validation fails.

Superset can’t verify the token signature. Check:

• OIDC discovery URL is correct
• Superset can reach the discovery URL (check firewall rules)
• The discovery URL returns valid JSON with the jwks_uri field
• Superset has downloaded the public keys (check logs)

Issue: User creation fails with duplicate email.

Two users in Identity Center have the same email, or a user already exists in Superset with that email. Check:

• Identity Center user list for duplicate emails
• Superset database for existing users with that email
• Your email claim extraction logic (might be pulling the wrong field)

Next Steps and Further Learning

Once you’ve successfully integrated AWS Identity Center with Superset, consider:

1. Implementing row-level security (RLS): Use custom claims to restrict dashboard data by user attributes
2. Setting up automated provisioning: Use AWS Lambda to sync Identity Center changes to Superset automatically
3. Integrating AI-powered analytics: D23’s AI analytics capabilities include text-to-SQL, which works seamlessly with SSO-authenticated users
4. Embedding Superset dashboards: If you’re embedding analytics in your product, SSO ensures your customers authenticate through their corporate identity
5. Advanced monitoring: Set up alerts for failed login attempts or unusual access patterns

For more details on Superset authentication options, see the official documentation. For AWS Identity Center specifics, refer to the AWS documentation.

The integration of AWS Identity Center with Apache Superset is a powerful way to build enterprise-grade analytics without the overhead of proprietary BI platforms. Your users get a seamless login experience, your team gets centralized access control, and your security team gets comprehensive audit trails. It’s a win across the organization.

For teams using D23’s managed Superset, this integration is handled end-to-end by the platform team, freeing your data and engineering leaders to focus on analytics strategy and implementation rather than infrastructure management.