Signed Embeds Clarification + GitHub Reference Apps

Please forgive the "Is the sky blue?" line of questions, as a noob it's worth verifying my understanding of Metabase functionality.

Access to a signed embed is controlled via a login within the embed that verifies an end user's Metabase UN & PW, is that correct?

Permissions set by the Admin control what a signed embed end user can and cannot see, is that correct?

Groups of users with common permissions can all see the same signed embed, is that correct?

Each user can filter a signed embed dashboard, for example, independently of other users within the same group such that users A and B can simultaneously drill down on one or more selections of a category to see specific KPIs without interfering with what the other is viewing, is that correct?

How does one use the embedding-reference-apps on GitHub? The directions are bit thin for those with little to no experience in downloading and applying such things from GitHub.

Are there any other helpful references to signed embeds besides those below?

https://www.metabase.com/embedding/
https://www.metabase.com/blog/Embed-Metabase/

Hi @mesquest,

No problem - just ask away (we all start out from scratch here)

Per my understanding (and I didn’t have any hands on this part - yet) you’re close, but it’s not exactly username/password being handed between the embedding application and the dashboard or question of Metabase you embed. It’s just being signed using a secret token from Metabase used by your application.

The signature handed over from your embedding app can include parameters though and those can include a locked parameter that maps to a e.g. user or group id or anything that you use to filter/restrict what that given user logged into your embedding application will see. It’s entirely up to you and your embedding application to define that mapping logic based on user identity in you embedding app - so not directly linked to Metabase UN/PW - but an access besides that.

I think you found many of the right links. Key to the whole restriction of access is quite well captured in the last Q&A in Embedd cards/dashboard in other applications - #4 by romain

Groups of users with common permissions can all see the same signed embed, is that correct?

Yes as long as you are only referring to groups of users on your embedding applications side of the fence? It has nothing to do with users and groups defined to log directly into the Metabase application - those are separate concepts.

Which of the langagages given there (or Java or C# if you look around for examples shared here in Metabase discourse) are you most comfortable working with - in particular in the context of standing up a simple webapp? I would take that and deploy that as a webapp. Note security for this hinges on that it’s all embedded in a secure server side application because the encryption with the token shared from Metabase has to be locked away from prying eyes.

For my intended purposes ‘users’ are those who view dashboards applying multiple filters to drill down to what they want to see. For groups of users A (basic), B (premium), and C (professional) each must have increasing amounts of information available to them.

Ideally ‘users’ would be able to customize choice of cards, positioning, sizing, formatting, etc. and be able to download csv directly from the dashboard cards without ever logging into Metabase. For the time being this can be set aside but the control of which group of users sees what level of information in the final dashboard(s) is the #1 requirement.

So how much of this can I do via Metabase and how much (and how) can I do this via some other means?

If you have your users already logged into your app embedding Metabase (as this thread started with) you can divide your users into the A, B, C groups and either limit what they can see based on different pages A, B1, B2, C as needed.

For them to be able to customize their dashboard pages themselves then we are not talking embedding but that they log into Metabase directly and you then control access based on what access you give them inside Metabase. You can easily experiment with that yourself. Similarly with CSV download. I think there’s already a feature request on GitHub for CSV download from embedded pages though.

Thank you so much Jornh, I appreciate your input.

In addition to your suggestion there may be a way to combine this per the response to the following post by passing the user id and or group id to a locked parameter within the embed. Does that sound viable?

PS, Oh, yes, you indicated as much in this post to AndrewMBaines! Now how to tie that to a group, a Metabase group or some group defined elsewhere?... It has possibilities, I'll have to study this.