We’re setting up QuickSight for sharing dashboards with external users and just had one question. We plan creating registered users using an email addresses managed by us with some sort of abbreviation (like userforourservice+4@amazon.com) for the registered accounts.
After creating the account we just made a call to “generate embed url for registered user” using the new user we created and it works, the account looks to be active with a “last active” date showing as well as a “reset password” option. We are assuming it generated some sort of random password when the api call was made.
Does this mean we’re all good? Using that account will be fine?
This way of doing things would really make our lives easier, as we wouldn’t have to deal with passwords for each account.
That’s how we do it for our SaaS application and it works perfectly for us. Our users can access the embedded dashboards by simply logging in to the application and don’t need to enter a separate QuickSight password.
Hi @apiyaral, The approach of generating email addresses like ‘userforourservice+4@amazon.com’ and creating registered users with the API should work fine. QuickSight will generate a random password for each new user created this way. These generated users will be fully functional QuickSight users that can log in and access shared dashboards/content. The only caveat is that since you don’t know their passwords, password resets and login would need to be handled programmatically through the API.
For security best practices, be sure to implement secure handling of API credentials/keys used to create the users and generate embed URLs. You don’t want to expose the ability to add users or generate shareable links.
Some of the behavior depends on the authentication method and identity provider that you are choosing. Assuming for now, that you leverage non-IAM QuickSight managed users (i.e., IdentityType = QUICKSIGHT).
While you can create users via the RegisterUser - Amazon QuickSight API, those users will (as of now) remain in status inactive unless their registration is confirmed and password set via the UserInvitationUrl that is part of the API call’s reponse. While this is no general problem in an embedding use case, some functionality (e.g. sending out e-mail reports) is not supported for users that are flagged as Active: false (as part of the ListUsers - Amazon QuickSight response).
All of that said, given the nature of how you were planning to set the email addresses, it seems like you were anyway not planning to leverage QuickSight’s e-mailing capabilities in your use case, right? However, there is also no need to create additional e-mail addresses that you manage. You will get the same behavior when using the end users’ actual e-mail address (unless other requirements force you to not use them within your QuickSight setup). An example reason for such a requirement could be: Admins can resend invitations via the UI. If you don’t want this to ever be possible, you might not want to use the end user’s actual e-mail address.
Did this answer your question? If so, please help the community out by marking this answer as “Solution!”. Thanks!