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:
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:
Support custom domains for QuickSight when SSO is configured.
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.
I would suggest opening up a support case with AWS so that they can dive deeper and get a better understanding.
Here are the steps to open a support case. If your company has someone who manages your AWS account, you might not have direct access to AWS Support and will need to raise an internal ticket to your IT team or whomever manages your AWS account. They should be able to open an AWS Support case on your behalf.
Do you mean open an AWS Support ticket to make a feature request for the QuickSight product? If so, I certainly will do that but I wanted to understand a few things first:
Is my understanding of the way QuickSight currently works correct? That is, double check if I missed or misunderstood some part of the QuickSight âź· SSO integration or the ability to configure it.
If so, is the QuickSight team aware of the situation, do they consider it an issue and if so are there any plans to address it?
More broadly, how are other folks in the QuickSight Community working around the problem of sharing dashboard URLs with SSO enabled?
I’m really not clear how any organisation of a reasonable size can train users to remember an account name/directory alias to access BI data.
Hi @reporting - You mentioned that you are using Service Provider (SP) initiated SSO, which is the right way to do this since then, QuickSight knows which SSO service you are using and your users can visit a QuickSight URL that has the account name (aka directory alias) in it, and QS will redirect your user to the SSO page. I think your point is that your users may not know the name of your quicksight account, which I understand is a realistic situation though is a bit harder to deal with.
It looks like you discovered that you can add the account name into the URL manually (by adding “&directory_alias=blah” to the end of the URL), and this is automatically added to URLs contained in links you find in an emailed report or the notification you receive that a dashboard has been shared with you for instance, but does not get automatically built into the URL you see in your browser when on a dashboard page if someone were to just copy/paste it.
Vanity/custom domains for your specific QS account are in consideration by the product team, though I dont have an ETA to share with you.
Aside from user education as well as hoping the user will know they could also access QS via your SSO portal and then opening the dashboard link again, we would need to implement one of your two suggestions, which are both spot on.