Manage access to insights with an account instance of AWS IAM Identity Center and Amazon QuickSight

AWS IAM Identity Center enables administrators to securely create or connect workforce identities and manage their access across AWS accounts and applications. With IAM Identity Center, you can create and manage user identities in AWS, or connect your existing identity source, including Microsoft Active Directory, Okta, Ping Identity, JumpCloud, Google Workspace, Microsoft Entra ID, and more. It simplifies access management to AWS applications.

An instance is a single deployment of IAM Identity Center. There are two types of instances available for IAM Identity Center:

• Organization instance – When you enable IAM Identity Center in conjunction with AWS Organizations, you’re creating an organization instance of IAM Identity Center. An organization instance is the primary and recommended method of enabling IAM Identity Center. In an organization instance, you create or connect your workforce users for use across multiple AWS accounts and applications.
• Account instance – You can create an instance of IAM Identity Center that is bound to a single AWS account, called an account instance of IAM Identity Center. Account instances are used only to manage user and group access in the single AWS account for AWS and custom managed applications. You can create an account instance from either a standalone AWS account that is not managed by Organizations or a member account in Organizations.

Amazon QuickSight is an IAM Identity Center enabled application. Administrators can create a new QuickSight account and use IAM Identity Center for managing QuickSight users and groups. IAM Identity Center can store QuickSight user and group identities within IAM Identity Center itself as an identity store, or they can configure it with a third-party identity provider (IdP) used within their organization. Administrators can use groups in their IdP to assign QuickSight roles (administrator, author, and reader) to users. After they’re successfully authenticated via IdP, users can seamlessly access QuickSight dashboards either from the QuickSight application or as an embedded component within their business applications. Having QuickSight users and groups provisioned in an IdP also helps control authorization to QuickSight resources like dashboards and datasets.

However, until now, QuickSight was only integrated with organization instances of IAM Identity Center. Today, we are expanding the capability and announcing the integration of QuickSight with account instances of IAM Identity Center. This new feature is available in all AWS Regions where QuickSight and IAM Identity Center are available.

In this post, we discuss when you should use which type of instance, the benefits of using IAM Identity Center with QuickSight, how to configure an account instance, and how to use it to access QuickSight.

When to use an organization instance or an account instance of IAM Identity Center

You can integrate QuickSight with an organization instance of IAM Identity Center to enable access to users and groups from your organization’s identity store into various AWS accounts and applications like QuickSight in Organizations. For example, assume you are using a SAML 2.0 compliant third-party IdP service like Okta to centrally manage your organization’s internal workforce user identities. Different departments in your organization use their own QuickSight accounts, or you deploy resources for separate environments like development, UAT, and production in separate QuickSight accounts. In such scenarios, you can use an organization instance to manage users and groups of an entire organization centrally in your IdP and authenticate to various AWS and QuickSight accounts centrally, as depicted in the following figure.

Account instances of IAM Identity Center are useful for the following QuickSight use cases:

• User management for an independent software vendor (ISV) business application where end-users view QuickSight dashboards only – You can centrally manage users and groups across users from various customer organizations, and enable access control to those users for resources in QuickSight and your business applications. If your AWS account where the QuickSight subscription is deployed is part of an organization that has an organization instance configured with your internal IdP, an account instance enables you to have a separate dedicated directory with the benefits of IAM Identity Center, like SAML group sync for your external customers that use the QuickSight application. This configuration is only recommended if you don’t need user isolation and don’t use the QuickSight multitenancy feature. If you plan to enable multi tenancy authoring in the same QuickSight account for multiple customers, you should not use IAM Identity Center currently.
• Your organization instance doesn’t allow provisioning external users but you have a use case that requires provisioning both internal and external users – You might need to enable access to QuickSight for a different set of users external to your organization that can’t be provisioned to your organization instance. For example, you have a Sales Compensation QuickSight dashboard that is used by both your internal employees in the sales department as well external users like sales managers in your channel partner’s organization.
• Seamless QuickSight access to users and groups across various business subsidiaries for a common project – Consider a scenario that various business subsidiaries in your organization maintain separate user identity stores, but users from different subsidiaries need to collaborate and access QuickSight for a common project. In this scenario, you can use an account instance with QuickSight, where you create all the required users and groups from various subsidiaries into an account instance. There can be various reasons for business subsidiaries choosing and maintaining separate identity stores, like regulatory compliance, subsidiaries operating in different countries, or mergers and acquisitions.
• Enabling QuickSight embedded analytics access for a trial period – Consider the example that you are offering a trial for your software as a service (SaaS) business application that is powered by QuickSight embedded analytics to prospective customers. You manage access to your application with an IdP by assigning groups that contain the users for a customer. You can provision, authorize, and de-provision trial users belonging to a prospective customer in your business application by making them members of an IdP group and granting them limited trial functionality in the business application. With an account instance, you can assign the group access to the QuickSight application. This can authorize trial users on QuickSight embedded dashboards based on this group membership. When the trial expires, you can delete the IdP group access, which removes trial users from both your application and embedded QuickSight dashboards.

