Granting QuickSight access to federated users
When you use federated identities, you can manage users with an external identity provider (IdP) to authenticate users when they sign in to Amazon QuickSight. QuickSight supports identity federation with SAML 2.0. Many external IdPs, such as Okta and Ping, use this standard. You can also use AWS IAM Identity Center as your external IdP for a SAML 2.0 federation approach to QuickSight access. However, we recommend the built-in service integration discussed in IAM Identity Center integration in this guide instead of the federated user approach. If you use IAM Identity Center, the federated user approach is only recommended if you cannot use IAM Identity Center integration due to current feature limitations.
Federated users have a single sign-on (SSO) experience, and you can grant access to
QuickSight without creating an AWS Identity and Access Management (IAM) user or QuickSight local user for each person
in your organization. In addition, federation provides users with temporary credentials,
which is a security best
practice. For more information about identity federation and its benefits and
use cases, see Identity federation in
AWS
When configuring access to QuickSight for federated users, you can use one of the following approaches:
Both of these approaches allow federated users to self-provision access to QuickSight. The approaches vary based on the architecture and services used for federation. However, in both solutions, the federated user then assumes an IAM role that determines which permissions they have in QuickSight.
When you use QuickSight Enterprise edition, you can force users who are self-provisioning their access to sign in to QuickSight by using the email address defined in the identity provider. For more information, see QuickSight email synchronization for federated users.
