Last updated: November 2, 2026
You need a clear way to share dashboards without exposing them to the wrong audience. If you embed analytics in a customer portal, the access rule should be decided before the dashboard loads.
How to protect embedded dashboards with SSO or share signed public links that expire: use SSO when a signed-in user should see tenant-specific data inside your portal, and use a signed link when access should be temporary. SSO ties access to a person. An expiring link ties access to a share event and stops working on schedule.
- Use SSO for recurring portal users.
- Use expiring links for short-term sharing.
- Define tenant, role, and filter rules once.
- Keep the dashboard in your BI vendor.
- Choose the simplest access model that fits the job.
How do you protect embedded dashboards with SSO or expiring links?
You protect embedded dashboards by making identity and time limits part of the embed itself. With SSO, the user signs in once and enters the portal as an authenticated tenant member. With a signed public link, the URL carries a time-bound permission and stops working after expiry.
This is the core problem Embedportal is built around as the embedding layer for customer-facing analytics. It sits between your existing data and your existing BI tools, so you do not have to build a multi-tenant distribution layer yourself. For a broader view of the build-or-buy decision, read why teams stop building embedded BI from scratch.
What does SSO protect?
SSO protects the login step. The user proves identity through your existing sign-in flow, then the portal can map that identity to a tenant, a role, and the right filter attributes. That is useful when users should return often and should always see the same branded experience.
What does an expiring link protect?
An expiring link protects the sharing window. It is better for a short review cycle, a handoff, or a one-time view where you do not want to maintain an ongoing account relationship. The trade-off is simple: convenience goes up, but so does the need to keep expiry short and well defined.
When should you use SSO vs signed public links?
Use SSO when access should follow a person. Use a signed public link when access should follow a specific share event. If you are unsure, start with the stricter option, because the lighter option should only exist when a temporary link is truly enough.
The comparison below is a practical way to choose.
| Access model | Best for | Trade-off |
|---|---|---|
| SSO | Logged-in portal users | Requires your sign-in flow to be in place |
| Signed public link | Temporary external sharing | Access ends when the link expires |
| Neither | Internal-only dashboards | Not suitable for customer-facing use |
If you are still deciding on the portal layer itself, review what to look for in an embedded analytics platform. If your question is specifically about sign-in flow, this SSO guide for embedded dashboards is the next step.
How does Embedportal handle tenant-based access?
Embedportal uses one JSON configuration where you define tenants, roles, and filter attributes. That keeps the access model in one place instead of spreading rules across separate vendor-specific setups. It also means you are defining the distribution layer, not moving the dashboard out of your BI vendor.
Dashboards stay stored in your own BI vendor. Embedportal handles the distribution layer only, and it supports Tableau, Power BI, QuickSight, and Metabase. You embed via a React component or iframe using dashboardId and tenantId, so the portal knows which dashboard and which tenant context to load.
Why define tenant, role, and filter attributes together?
Because the same user can need different visibility in different tenants. A single configuration helps you keep the model consistent across portals and vendors. It also gives you one place to reason about who should see which dashboard and which filtered slice of data.
How is this different from rebuilding embeds in React?
Rebuilding the entire experience in React means you own the distribution logic, the tenant mapping, and the vendor-specific differences. Embedportal is intended for SaaS products that want customer-facing analytics without rebuilding BI in React, and for data teams that want to distribute dashboards without duplicating them.
How do branded portals keep access control and branding aligned?
They keep both in the same portal layer. Embedportal supports branding with colors, logo, and typography, and each organization can keep its own theme. That matters when users switch tenants, because they should not see another brand during the transition.
For agencies and consultancies, that makes client reporting easier to present under one identity. For internal portals, it helps you unify dashboards across vendors under one URL. If branding is part of your evaluation, compare the portal approach with the guidance in the embedded analytics dashboard guide.
What changes when the tenant changes?
The visible experience changes with the tenant theme and the tenant rules. The embedded dashboard remains the same asset in your BI vendor, but the portal applies the right context at load time. That is the difference between a dashboard that is merely visible and one that is correctly distributed.
When is a native vendor embed or simpler setup better?
A native vendor embed is better when you only need one BI tool, one portal, and a simple distribution path. A simpler in-house setup is better when your access model is minimal and your team already owns the full integration burden. If you do not need multi-vendor distribution, a portal layer may be more than you need.
That trade-off matters. If you only serve one audience and one dashboard stack, the shortest path is often the right one. If you need to coordinate Tableau, Power BI, QuickSight, and Metabase in one branded experience, one integration surface is easier than building and maintaining four separate paths.
How do you decide quickly?
- Count the BI vendors you must support.
- Count the tenants or client groups you must isolate.
- Decide whether access is ongoing or temporary.
- Choose SSO for ongoing access and expiring links for short-term sharing.
- Use a portal layer only if the distribution problem is bigger than one team can safely own.
For a more detailed decision framework, see the guide to API embedded dashboards and multi-vendor analytics. If you want to understand the operational side, SSO and security for embedded analytics is relevant too.
What should you check before you go live?
Check the access path first, then the tenant mapping, then the expiry behavior. You want the dashboard to load only for the right user or the right share window. You also want the theme, role, and filter attributes to match the intended tenant every time.
If you are embedding QuickSight specifically, review how QuickSight session tags work in embedded dashboards. If you want to see the operational layer in practice, the row-level security for embedded dashboards page is a useful companion.
What is the minimum test plan?
Test a valid SSO user, an invalid user, a valid signed link before expiry, and the same link after expiry. Then switch tenants and confirm that the branding and filters change as expected. The goal is not to test everything at once. The goal is to prove that access ends when it should.
For a product walkthrough, Embedportal offers a fifteen-minute session where a customer dashboard is embedded live into a demo portal. If you want to see the flow in action, visit Embedportal.
Protecting embedded dashboards is mostly about choosing the right control point. SSO fits recurring authenticated users. Expiring links fit temporary sharing. If you need one place to define tenants, roles, and filter attributes across multiple BI vendors, a portal layer is the cleaner path.
See it in action at embedportal.com.
Frequently Asked Questions
When should you use SSO for an embedded dashboard?
Use SSO when access should follow a signed-in person across repeated visits. It is the right fit for portal users who should see tenant-specific data, a branded experience, and the same permissions each time they return. SSO ties the embed to identity instead of to a one-off share.
When is a signed public link better than SSO?
A signed public link is better when access should be temporary and tied to a specific share event. Use it for reviews, handoffs, or short-term external access. The link should expire on a fixed schedule, so the dashboard stops loading after the approved window ends.
What should you test before you go live?
Test four cases before launch: a valid SSO user, an invalid user, a valid signed link before expiry, and the same link after expiry. Then switch tenants and confirm that the right branding, filters, and dashboard context appear. That gives you a simple check that access ends when it should.
Do you need to rebuild dashboards in React to support tenant-based access?
No. You do not need to rebuild the dashboard itself in React just to control access. Keep the dashboard in your BI vendor and manage the distribution layer separately. That keeps tenant mapping, roles, and filter attributes in one place instead of duplicating logic across screens.
How does a portal layer help with multi-vendor BI?
A portal layer gives you one integration surface for multiple BI tools, so you are not building the same multi-tenant logic four times. That is useful when your stack includes Tableau, Power BI, QuickSight, or Metabase and you need one branded place to distribute them.
