sadpandajoe commented on code in PR #43637:
URL: https://github.com/apache/superset/pull/43637#discussion_r3886253791
##########
docs/admin_docs/configuration/mcp-server.mdx:
##########
@@ -253,6 +253,57 @@ def my_custom_auth_factory(app):
MCP_AUTH_FACTORY = my_custom_auth_factory
```
+### Embedded Guest Authentication
+
+Superset's [embedded dashboards](/user-docs/using-superset/embedding) feature
mints short-lived **guest tokens** for anonymous/embedded viewers. The MCP
server can accept these same guest tokens, so an embedded guest (e.g. an in-app
chatbot next to an embedded dashboard) can call MCP tools scoped to the
dashboards/resources named in its token.
+
+This is opt-in and reuses the existing core guest-token configuration -- there
is no MCP-specific guest secret or audience.
+
+```python
+# superset_config.py
+FEATURE_FLAGS = {"EMBEDDED_SUPERSET": True} # required -- guest tokens only
exist when this is on
+MCP_EMBEDDED_GUEST_AUTH_ENABLED = True # opt-in for the MCP transport
(default False)
Review Comment:
A configured `MCP_AUTH_FACTORY` is selected before the default factory, so
it bypasses the guest-token verifier entirely. A deployment already using a
custom OIDC factory can enable these flags and still reject every guest token
unless that factory implements guest verification itself. Should this
requirement be called out here?
##########
docs/admin_docs/configuration/mcp-server.mdx:
##########
@@ -253,6 +253,57 @@ def my_custom_auth_factory(app):
MCP_AUTH_FACTORY = my_custom_auth_factory
```
+### Embedded Guest Authentication
+
+Superset's [embedded dashboards](/user-docs/using-superset/embedding) feature
mints short-lived **guest tokens** for anonymous/embedded viewers. The MCP
server can accept these same guest tokens, so an embedded guest (e.g. an in-app
chatbot next to an embedded dashboard) can call MCP tools scoped to the
dashboards/resources named in its token.
+
+This is opt-in and reuses the existing core guest-token configuration -- there
is no MCP-specific guest secret or audience.
+
+```python
+# superset_config.py
+FEATURE_FLAGS = {"EMBEDDED_SUPERSET": True} # required -- guest tokens only
exist when this is on
+MCP_EMBEDDED_GUEST_AUTH_ENABLED = True # opt-in for the MCP transport
(default False)
+```
+
+Present the guest token the same way as any other bearer token:
+
+```bash
+curl -X POST http://localhost:5008/mcp \
+ -H 'Content-Type: application/json' \
+ -H 'Authorization: Bearer YOUR_GUEST_TOKEN' \
+ -d '{"jsonrpc": "2.0", "method": "tools/list", "id": 1}'
+```
+
+**How it works**
+
+- A dedicated guest-token verifier validates the token against the same
`GUEST_TOKEN_JWT_SECRET` / `GUEST_TOKEN_JWT_ALGO` / `GUEST_TOKEN_JWT_AUDIENCE`
config used by embedded dashboards, replays the embedded structural checks, and
enforces revocation (global version bumps and per-dashboard
`guest_token_revoked_before` cutoffs). It runs *before* the JWT verifier
described above, since guest tokens are signed with a different key/algorithm
and would otherwise be rejected at the transport.
+- A verified guest resolves to a Superset guest user as the highest-priority
identity, so it's never downgraded to API-key / `MCP_DEV_USERNAME` / dev-mode
resolution. Data access is scoped by the same checks (dataset allowlist,
dashboard access, row-level security) that apply to embedded dashboard views.
+- Guests are restricted to a default-deny allow-list,
`MCP_GUEST_ALLOWED_TOOLS`, regardless of `MCP_RBAC_ENABLED`. Sensitive
enumeration tools like `find_users` and `get_instance_info` are denied simply
by being absent from the default list.
+
+```python
+# superset_config.py
+MCP_GUEST_ALLOWED_TOOLS = {
+ "get_dashboard_info",
+ "get_dashboard_layout",
+ "list_dashboards",
+ "list_charts",
+ "get_chart_info",
+ "get_chart_data",
+ "get_chart_preview",
+} # default
+```
+
+**Deployment requirements**
+
+- The MCP server and the service that mints guest tokens (the Superset web
app) must share `GUEST_TOKEN_JWT_SECRET` and `GUEST_TOKEN_JWT_AUDIENCE`. Set
`GUEST_TOKEN_JWT_AUDIENCE` explicitly -- if it's unset, audience validation
falls back to the URL host, which can differ between the two services and cause
every guest token to fail validation.
+- The `GUEST_ROLE_NAME` role (default `Public`) must exist -- a guest token is
rejected if it does not.
+- Don't set `MCP_DEV_USERNAME` on a deployment that also serves embedded
guests.
+- Restart the MCP process after toggling `EMBEDDED_SUPERSET` or
`MCP_EMBEDDED_GUEST_AUTH_ENABLED` -- guest auth is wired up once at startup.
+
+:::warning
+`GUEST_TOKEN_JWT_SECRET` guards both the web embedding and MCP guest-auth
surfaces. Never leave it at its insecure default in production -- anyone who
knows the default can forge guest tokens accepted by either.
Review Comment:
With guest auth enabled, the default `GUEST_TOKEN_JWT_SECRET` does not
merely permit forgery: startup raises `MCPAuthConfigError` and the MCP service
never accepts requests. Should this say that a non-default secret is required
before enabling guest auth, so the configuration example does not lead a fresh
deployment to fail at startup?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
