Reuse/Migrate users to use SSO

[bonamim]

When we created the Apache Superset instance we kept the default login form (user/pass).

However, we need to switch to using Google SSO. This change has already been configured in the development environment, but we have verified the following situation:

• If the user already exists with the same email that the person is trying to access, the following error message is displayed ❌
• If the user doesn't exist, a new one is created and everything is normal ✅

Environment

• browser type and version: Chrome (Version 104.0.5112.101)
• superset version: superset version 2.0.0
• any feature flags active:
  • ENABLE_TEMPLATE_PROCESSING
• The config inside the Pod:

  config_oauth: |
    CSRF_ENABLED = True
    # This will make sure the redirect_uri is properly computed, even with SSL offloading
    ENABLE_PROXY_FIX = True
  
    from flask_appbuilder.security.manager import AUTH_OAUTH
    AUTH_TYPE = AUTH_OAUTH
    OAUTH_PROVIDERS = [
        {
            "name": "google",
            "icon": "fa-google",
            "token_key": "access_token",
            "remote_app": {
                "client_id": os.getenv("GOOGLE_KEY"),
                "client_secret": os.getenv("GOOGLE_SECRET"),
                "api_base_url": "https://www.googleapis.com/oauth2/v2/",
                "client_kwargs": {"scope": "email profile"},
                "request_token_url": None,
                "access_token_url": "https://accounts.google.com/o/oauth2/token",
                "authorize_url": "https://accounts.google.com/o/oauth2/auth",
                "authorize_params": {"hd": os.getenv("AUTH_DOMAIN", "")}
            },
        }
    ]
  
    # Map Authlib roles to superset roles
    AUTH_ROLE_ADMIN = 'Admin'
    AUTH_ROLE_PUBLIC = 'Public'
  
    # Will allow user self registration, allowing to create Flask users from Authorized User
    AUTH_USER_REGISTRATION = True
  
    # The default user self registration role
    AUTH_USER_REGISTRATION_ROLE = "Gamma"
  

Question

• Is it possible to reuse or somehow migrate existing users? Because if it is not possible, we will lose all relations between the user and the object created by him/her.

[bonamim]

@rusackas, Could you help me escalate this situation? I don't know if it's a bug or feature.

[c608345]

You can get a clue from superset cli log.

[rusackas]

Tagging @craig-rueda @nytai here since they'd know better than I.

[ichait-bgl]

Not sure if this will help, but we had a similar setup. Started with vanilla user/pass auth and then enabled SSO via Jumpcloud.

If a user was already created through user pass, when they logged in via SSO, a new user record would be created because the field values (e.g. username) used to created the user initially were different to those coming from Jumpcloud.

What worked for us was to edit any existing user records so that the fields would match what would come from Jumpcloud. Then when the user logs in via SSO, Superset seemed to just match them with the existing user and all worked fine.

[einsteinhacks24]

@ichait-bgl can you please elaborate the below statement? I am also stuck after changing the login from credentials to Google SSO.What all parameters do i have to match ? Is it just first_name, last_name, user_name and email ? Thanks in advance

"What worked for us was to edit any existing user records so that the fields would match what would come from Jumpcloud"

[rusackas]

Are you still facing this? I'm assuming not... I'll close it as stale since it's been quiet for months, we no longer support Superset prior to 3.1, and we can't really help troubleshoot custom security managers. From re-reading the thread, it sounds like there were just pre-SSO user accounts blocking on unique email addresses. I would assume you need to somehow migrate those accounts, but it might be easier to delete/recreate them depending on the state of the instance (which sounds like it's a pretty fresh setup, so hopefully recreating users in your preferred auth system isn't the end of the world).

We can revisit/reopen this if you're still facing this in Superset 3.1/4.0, but updated context would be appreciated.

[scarby]

@rusackas this is still an issue with superset 4.0.1

In my case i'm looking at how to sync role assignments between our internal application database and apache superset. In this scenario it would be nice to be able to pre-create the user via the superset API and attach the correct roles based on the users Org unit, then when the user logs in via OIDC it would be useful to update the user with the user_id from oidc, instead superset fails when trying to insert a user with a duplicate e-mail address.

[rusackas]

Right, you can't have two users with the same email address. Can you update the existing user rather than insert a new (effectively duplicate) user? This workflow isn't something I often deal with, but I'm not sure it's a bug, per see. Maybe @nytai can either help or recommend someone else who knows the right way to pull this off.

[scarby]

Right, you can't have two users with the same email address. Can you update the existing user rather than insert a new (effectively duplicate) user? This workflow isn't something I often deal with, but I'm not sure it's a bug, per see. Maybe @nytai can either help or recommend someone else who knows the right way to pull this off.

In this case the solution was to use a custom security manager and use the e-mail as the username (as the sid from oauth isn't necessarily known to us beforehand) It would be nice to have an out of the box flag to use the e-mail to identify the user so it doesn't try to create a new one if the username doesn't exist.