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 Quick Sight is an IAM Identity Center enabled application. Administrators can create a new Quick Sight account and use IAM Identity Center for managing Quick Sight users and groups. IAM Identity Center can store Quick Sight 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 Quick Sight roles (administrator, author, and reader) to users. After they’re successfully authenticated via IdP, users can seamlessly access Quick Sight dashboards either from the Quick Sight application or as an embedded component within their business applications. Having Quick Sight users and groups provisioned in an IdP also helps control authorization to Quick Sight resources like dashboards and datasets.
However, until now, Quick Sight was only integrated with organization instances of IAM Identity Center. Today, we are expanding the capability and announcing the integration of Quick Sight with account instances of IAM Identity Center. This new feature is available in all AWS Regions where Quick Sight 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 Quick Sight, how to configure an account instance, and how to use it to access Quick Sight.
When to use an organization instance or an account instance of IAM Identity Center
You can integrate Quick Sight 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 Quick Sight 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 Quick Sight accounts, or you deploy resources for separate environments like development, UAT, and production in separate Quick Sight 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 Quick Sight accounts centrally, as depicted in the following figure.
Account instances of IAM Identity Center are useful for the following Quick Sight use cases:
- User management for an independent software vendor (ISV) business application where end-users view Quick Sight 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 Quick Sight and your business applications. If your AWS account where the Quick Sight 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 Quick Sight application. This configuration is only recommended if you don’t need user isolation and don’t use the Quick Sight multitenancy feature. If you plan to enable multi tenancy authoring in the same Quick Sight 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 Quick Sight 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 Quick Sight 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 Quick Sight 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 Quick Sight for a common project. In this scenario, you can use an account instance with Quick Sight, 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 Quick Sight 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 Quick Sight 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 Quick Sight application. This can authorize trial users on Quick Sight 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 Quick Sight dashboards.
In this post, we demonstrate how to build a SaaS business application powered by Quick Sight embedded analytics using an account instance to manage access to insights.
Benefits of using IAM Identity Center for a business application with embedded Quick Sight 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 Quick Sight embedded analytics within this application, you can use IdP managed users and groups within Quick Sight. By integrating Quick Sight 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 Quick Sight users and groups, respectively. This is depicted in the following figure.
Integrating an account instance with Quick Sight offers the following benefits:
- Credentials are stored centrally in a single identity store for your business application, Quick Sight, 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 Quick Sight 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 Quick Sight 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 Quick Sight with row-level security (RLS) and column-level security (CLS) features.
Solution overview
In this post, we demonstrate how to configure Quick Sight with an account instance and provision Quick Sight 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 Quick Sight. We also demonstrate how users are authorized to access Quick Sight resources and data for their organization using shared folders. The following figure illustrates this architecture.
The following are the high-level steps to configure Quick Sight with an account instance and provision users:
- Enable account instances using the AWS Management Console and create an account instance of IAM Identity Center.
- Manage your identity source.
- Sign up for a Quick Sight subscription with IAM Identity Center.
- 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 Quick Sight.
To use IAM Identity Center with Quick Sight, you must create at least three groups in Okta for Quick Sight: 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 Quick Sight roles when subscribing to Quick Sight with an account instance.
When using IAM Identity Center as the authentication method, Quick Sight only supports single tenancy with the default namespace. The Quick Sight multitenancy with isolated namespaces feature is not supported when using IAM Identity Center. To control access to Quick Sight dashboards by customer, you can create one or more groups per customer organization. For example, you can add Quick Sight users from the red-customer organization as members of red-customer-grp in Okta. You can grant permissions to access specific Quick Sight 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 Quick Sight 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 Quick Sight role. This is illustrated in the following table.
| Username | Group to determine Quick Sight role | Group for Quick Sight resource access |
| internal_admin1@amazon.com | qs-admin-grp | Internal |
| internal_admin2@amazon.com | qs-admin-grp | Internal |
| internal_author1@amazon.com | qs-author-grp | Internal |
| internal_author2@amazon.com | qs-author-grp | Internal |
| internal_reader1@amazon.com | qs-reader-grp | Internal |
| internal_reader2@amazon.com | qs-reader-grp | Internal |
| red_customer_reader1@amazon.com | qs-reader-grp | red-customer-grp |
| red_customer_reader2@amazon.com | qs-reader-grp | red-customer-grp |
| blue_customer_reader1@amazon.com | qs-reader-grp | blue-customer-grp |
| blue_customer_reader2@amazon.com | qs-reader-grp | blue-customer-grp |
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 Quick Sight using IAM Identity Center for authentication
The next step is to sign up and configure Quick Sight to use the groups you created and manage access using Okta groups.
If you already signed up for Quick Sight using other methods of authentication, you have to unsubscribe from Quick Sight and sign up again. This action deletes all resources in your Quick Sight account, so you need to back up your Quick Sight assets if you want to keep them.
Follow the steps in the following screenshot to sign up for Quick Sight 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 Quick Sight admin, author, and reader roles during the sign-up process.
Upon a successful sign-up, follow these steps:
- Choose Go to Amazon Quick Sight.
An IAM admin page of Quick Sight will be displayed.
- To log in as one of the admin users, choose Quick Sight Sign-In.
- Enter the Quick Sight account name.
You will be redirected to the Okta login page.
- Log in as one of the members of the Quick Sight group (
qs-admin-grp,qs-author-grp, orqs-reader-grp).
Congratulations! You have now successfully signed in as a Quick Sight admin that is authenticated using IAM Identity Center.
The IAM Identity Center users and groups are now provisioned in Quick Sight. You can grant these users and groups authorization to access Quick Sight dashboards and other resources in Quick Sight. 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:
The following code is an example of the list-users command:
Publish dashboards and organize them into folders
So far, you have completed the Quick Sight account setup with users and groups. Now you have to create dashboards and other Quick Sight resources. Because you have users from different customer organizations consuming Quick Sight 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 Quick Sight RLS policy feature to make sure each customer sees only their data in the same Quick Sight 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 Quick Sight resources for each scenario.
Have a separate copy of dashboards and datasets for each customer
For the first scenario, we serve different Quick Sight resources for each customer. We organize content using shared folders. Complete the following steps to set up the shared folders:
- Create customer-specific shared folders; one folder for each customer.
- Add Quick Sight resources that belong to a customer into that customer-specific shared folder.
- 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 Quick Sight by adding them to the respective organization group and the Quick Sight role group in Okta. Permissions on Quick Sight 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 Quick Sight 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 Quick Sight resources, shared folders, and group permissions, users from each customer can seamlessly access the Quick Sight 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 Quick Sight embedded dashboards.
Log in to a SaaS application and access a Quick Sight embedded dashboard
In user-based embedding of a Quick Sight dashboard, the authentication is done by the application and authorization is done by Quick Sight. 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 Quick Sight. A typical flow of embedding Quick Sight is shown in the following figure.
There is no change in how the Quick Sight dashboard is embedded for users with the Quick Sight 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 Quick Sight JavaScript embedding SDK. In the generateEmbedUrlForRegisteredUser call, we pass the Quick Sight 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 Quick Sight dashboards:
- The internal admin user has access to both the red customer and blue customer sales dashboards
- The
red-customer-reader-1user has access to the red customer sales dashboard - The
blue-customer-reader-1user 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_customerandblue_customer - The
red-customer-reader-1user can see records ofred_customeronly - The
blue-customer-reader-1user can see records ofblue_customeronly
Provision and de-provision users in the application and Quick Sight
When you have user identities maintained in a centralized identity store for an application, Quick Sight 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 Quick Sight. 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 Quick Sight.
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 Quick Sight. Additionally, by adding red-customer-reader-3 into red-customer-grp, you authorize this user to access Quick Sight 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 Quick Sight.
Conclusion
In this post, we explained how to configure an account instance of IAM Identity Center with Quick Sight. We also explained how to integrate an account instance with Okta and seamlessly manage authorization in Quick Sight using Okta group memberships. Additionally, we demonstrated how new users provisioned in Okta can seamlessly access the Quick Sight dashboards with restricted authorization only to their organization’s resources and data within a SaaS application.
We hope you will find the Quick Sight integration with IAM Identity Center a useful feature to centrally manage user identities. We recommend that you use Quick Sight 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 Quick Sight. 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 Quick Sight. 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 Quick Sight 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.
This is a companion discussion topic for the original entry at https://aws.amazon.com/blogs/business-intelligence/manage-access-to-insights-with-an-account-instance-of-aws-iam-identity-center-and-amazon-quicksight/