In this post, we demonstrate how to build a SaaS business application powered by QuickSight embedded analytics using an account instance to manage access to insights.

Benefits of using IAM Identity Center for a business application with embedded QuickSight dashboards

If you are an ISV offering a software application that is used by business users from different customer organizations, you can manage users and groups from various customer organizations within a centralized IdP for your application. If you also offer QuickSight embedded analytics within this application, you can use IdP managed users and groups within QuickSight. By integrating QuickSight with an account instance, users and groups from the IdP are automatically synchronized by System for Cross-domain Identity Management (SCIM) to your account instance, and they become QuickSight users and groups, respectively. This is depicted in the following figure.

Integrating an account instance with QuickSight offers the following benefits:

• Credentials are stored centrally in a single identity store for your business application, QuickSight, and any other external web service components used by your business application.
• IdP groups are seamlessly synchronized to IAM Identity Center. You can use these IAM Identity Center groups within QuickSight for user-to-group membership, to simplify granting and revoking permissions to a group rather than individual member users.
• Application and resource authorization like access to QuickSight dashboards and datasets works for users and groups created in your IdP.
• Users and groups synchronized from the IdP to IAM Identity Center enable fine-grained access control in QuickSight with row-level security (RLS) and column-level security (CLS) features.

Solution overview

In this post, we demonstrate how to configure QuickSight with an account instance and provision QuickSight users and groups. After the configuration is complete, provisioning and de-provisioning of users and groups and changes in group memberships in Okta propagate automatically to QuickSight. We also demonstrate how users are authorized to access QuickSight resources and data for their organization using shared folders. The following figure illustrates this architecture.

The following are the high-level steps to configure QuickSight with an account instance and provision users:

1. Enable account instances using the AWS Management Console and create an account instance of IAM Identity Center.
2. Manage your identity source.
3. Sign up for a QuickSight subscription with IAM Identity Center.
4. Create and organize assets using folders.

Prerequisites

Before you create an account instance, make sure that none of the constraints mentioned in Account instances of IAM Identity Center are in effect that would prevent you from enabling it. For example, make sure that your administrator hasn’t created a Service Control Policy that prevents the creation of account instances.

As a prerequisite, we have already provisioned an Okta directory that we will integrate with our IAM Identity Center account instance. Refer to Integrate Okta with AWS IAM Identity Center to manage users, roles, and multi-account access for steps on how to integrate Okta with your account instance.

After you successfully integrate the Okta IdP user directory with the account instance, you create the required users and groups in Okta and configure IAM Identity Center to use Okta as the source identity store rather than provisioning users locally in IAM Identity Center.

Create an account instance

First, you need to enable IAM Identity Center in your AWS account, as demonstrated in the following screenshot.

Manage your identity source

After you create an IAM Identity Center instance for the first time, it is automatically configured to use the Identity Center directory as your default identity source. IAM Identity Center can manage users and groups either locally in an AWS Identity Center directory, or in an external IdP. In this post, we use Okta as an external IdP identity store for our business application and QuickSight.

To use IAM Identity Center with QuickSight, you must create at least three groups in Okta for QuickSight: admin, author, and reader. For illustration purposes, let’s create qs-admin-grp, qs-author-grp, and qs-reader-grp in Okta. These groups will be mapped to their respective QuickSight roles when subscribing to QuickSight with an account instance.

When using IAM Identity Center as the authentication method, QuickSight only supports single tenancy with the default namespace. The QuickSight multitenancy with isolated namespaces feature is not supported when using IAM Identity Center. To control access to QuickSight dashboards by customer, you can create one or more groups per customer organization. For example, you can add QuickSight users from the red-customer organization as members of red-customer-grp in Okta. You can grant permissions to access specific QuickSight dashboards belonging to red-customer only to red-customer-grp. Users from other customers are not added to red-customer-grp, so they lack authorization to access the red-customer QuickSight dashboards.

