Share "direct" dashboard URLs which fully handle SSO authentication when required

Currently, my QuickSight account has Service Provider Initiated SSO & email syncing for federated user turned on. Our company uses Azure AD as the IdP so our redirect URL parameter is set to RelayState.

This allows our reporting team to share SP initiated URLs like this around the business and users are automatically authenticated & created if required:

https://myapps.microsoft.com/signin/APP_ID?tenantId=TENANT_ID&RelayState=https://eu-west-1.quicksight.aws.amazon.com/sn/dashboards/DASHBOARD_ID

This let’s anyone from across the business view crucial reporting data without involvement from the reporting team.

The problem comes when a user copies & pastes a “direct” QuickSight dashboard URL (i.e. https://eu-west-1.quicksight.aws.amazon.com/sn/dashboards/DASHBOARD_ID) and shares it with someone else in the business who tries to navigate to it.

Instead of being seamlessly authenticated and taken to the data, they’ll be dumped at the QuickSight login screen and unable to proceed if they don’t know what the QuickSight account name is. This results in support tickets to internal IT teams saying that “reporting is broken”.

It seems to me there is a gap in the UX here as it should be possible to share links to dashboards without all users across the business needing to remember a “special string” (directory alias) to gain access.

Am I missing anything in the docs to handle this case? How are others solving this problem?


As I see it, the solution to this problem is to have the URL contain all necessary information to automatically perform IdP authentication if required.

My suggestions, in order of preference:

  1. Support custom domains for QuickSight when SSO is configured.
  2. Embed the directory alias in the URL for all QuickSight frontend routes (e.g. https://quicksight.aws.amazon.com/sn/directory_alias/DIRECTORY_ALIAS/dashboards/ID)

In both cases it’s easy for the server-side code to build and return the authorize URL. The frontend code can then perform a simple browser redirect if required.

Has anything like this been considered?