Re: [D] Superset Embedded SDK [superset]

["LiamTorrelli (via GitHub)" <gi...@apache.org>]

GitHub user LiamTorrelli added a comment to the discussion: Superset Embedded SDK

Short version of what the embedded SDK actually does, and then the tenant-role question — because that's the part that trips people up.

**What it's for**

`@superset-ui/embedded-sdk` mounts a Superset dashboard in a cross-origin `<iframe>` inside your app. The user never logs into Superset directly. Your backend mints a short-lived **guest JWT**, the SDK passes it over `postMessage`, and Superset spins up an anonymous session inside the frame.

Superset does **not** hand guest tokens to the browser. Your app calls `/api/v1/security/guest_token/` server-to-server (with a privileged service account), gets the JWT back, and your `fetchGuestToken` callback returns it to the client.

Minimal client side:

```javascript
import { embedDashboard } from "@superset-ui/embedded-sdk";

embedDashboard({
  id: "<dashboard-uuid-from-embed-modal>",
  supersetDomain: "https://superset.example.com",
  mountPoint: document.getElementById("analytics-container"),
  fetchGuestToken: () =>
    fetch("/api/superset-guest-token").then((r) => r.text()),
  dashboardUiConfig: { hideTitle: true },
});
```

Server side you POST something like:

```json
{
  "user": { "username": "tenant_acme_viewer" },
  "resources": [{ "type": "dashboard", "id": "<uuid>" }],
  "rls": [{ "clause": "tenant_id = 'acme'" }]
}
```

Signed with `GUEST_TOKEN_JWT_SECRET`. Default expiry is 300 seconds.

**Your tenant-role question**

No — a guest token does **not** map to your existing tenant FAB roles the way normal DB auth does.

Every guest session gets whatever role `GUEST_ROLE_NAME` points at (default `Public`, a lot of teams bump it to `Gamma` when charts come back empty). Your per-tenant roles in Superset are bypassed for the iframe session.

Multi-tenant access is enforced in **your token-minting code**, not by picking a Superset role:

1. User logs into **your** app (DB auth, SSO, whatever).
2. Your backend resolves tenant → allowed dashboard UUIDs for that tenant.
3. You mint a guest token whose `resources` list only includes those dashboards, and whose `rls` clauses scope the SQL (e.g. `organization_id = 123`).
4. Optional: `GUEST_TOKEN_VALIDATOR_HOOK` in `superset_config.py` to reject tokens that arrive without tenant scoping.

So tenant A never gets tenant B's dashboards because your API never puts them in the payload — not because Superset evaluated their FAB role inside the iframe.

The trap: treating the guest token as "extend my logged-in user into Superset." It's a second auth system. Your app's session and the iframe JWT are parallel. RLS in the token is synthetic — whatever string your backend injects gets compiled into every query. Stale or missing clauses leak data even when the UI looks fine.

**Before it works at all**

`EMBEDDED_SUPERSET = True`, rotate `GUEST_TOKEN_JWT_SECRET`, CORS + Talisman/`frame-ancestors`, and add your parent origin in the dashboard Embed modal **Allowed Domains**. Missing any of those and you'll debug iframe errors before you ever get to tenant logic.

We wrote up the full flow — `embedDashboard()` lifecycle, postMessage handshake, RLS, and all nine server switches: https://www.drafted.work/blog/superset-embedded-sdk-guest-tokens

GitHub link: https://github.com/apache/superset/discussions/36975#discussioncomment-17322069

----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org