In our example, we create users in Okta that are in the ISV’s internal organization, red-customer organization, and blue-customer organization. We add them to their respective Okta groups specific to their organization and QuickSight role. This is illustrated in the following table.

Because IAM Identity Center is integrated with Okta, these users and groups automatically synchronize using SCIM into IAM identity Center. You can validate users and group synchronization from Okta to IAM Identity Center by logging in to IAM Identity Center, as shown in the following screenshot.

Sign up to QuickSight using IAM Identity Center for authentication

The next step is to sign up and configure QuickSight to use the groups you created and manage access using Okta groups.

If you already signed up for QuickSight using other methods of authentication, you have to unsubscribe from QuickSight and sign up again. This action deletes all resources in your QuickSight account, so you need to back up your QuickSight assets if you want to keep them.

Follow the steps in the following screenshot to sign up for QuickSight with the IAM Identity Center identity configuration. Make sure that you provide the Okta group names (qs-admin-grp, qs-author-grp, and qs-reader-grp) created in the previous steps for the QuickSight admin, author, and reader roles during the sign-up process.

Upon a successful sign-up, follow these steps:

1. Choose Go to Amazon QuickSight.

An IAM admin page of QuickSight will be displayed.

2. To log in as one of the admin users, choose QuickSight Sign-In.
3. Enter the QuickSight account name.

You will be redirected to the Okta login page.

4. Log in as one of the members of the QuickSight group (qs-admin-grp, qs-author-grp, or qs-reader-grp).
   

Congratulations! You have now successfully signed in as a QuickSight admin that is authenticated using IAM Identity Center.

The IAM Identity Center users and groups are now provisioned in QuickSight. You can grant these users and groups authorization to access QuickSight dashboards and other resources in QuickSight. You can validate that users and groups are successfully provisioned by running the list-groups and list-users commands in the AWS Command Line Interface (AWS CLI).

The following code is an example of the list-groups command:

aws quicksight list-groups --aws-account-id <<Your AWS Account Id>> --namespace default

The following code is an example of the list-users command:

aws quicksight list-users --aws-account-id <<Your AWS Account Id>> --namespace default

Publish dashboards and organize them into folders

So far, you have completed the QuickSight account setup with users and groups. Now you have to create dashboards and other QuickSight resources. Because you have users from different customer organizations consuming QuickSight embedded analytics within a business application, there are two possible designs scenarios to manage access to dashboards:

• Have a separate copy of dashboards and datasets for each customer – Although dashboards for each customer have the same visuals, they may be different in theme (branding) and based on a different dataset. These dashboards are developed one time by the ISV and programmatically deployed using asset-bundle APIs and copied into each customer’s shared folder.
• Have the same dashboard and dataset for all customers – You can implement the QuickSight RLS policy feature to make sure each customer sees only their data in the same QuickSight dashboard. This restricts each user to see data that is scoped to their company and job role.

In this section, we demonstrate how to create and organize QuickSight resources for each scenario.

Have a separate copy of dashboards and datasets for each customer

For the first scenario, we serve different QuickSight resources for each customer. We organize content using shared folders. Complete the following steps to set up the shared folders:

1. Create customer-specific shared folders; one folder for each customer.
2. Add QuickSight resources that belong to a customer into that customer-specific shared folder.
3. Share the folder selectively, only with the Okta group specific to the customer’s organization. For this example, we grant the viewer role to the customer’s group on their shared folder.

In our example, we created separate dashboards named red-customer-dashboard and blue-customer-dashboard. These dashboards are built on different datasets and placed in the red-customer and blue-customer shared folders, respectively. The Okta groups red-customer-grp and blue-customer-grp have viewer permissions on their shared folders.

You can onboard new users to QuickSight by adding them to the respective organization group and the QuickSight role group in Okta. Permissions on QuickSight resources are inherited via shared folders with group memberships. If there are job role-level permissions within each customer’s organization, create additional Okta groups specific to their job function and map them to a subfolder within the main organization-level folder, as shown in the following figure.

Have the same dashboard and dataset for all customers

For the second scenario, we create a single dashboard built from the same dataset and place it in a folder that users from every customer organization can access. By configuring the QuickSight RLS policy feature, we restrict user access to their respective organization’s records in the common dataset.

In our example, we created a dashboard named common-dashboard on a common dataset and placed it in a shared folder named common-assets, for which access is granted to both groups red-customer-grp and blue-customer-grp.

