Open-source alternative to Tableau embedded analytics

The host server does the authentication. Your application logs in its own user through the identity system you already run, decides which dashboard that user may see, and then calls Superset's /api/v1/security/guest_token/ endpoint using a service account. The request carries the dashboard identifier and the row-level rules that restrict what the viewer can see, for example a clause that limits a sales dashboard to one customer's region. Superset returns a short-lived guest token, and the host passes that token to the browser, where the @superset-ui/embedded-sdk package mounts the dashboard. The browser never holds the service account credentials. Confirm the token lifetime and the exact request fields against the current embedding documentation for the Superset version you deploy, because these details change between releases.

Three controls decide whether this design holds up. First, the guest token endpoint must never be called from client-side code, since anyone who can read the browser's network traffic could then request tokens with arbitrary rules. Second, the EMBEDDED_SUPERSET feature flag must be set to True in the Superset configuration, or the embedded SDK and the guest token endpoint stay unavailable. Third, each embedded dashboard has an Allowed Domains setting, and an empty list accepts requests from any origin. Set it to the exact host names of your portal for production, and test from an unlisted origin to confirm the request is refused. Review the Superset embedding documentation before you finalize these settings.

Row-level rules are only as reliable as the values the host sends. If your application builds the rule from a client-supplied tenant identifier, a viewer can change that value and see another customer's rows, so the host must derive the tenant from its server-side session. Plan a test matrix with at least two tenants and check that each guest token returns only that tenant's data in the database query, not just in the chart. Ask your implementation partner or internal team to document who owns the service account, how its secret is rotated, and how token issuance is logged. These decisions belong in the host's identity and tenancy design, and they should be reviewed before the first customer sees a dashboard.

The most important point is that tenant isolation is the vendor's application responsibility, not something the BI tool does for you. In a Superset embedding, the host application's server requests a guest token from /api/v1/security/guest_token/ using a service account, and that request carries the row-level security rules that decide which rows an embedded viewer can see. If the host omits a rule, a filter is built with the wrong value, or the token is requested from client-side code, the viewer may see another customer's rows with no error raised. Treat each guest token request as a data access decision, and write tests that prove one tenant's token cannot return another tenant's records. Also decide early between a shared dataset filtered by row-level rules and separate datasets or databases per tenant. The shared model is easier to operate, but a single missing rule exposes data; separate datasets reduce that blast radius at the cost of more objects to manage. Lock down each dashboard's Allowed Domains setting, because an empty list permits any origin.

Identity mapping has to be designed on both sides of the token. Superset's AUTH_ROLES_MAPPING maps LDAP or OAuth groups to roles for people who sign in to Superset itself, and that mapping is useful for internal analysts. Customers viewing an embedded dashboard usually do not hold Superset accounts at all, so their access is defined by the guest token claims that the host builds from its own session. Confirm with your identity team which claims the host trusts, how they are validated, and what happens when a customer's account is disabled between token issue and expiry. Keep the host's session, token lifetime and tenant identifier in one code path so that a change to one does not silently break the others. Metabase handles this differently: its open source and Starter plans lack JWT, SAML and SCIM, and row and column permissions require Pro or Enterprise, so confirm the plan before you design the identity flow around those features.

Secrets and audit trails need the same discipline. Superset requires a user-specified SECRET_KEY to start, and PREVIOUS_SECRET_KEY supports rotation, so store the key and the service account credentials in a secrets manager, restrict who can read them, and rehearse rotation in staging before you need it. Rotate the service account credential on a schedule your security policy sets, and remove it from build logs and client bundles. For audit logging, decide what must be recorded: which customer or user requested a token, which dashboard and filter values were applied, and when. Superset's own logs and the host's logs record different events, so confirm with your security team which layer is the system of record. Metabase's usage analytics and auditing sit in the paid Pro and Enterprise plans, so confirm whether the open source edition meets your evidence needs before you rely on it.

DeployOpen plans, implements, integrates, hardens, backs up and documents a self-hosted Apache Superset or Metabase deployment inside your own cloud account, data center or air-gapped network. For an embedded layer, the first scoping decision is which tool fits the tenancy model: Superset's embedded SDK with guest tokens and row-level security, or Metabase embedding under a plan that includes the permissions and identity features you need. Scope also has to name the host application that requests tokens, the identity provider behind it, and the tenant identifiers that drive row-level rules. Engagements are fixed-scope, with those decisions, deliverables and timelines agreed in writing before work starts.

The build concentrates on the boundary between your application and the analytics server. The token-issuing service runs server side under a dedicated service account that calls /api/v1/security/guest_token/, and the EMBEDDED_SUPERSET flag must be enabled first. Each dashboard's Allowed Domains list is set to your production origins rather than left empty, and row-level rules are generated from the authenticated tenant, never from values the browser supplies. Metadata storage goes on PostgreSQL or MySQL, with the caching layer and Celery workers added where alerts, async queries or thumbnails are needed. Secrets such as SECRET_KEY are managed outside source control, and the upgrade path is documented before go-live.

Testing covers the embed and its tenant boundaries as an attacker would approach them. DeployOpen's security testing team can check whether a token issued for one tenant can read another tenant's rows through filters, URL parameters or cached results, whether origin restrictions hold, and whether the token service rejects unauthenticated requests. Ask for written test scope, the environments used, and how findings are retested. Retainers can then cover version upgrades, which Superset's upgrade documentation describes as a staged process with a metadata database backup and staging test first.