suddjian opened a new issue #17187:
URL: https://github.com/apache/superset/issues/17187
## [SIP-75] Proposal for Embeddable Dashboards
### Motivation
Embedding Superset dashboards into a third-party application is currently
only possible if the dashboard is made public. We would like to add a feature
to integrate dashboards into third-party applications ("Host Apps") with
authentication handled by the third party.
There should be no need to log in to an integrated dashboard if the user is
already logged in to the Host App.
Example use cases:
- A storefront wants to offer engagement metrics to each of its vendors,
integrated into the store management experience.
- A bank wants to offer a financial wellness dashboard to account holders.
Superset currently allows for a variety of valid strategies for granting API
access, which can include various types of API Keys, depending on the
deployment. Rather than force a specific API Key system into Superset, we’ve
designed this spec to be agnostic to those details and depend on the existing
security manager features as much as possible.
### Proposed Change
1. Dashboard creator marks their dashboard as "embedded" in the dashboard
UI. This design isn’t done yet, but it’ll likely be a modal or a new panel in
the edit mode sidebar. Dashboard creator defines a list of allowed referrer
domains.
1. Introduce a new endpoint `POST /embedded-resource/`, which takes user
information, returns a short-lived embed url including proof of being generated
by Superset. This url will grant access to the resource.
1. Example embed url:
`https://example.org/superset/dashboard/123/embed?menu=0&title=0&rls=(team:a)×tamp=1234567890&sig=blahblahblahblahblah`.
It contains parameters controlling ui behavior, a timestamp so that the url
will expire, and row-level-security parameters (could be encoded either as
filter literals or as a RLS rule id). Lastly, Superset signs the url including
the query and appends the result as the `sig` parameter.
1. The Host App is responsible for loading the embed url in an iframe for
the correct user and exposing the url to no one else.
1. Browser loads the Superset url in the iframe. Superset backend checks the
signature to ensure that it generated this url, that the url is not expired,
and that the referrer is allowed.
1. Superset issues a jwt to the embedded user for use as authentication in
subsequent requests. This token includes user info, dashboard id, and rls info.
This logically separates embedded users from regular users, and prevents their
info from filling up tables in Superset.
1. When a request is made using a jwt embedded auth token, security manager
will use the information in the jwt to do its checks.
### New or Changed Public Interfaces
`POST /embedded-resource/` endpoint
### New dependencies
flask-jwt-extended for handling jwt embed tokens
### Migration Plan and Compatibility
Will create new table `embedded_dashboards` containing a dashboard id
reference, an allowlist of referrers, and
### Rejected Alternatives
OAuth login - requires users to sign in to the iframe, lower UX
Generating a url or token in the Host App - better to keep generation on
Superset side to avoid exposing implementation details, and so that we don’t
have to define a specific API key spec
--
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]