After you configure the QuickSight resources, shared folders, and group permissions, users from each customer can seamlessly access the QuickSight dashboards with restricted authorization only to their organization’s resources and data.

Next, we demonstrate the experience for customers when they log in to their business application and access QuickSight embedded dashboards.

Log in to a SaaS application and access a QuickSight embedded dashboard

In user-based embedding of a QuickSight dashboard, the authentication is done by the application and authorization is done by QuickSight. In our use case, the same Okta directory that we configured with IAM Identity Center is used to authenticate customers into the web application. This makes sure that users logging in to the application are already present and have the necessary access in QuickSight. A typical flow of embedding QuickSight is shown in the following figure.

There is no change in how the QuickSight dashboard is embedded for users with the QuickSight IAM Identity Center authentication method. We generate the embed URL using the GenerateEmbedUrlForRegisteredUser API and then embed the URL in the web application using the QuickSight JavaScript embedding SDK. In the generateEmbedUrlForRegisteredUser call, we pass the QuickSight UserArn of the Okta user logged in to the application.

The following screenshot demonstrates the first scenario, in which each customer logs in to the business application and see different QuickSight dashboards:

• The internal admin user has access to both the red customer and blue customer sales dashboards
• The red-customer-reader-1 user has access to the red customer sales dashboard
• The blue-customer-reader-1 user has access to the blue customer sales dashboard

The following screenshot demonstrates the second scenario, in which all users have access to the common sales dashboard. However, based on the user logged in, row-level security is applied, and each user sees their respective data in the same dashboard:

• The internal admin user can see records for both red_customer and blue_customer
• The red-customer-reader-1 user can see records of red_customer only
• The blue-customer-reader-1 user can see records of blue_customer only

Provision and de-provision users in the application and QuickSight

When you have user identities maintained in a centralized identity store for an application, QuickSight and other web services used by the application can help with simplified user provisioning, access management, and de-provisioning. When a new user joins a customer organization, you have to provision them only once in the central IdP (Okta) and make them a member of relevant groups. Group membership in Okta authorizes their access in the application and QuickSight. Similarly, if the user leaves the customer organization or changes their job role, it’s straightforward to revoke their access and de-provision them from business applications and QuickSight.

The following screenshot demonstrates how adding red-customer-reader-3 to Okta will automatically synchronize this user in IAM Identity Center. Because we added this user in the qs-reader-grp Okta group, it’s also provisioned automatically in QuickSight. Additionally, by adding red-customer-reader-3 into red-customer-grp, you authorize this user to access QuickSight dashboards and other resources present in the red-customer shared folders.

Similarly, when the user red-customer-reader-3 leaves the organization, de-provisioning the user in Okta will automatically revoke the user’s access both in the application and QuickSight.

Conclusion

In this post, we explained how to configure an account instance of IAM Identity Center with QuickSight. We also explained how to integrate an account instance with Okta and seamlessly manage authorization in QuickSight using Okta group memberships. Additionally, we demonstrated how new users provisioned in Okta can seamlessly access the QuickSight dashboards with restricted authorization only to their organization’s resources and data within a SaaS application.

We hope you will find the QuickSight integration with IAM Identity Center a useful feature to centrally manage user identities. We recommend that you use QuickSight embedded analytics in your SaaS application, and use an account instance of IAM Identity Center to seamlessly provision and manage user identities.

About the Authors

Anwar Ali is a Specialist Solutions Architect for Amazon QuickSight. Anwar has over 18 years of experience implementing enterprise business intelligence (BI), data analytics, and database solutions. He specializes in designing BI and data warehousing architecture and helps customers adopt best practices for BI and data warehousing solutions.

 Vetri Natarajan is a Specialist Solutions Architect for Amazon QuickSight. Vetri has 15 years of experience implementing enterprise business intelligence (BI) solutions and greenfield data products. Vetri specializes in integration of BI solutions with business applications and enabling data-driven decisions.

Camille Taylor is a Sr. Technical Product Manager focused on Amazon QuickSight administration, identity management, and governance at AWS. Her career has been focused on helping Fortune 500 companies derive value from their data and scale adoption of their business intelligence investments across industries.

Steve Pascoe is a Senior Technical Product Manager with the AWS Identity team. He delights in empowering customers with creative and unique solutions to everyday problems. Outside of that, he likes to build things with his family through Lego, woodworking, and recently, 3D printing.