GitHub user FrancescoCastaldi added a comment to the discussion: RBAC-only with
a non-empty scope for the MCP server
The issue happens because `_get_token_scopes()` in
`superset/mcp_service/auth.py` returns `None` (which triggers the pure RBAC
fallback) only when the token has no scopes at all. As soon as standard OIDC
identity scopes like `openid` or `profile` are present, `_token_scope_allows()`
evaluates them against Superset permissions. For tools that do not define an
explicit `class_permission_name` (such as `quickstart_prompt`), the logic falls
back to requiring the broad method scope `superset:read` or `superset:write`.
Because standard IdP scopes do not match `superset:read`, the request is denied.
Between the two PR approaches you suggested, filtering out non-Superset scopes
by returning `None` when no recognized scopes remain carries a security
trade-off: an administrator who intends to restrict access using a scoped token
would inadvertently have scope enforcement completely bypassed if their scope
names are mistyped or unrecognized, dropping straight down to pure RBAC.
A cleaner, maintainer-aligned architecture consists of two parts:
1. **Explicit Scope Exclusion or Translation in Configuration:**
In `superset_config.py`, support an explicit list of generic identity scopes to
ignore before evaluating permission scopes, for example:
```python
# superset_config.py
MCP_IGNORED_SCOPES = {"openid", "profile", "email", "offline_access"}
```
In `_get_token_scopes()`, strip those identity scopes first. If the remaining
set of scopes is empty, and the deployment is configured for RBAC-only
fallback, you can safely return `None`.
2. **Assigning Base Class Permissions to Permission-less Tools:**
In `superset/mcp_service/server.py`, assigning an explicit class permission to
tools like `quickstart_prompt` (such as `class_permission_name="Superset"`)
ensures that standard RBAC permissions (`can_read on Superset`) govern the tool
consistently without triggering the permission-less scope denial.
If your IdP allows custom scope mappings, the immediate solution without
modifying Superset core is to configure the client scope mapping in your IdP to
append `superset:read` (and `superset:write` if needed) to the issued access
token.
GitHub link:
https://github.com/apache/superset/discussions/45673#discussioncomment-19164442
----
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]
