MCP server: how to map the JWT identity to a Superset user? (MCP_USER_RESOLVER in docs, not found in code)

[geovanasullivan]

Version: Apache Superset 6.1.0. MCP started with superset mcp run, MCP_AUTH_ENABLED=True, JWT validation.

What I expected: following the MCP server docs, the sub claim of the token identifies the Superset user, so each person’s RBAC applies.

What happens: the JWT is validated, but nothing maps sub to a Superset user. Every tool call fails with “No authenticated user found” unless I set MCP_DEV_USERNAME. With it set, every token acts as the same user, so there is no per-user RBAC or auditing.

Docs vs code: the docs mention MCP_USER_RESOLVER. I searched the repository for it and found no results.

Questions:

• Does MCP_USER_RESOLVER exist? If so, in which release (or branch) is it available?
• Is there a supported way in 6.1.0 to map the token identity to a Superset user?
• What is the recommended setup for multi-user access until then? (We would like to avoid everyone acting as a single shared user.)

@dosu

[dosubot[bot]]

The organization that owns this space has reached its limit of 200 credits per month. Usage will reset on 2026-11-01. Please contact an owner or admin of that organization to upgrade its plan. Upgrading a different organization will not change this space's limit.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[nicholas-greenwood]

the docs list MCP_USER_RESOLVER, but it is not wired up in 6.1.0. 6.1.0's get_user_from_request() only checks an existing g.user and MCP_DEV_USERNAME. adding a resolver to superset_config.py won't connect the validated jwt to a user in that version

the resolver was added in #38747. MCP_USER_RESOLVER is used on master and in 7.0.0rc2's auth code. 7.0.0rc2 is a prerelease, so i'd test it in staging before considering an upgrade

in that implementation, MCP_USER_RESOLVER(app, access_token) returns an existing superset username. the default resolver checks preferred_username, username, email, then sub. if an opaque sub doesn't match your superset usernames, you'll need an explicit mapping

the users must already exist. unknown identities are rejected

for multi-user access:

• leave MCP_DEV_USERNAME unset
• set MCP_RBAC_ENABLED = True
• bind jwt validation to your issuer and mcp audience

if you trust multiple issuers, map using both iss and sub. otherwise, 2 issuers could resolve the same subject to the wrong account

before exposing the service, test with 2 users who have different dataset permissions. include concurrent calls and check their audit user ids

if you need to stay on stable 6.1.0, i'm afraid there's no configuration-only fix for multi-user identity in its mcp authentication code. i'd keep multi-user mcp disabled until you have a reviewed backport or a stable release containing the resolver. MCP_DEV_USERNAME would keep everyone acting as the same user

cheers

[FrancescoCastaldi]

To answer your questions directly:

1. Does MCP_USER_RESOLVER exist?
   Yes, but it was introduced in pull request fix(mcp): prevent stale g.user from causing user impersonation across tool calls #38747 for the Superset 7.0 development cycle (master and 7.0 release candidates). In the 6.1.0 release tag, superset/mcp_service/auth.py only implements authentication via g.user or fallback to MCP_DEV_USERNAME. The documentation was updated ahead of the code backport.

2. Is there a supported way in 6.1.0 to map token identity without upgrading?
   In 6.1.0 there is no native configuration key for user resolution. However, you can inject the resolver dynamically in superset_config.py by monkeypatching the MCP authentication function during startup:

# superset_config.py
from superset.extensions import security_manager
from flask import g

def patch_mcp_auth():
    try:
        import superset.mcp_service.auth as mcp_auth
        original_get_user = mcp_auth.get_user_from_request

        def custom_get_user_from_request():
            user = original_get_user()
            if user:
                return user
            
            # Extract JWT from Authorization header
            from fastmcp.server.dependencies import get_access_token
            token = get_access_token()
            if token and hasattr(token, "claims"):
                username = token.claims.get("preferred_username") or token.claims.get("sub")
                if username:
                    resolved_user = security_manager.find_user(username=username)
                    if resolved_user:
                        return resolved_user
            return None

        mcp_auth.get_user_from_request = custom_get_user_from_request
    except (ImportError, AttributeError):
        pass

# Execute during config evaluation
patch_mcp_auth()

3. Recommended Multi-User Setup:
   If you cannot patch 6.1.0 or upgrade to the 7.0 release line:

• Keep MCP_DEV_USERNAME = None in production environments to avoid privilege escalation.
• Run the MCP server behind an API gateway or reverse proxy that validates the user session and proxies requests with user context.
• When migrating to 7.0, configure the native MCP_USER_RESOLVER function in superset_config.py taking (app, access_token) and returning the corresponding username from your directory.