GitHub user shelkesays added a comment to the discussion: Restriction of User
and Role Views to Admins Only
**Allow User/Role Management UI Access Based on Permissions Instead of
Admin-Only Route Gating**
The frontend currently restricts access to user, role, and group management
routes exclusively to Admin users via an isAdmin check in routes.tsx. This
prevents organizations from delegating user lifecycle operations through custom
roles, even though the backend permission model and Flask-AppBuilder access
controls already support these workflows. As a result, organizations are often
forced to grant full Admin access to operational staff for routine account
management tasks, increasing overall privilege exposure.
Background:
We operate a Superset deployment with approximately 300 users across multiple
functional teams (Sales, Finance, Operations, Customer Success, etc.).
The security rationale behind limiting user and role management to Admin users
is understandable. However, in practice, routine user lifecycle operations
occur frequently:
* Creating accounts for new hires
* Resetting passwords
* Disabling accounts for departing employees
* Updating role assignments when users change teams
These activities are operational in nature and do not require broad platform
administration privileges.
Currently, the only practical way to delegate these responsibilities is to
grant the full Admin role, which also provides access to:
* Editing all dashboards regardless of ownership
* Creating, modifying, and deleting roles
* Managing Row Level Security (RLS) rules
* Changing instance configuration
* Modifying security policies
* Managing datasets and database connections
* Other platform-wide administrative capabilities
Impact:
This requirement can unintentionally weaken least-privilege practices.
In our deployment, there are currently 17 Admin accounts. Most were granted
Admin solely to perform user onboarding, offboarding, or password reset tasks.
This significantly broadens the set of users with elevated platform privileges
and reduces the practical distinction of the Admin role.
Observed Behavior:
The backend permission model already supports granular delegation of user
management capabilities through permissions such as:
* can_list | UserDBModelView
* can_add | UserDBModelView
* can_edit | UserDBModelView
* resetpasswords | UserDBModelView
* menu_access | List Users
When these permissions are assigned to a custom role, Flask-AppBuilder’s
@has_access decorators correctly authorize access to endpoints such as:
* /users/list/
* /users/add
* /users/edit/<id>
* /resetpasswords/form
However, the frontend route registration logic contains an Admin-only gate:
if (isAdmin) {
...
}
As a result, users with the required backend permissions never see the
corresponding UI routes, despite being authorized by the backend.
Expected Behavior:
Frontend route registration should align with the existing backend permission
model.
Users who possess the relevant permissions should be able to access:
* User management routes when granted menu_access | List Users
* Role management routes when granted menu_access | List Roles
* Group management routes when granted menu_access | List Groups
Administrative capabilities that carry broader platform risk—such as security
configuration, RLS management, role definition changes, and instance-level
administration—could continue to remain Admin-only.
Use Case:
Many organizations need to separate two distinct operational responsibilities:
Platform Admin
A small set of highly trusted users responsible for:
* Instance configuration
* Security policies
* Role definitions
* RLS rules
* Integrations
* Database connections
User Account Operator
Operational staff responsible only for:
* Creating users
* Editing users
* Disabling users
* Resetting passwords
* Assigning existing roles
Without access to:
* Instance configuration
* RLS management
* Role creation/modification
* Dataset management
* Other platform administration capabilities
Suggested Direction:
Consider allowing frontend registration of:
* /users/
* /roles/
* /list_groups/
based on the corresponding menu_access permissions rather than requiring
isAdmin === true.
This would:
* Better support least-privilege deployments
* Reduce the need to grant full Admin access for routine operational tasks
* Align frontend behavior with backend authorization controls
* Eliminate the current inconsistency where backend access is permitted but
frontend navigation is blocked
Additional Context:
If there is agreement with the direction, I would be happy to contribute a PR.
I wanted to validate the use case and design intent first before proposing an
implementation that may conflict with existing project decisions.
FYI: @EnxDev @rusackas @jon-coffey
GitHub link:
https://github.com/apache/superset/discussions/44409#discussioncomment-18489843
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
