Can't open Settings -> List Users when using OAuth with Google for an Admin user

[pingusix]

A clear and concise description of what the bug is.

Expected results

User list displays and users can be edited When settings -> List Users is selected

Actual results

Get an access denied popup and return to dashboard

How to reproduce the bug

Enable AUTH_TYPE=AUTH_OAUTH in config.py

Snippet of config.py:

AUTH_TYPE = AUTH_OAUTH AUTH_USER_REGISTRATION = True AUTH_USER_REGISTRATION_ROLE = "Admin" PUBLIC_ROLE_LIKE_GAMMA = True OAUTH_PROVIDERS = [ { "name": "google", "icon": "fa-google", "token_key": "access_token", "remote_app": { "client_id": "xxx", "client_secret": "xxx", "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", } } ]

Register a new user using Google as a provider. Go to settings-> List Users

Also changed auth type back to AUTH_DB and logged in as admin. I then deleted permissions for new google-based admin user and added them back in so they matched the currently authorised admin. Logged out, changed config.py back to use oauth and logged in as google-based admin user. Problem remains (also created a new auth_db based user with same permissions and worked correctly)

Environment

(please complete the following information):

Ubuntu 18.04.3 Superset 1.0.1 Python 3.7.5 Node 8.10.0

[rrittsteiger]

We are also struggling with this problem.

[danielewood]

I'm not having this problem with Superset 1.1.0 running on Kubernetes, here is my google auth config for you to compare:

extraEnv:
  OAUTH_HOME_DOMAIN: 'mydomain.com'
  OAUTH_WHITELIST_REGEX: '@mydomain.com$'
extraSecretEnv:
  # GCP API Keys: https://console.cloud.google.com/apis/credentials
  # GCP ClientID: superset-oauth2
  GOOGLE_KEY: xxxxxxx.apps.googleusercontent.com
  GOOGLE_SECRET: xxxxxxxxxx
  
configOverrides:
  enable_proxy_fix: |
    # This will make sure the redirect_uri is properly computed, even with SSL offloading
    ENABLE_PROXY_FIX = True
  enable_debug: |
    LOG_LEVEL = 'DEBUG'
  enable_oauth: |
    from flask_appbuilder.security.manager import (AUTH_DB, AUTH_OAUTH)
    AUTH_TYPE = AUTH_OAUTH
    OAUTH_PROVIDERS = [
        {
            "name": "google",
            "whitelist": [ os.getenv("OAUTH_WHITELIST_REGEX", "") ],
            "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("OAUTH_HOME_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 = "Admin"

[pingusix]

Thanks for that, I've tried the above with 1.1.0 but am still getting the same issue -on login I appear to have a profile of Admin and can list roles (and can see the users assigned to the roles), etc but clicking on List Users gives an access denied.

Out of interest I implemented LDAP authentication against our production dc and am getting the same issue.

Reverting to AUTH_DB allows me to list and edit users.

Can I check my understanding that the expected behaviour of an admin user via OAUTH or LDAP is that they should be able to list and edit users within the app?

[danielewood]

Can I check my understanding that the expected behaviour of an admin user via OAUTH or LDAP is that they should be able to list and edit users within the app?

Yes. I do not even create a local admin account for my clusters anymore.

[pmarini]

Hi, I can confirm the same issue in my installation with LDAP authentication.

Environment

Ubuntu Server 20.04 Python 3.8.5 Apache Superset 1.1.0

[nxmbiar]

Even I had run into the same issue with my LDAP setup. Running a superset init resolved it

[TheRum]

I was also facing the same issue. But just now I ran superset init and it worked ! (I also use OAuth for authentication.)

[shawnzhu]

I have similar problem when initializing superset with AUTH_TYPE = AUTH_OAUTH in config but used AUTH_TYPE = AUTH_OAUTH after OAUTH2 config works.

I found the problem is about missing permissions like can (list|edit|userinfo|show|add|delete) UserOAuthModelView, which explained why it works after re-run superset init which basically sync role definitions.

So when switching authentication methods, the user data model name changes: https://github.com/dpgaspar/Flask-AppBuilder/blob/1fb6d985910d306a821a8da072cd3c93e41311ac/flask_appbuilder/security/mongoengine/manager.py#L43-L52

which means after switching authentication methods, it needs re-run superset init, or adding required permissions to the Admin role.

[calfzhou]

facing the same issue on my first day of using Superset 🥲

re-run superset init fixed it :-p

[alejandroparra]

I'm not having this problem with Superset 1.1.0 running on Kubernetes, here is my google auth config for you to compare:

extraEnv:
  OAUTH_HOME_DOMAIN: 'mydomain.com'
  OAUTH_WHITELIST_REGEX: '@mydomain.com$'
extraSecretEnv:
  # GCP API Keys: https://console.cloud.google.com/apis/credentials
  # GCP ClientID: superset-oauth2
  GOOGLE_KEY: xxxxxxx.apps.googleusercontent.com
  GOOGLE_SECRET: xxxxxxxxxx
  
configOverrides:
  enable_proxy_fix: |
    # This will make sure the redirect_uri is properly computed, even with SSL offloading
    ENABLE_PROXY_FIX = True
  enable_debug: |
    LOG_LEVEL = 'DEBUG'
  enable_oauth: |
    from flask_appbuilder.security.manager import (AUTH_DB, AUTH_OAUTH)
    AUTH_TYPE = AUTH_OAUTH
    OAUTH_PROVIDERS = [
        {
            "name": "google",
            "whitelist": [ os.getenv("OAUTH_WHITELIST_REGEX", "") ],
            "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("OAUTH_HOME_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 = "Admin"

for instance I recommend that you pass the credentials via configmap or secrets

[danielewood]

for instance I recommend that you pass the credentials via configmap or secrets

I'm not sure what the critique here is. Could you expand upon your statement?

[apratsunrthd]

Also facing this issue.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue .pinned to prevent stale bot from closing the issue.

[kapustor]

Same issue.

[radykal-com]

I'm facing the same issue with Oauth2 created users (with Admin role) and Superset 1.5.1

[weitang2022]

Still facing the same issue. Does anyone have a workaround?

[passren]

just re-run "superset init"

[ignasv]

Same issue on superset 2.1.0. Re-running superset init does not solve it.

[MPalix86]

Faced with the same issue while using Keycloak with Superset, I discovered that the roles in Keycloak for both the client and the users were not assigned correctly. To resolve this, I simply created the 'Admin' role for the Superset client in Keycloak and then assigned the role to the user under the Superset client.

[Domineer-Long]

I tried using OAUTH and LDAP and encountered the same issue, But the issue was resolved after running superset init.

[rusackas]

Shall we call this one resolved, then?

[rumbin]

At least on 3.0.3 this one is still an issue for us.

[mrtanatorn44]

Am working on Apache/Superset 3.1.0 using Official Docker image and using OAuth with AWS Cognito. I can resolved this with the same method as all previous comments but I have additional config.

1. Enter container and execute superset init.
2. Login as admin on website and go to List Roles page on top right menu.
3. Click edit Admin role record and add the permission below.
   (Make sure you are adding it, because if you click in drop down again it will remove)
   • can userinfo on UserOAuthModelView
   • can show on UserOAuthModelView
   • can list on UserOAuthModelView
   • can add on UserOAuthModelView
   • can edit on UserOAuthModelView
   • can delete on UserOAuthModelView

PS. If you are not using docker, I hope this step can guide you.