How to securely deliver business intelligence to internal-facing applications with Amazon QuickSight

Amazon QuickSight is a fully managed, cloud business intelligence (BI) service that makes it straightforward to connect to your data, create interactive dashboards, and share them with tens of thousands of users, either within the QuickSight interface or embedded in a web or mobile application.

In this post, we explore a set of implementation approaches that address authentication and authorization requirements for the embedded web application use case. We specifically address the use case of an enterprise with a central access management process. Each successive approach in this post enhances the user experience while requiring increased implementation effort:

1. Direct access to QuickSight dashboards
2. Accessing QuickSight dashboards embedded in an anonymously accessible website
3. Accessing QuickSight dashboards embedded in a restricted-access single page application

AWS Integration with a central access management process

Many enterprises, particularly in financial services, implement a centralized access management solution through an identity provider (IdP). Within this IdP, employees are represented as enterprise users and groups that represent various access domains. Each group has a designated employee owner responsible for approving membership and attesting membership at regular intervals and milestone events, such as role changes. Individual enterprise systems are expected to integrate with the enterprise IdP for authentication and use group memberships for authorization.

Amazon Web Services (AWS) offers a way to integrate identity and access management with an IdP through the AWS IAM Identity Center. Our example enterprise has two groups, ADMINS and DEVELOPERS, and has configured AWS IAM Identity Center integration with their IdP, associating these groups with the integration. Users and groups are synchronized from the IdP to IAM Identity Center through industry standard System for Cross-domain Identity Management (SCIM) protocol. The following diagram shows the groups in the IdP and IAM Identity Center.

QuickSight subscription setup

When adding a QuickSight subscription to your AWS account, you’ll be prompted to configure an authentication method. If your organization uses a central access management approach, you should select IAM Identity Center as the method. You’ll then be asked to specify which IAM Identity Center group should be mapped to the QuickSight Admin role. After the subscription is established, QuickSight admins can configure mappings between IAM Identity Center groups and the QuickSight Author and Reader roles.

To illustrate this process, consider the following example: An employee in the ADMINS group requests that the IdP administrator create groups for QuickSight access. The IdP administrator creates two groups: BI_EDITORS and BI_VIEWERS. These groups are then added to the IdP’s IAM Identity Center integration and synchronized using SCIM to AWS IAM Identity Center. Subsequently, the user in the ADMINS group can access QuickSight and map BI_EDITORS to the Author role and BI_VIEWERS to the Reader role.

Direct access to QuickSight dashboards

With the administrative tasks completed, BI_EDITORS users can now access QuickSight to create analyses and dashboards. They access the QuickSight service directly through its Regional URL. QuickSight redirects users to the IdP for authentication before granting access. BI_EDITORS can create dashboards and use the QuickSight console to share them with users in the BI_VIEWERS group. The console provides an option to copy a direct URL to the dashboard to the user’s clipboard. BI_EDITORS can then distribute this QuickSight URL to BI_VIEWERS users for dashboard access. The following screenshot shows the Copy link option on the dashboard.

When a BI_VIEWERS user accesses the URL, QuickSight redirects them to the IdP for authentication. It then validates that they have the Reader role (through role mapping) and permission to access the specific dashboard before rendering it.

The following diagram illustrates a BI_VIEWERS user accessing the QuickSight dashboard directly. The QuickSight service orchestrates a service provider (SP)-initiated single sign-on flow to authenticate the user and subsequent authorization.

Accessing QuickSight dashboards embedded in an anonymously accessible website

Imagine you want to embed the dashboard in an internal website. In the same way that the user in the BI_EDITORS role can use the QuickSight console to retrieve a direct link to the dashboard, they can also retrieve the embed code for incorporating the dashboard into a web page. The BI_EDITORS user can then collaborate with the website author to add the embed code to the website. The following screenshot shows the Copy embed code option.

When enterprise users access the internal website and the page containing the embed code, the code will trigger a pop-up window to QuickSight and initiate the SP-initiated single sign-on flow process. After the user completes the process, the pop-up window will close automatically and trigger the embedded frame to render the dashboard.

The following diagram illustrates that although the user’s request to the website is anonymous, the embedded frame (and pop-up) addresses authentication and authorization.

Accessing QuickSight dashboards embedded in a restricted-access single page application (SPA)

In the next scenario, we aim to integrate QuickSight dashboards into an existing application with restricted access. Assume, user access to the existing SPA is already governed by membership in the IdP’s APP_USERS group. This group needs to be synced with IAM Identity Center. To grant these users access to dashboards, the QuickSight admin user assigns the QuickSight Reader role to APP_USERS group, and the BI_EDITORS then share the dashboards with APP_USERS group. This way, no changes are required in the central access management platform, and dashboard access permissions for this group can be managed within QuickSight.

Solution approach

The solution follows these steps:

1. The IdP admin adds the APP_USERS group to the list of groups to synchronize with IAM Identity Center.
2. Within the QuickSight administration console, an ADMINS user maps the APP_USERS group to the Reader role.
3. BI_EDITORS create a new analysis for datasets associated with the app. They then publish the dashboard and share it with the APP_USERS group.

The following updated diagram shows the groups in the IdP and IAM Identity Center.

Assume that we follow the same approach to embed the dashboard by copying the embed code and putting that into the restricted-access web application. When users visit the web application, the web application triggers its preexisting SP-initiated single sign-on flow. Next, the user navigates to the view within the SPA containing the embedded dashboard. As in the previous scenario, the embed code launches a pop-up window. However, different from the previous scenario, within the pop-up window, QuickSight recognizes that the user has already authenticated with the IdP and quickly closes the window. It then displays the dashboard in the frame. Although the user only has to authenticate one time, we can further streamline this experience. However, it requires some additional integration.

Identity transmission

To focus on the transmission solution approach, assume that the web application uses OpenID Connect (OIDC) and has successfully orchestrated the authentication flow with the IdP. The browser has a valid JSON Web Token (JWT), such as an access token or ID token. We now need to implement a mechanism to transmit the identity context from the web application to QuickSight. The following diagram illustrates this flow.

Instead of using the embed code, the key to this approach is to dynamically create a dashboard URL that transmits the identity of the user:

1. Provide a mechanism for the SPA to retrieve the dynamic QuickSight URL.
2. Make sure that only authorized users can retrieve URLs and that they can only retrieve URLs for themselves.

The following solution presents a reference architecture using AWS serverless technologies Amazon API Gateway and AWS Lambda. You can choose a functionally equivalent solution using the services of your choice. The solution follows two high-level steps:

1. Retrieve the embed URL for a registered QuickSight user.
2. Embed the dashboard.

Retrieve Embed URL for a Registered QuickSight User

QuickSight provides an API to retrieve an embed URL for a registered user, which requires the QuickSight UserArn for the user as a parameter. Because the SPA has previously authenticated with the IdP and has access to the JWT, the solution is to create an private REST API for the SPA to request the registered user embed URL. The SPA must pass the JWT along with the request to the private REST API. An AWS Lambda function can decode the JWT, construct the UserArn, and call the QuickSight API to retrieve the embed URL. To make sure the JWT provided by the SPA is valid, Amazon API Gateway and a Lambda authorizer are used, which uses data from the IdP’s OpenID discovery document to verify the JWT. The final authorization occurs within QuickSight, confirming that the UserArn exists as a Reader (through mapping to the APP_USERS group) and has permission to access the requested dashboard. The flow is as follows:

1. SPA has completed authentication with IdP and has retrieved a JWT. Specific implementation approaches to securely authenticate a user with the IdC are outside the scope of this post.
2. SPA calls the private REST API to generate the embed URL for the registered user, passing the JWT.
3. Amazon API Gateway invokes the Lambda authorizer, passing the JWT.
4. The Lambda authorizer validates the JWT using the public key specified in the IdP’s OpenID discovery document and returns a policy to API Gateway.
5. API Gateway invokes Lambda to decode the JWT, constructs the UserArn and calls the QuickSight GenerateEmbedUrlForRegisteredUser API, then returns the authorized Embed URL.
6. QuickSight authorizes that the UserArn matches a user in the Reader role with access to the dashboard and returns the URL with an access code.

This flow is shown in the following architecture diagram.

Embed the dashboard

Having retrieved the authorized user embed URL, the SPA now uses the Amazon QuickSight Embedding SDK to display the dashboard to the user. Users need to authenticate only one time, and they can access the embedded dashboard without encountering pop-up windows.

The URL contains a short-lived bearer token used to authenticate user and allow QuickSight to apply appropriate authorization for dashboard access.

Conclusion

By following this approach, organizations can deliver rich and impactful business intelligence user experiences for their enterprise users. They can achieve this securely and in compliance with enterprise access management controls using Amazon QuickSight, API Gateway, and Lambda. Consider how your internally facing enterprise applications can be enhanced with business intelligence. Visit the QuickSight Community site for enablement, demos, and the community forum.

About the authors

Dodd Pfeffer is a Principal Solutions Architect at Amazon Web Services (AWS), based in New York City. He serves financial services industry customers to create innovative and practical solutions on the AWS Cloud. Dodd has deep experience in modern application development and platform architectures. He is driven by the value achieved through production usage.

Deepak Singh is an Amazon Web Services (AWS) Solutions Architect who specializes in helping businesses use data and AI to solve business problems. With experience spanning industries like finance, healthcare, retail, and tech, Deepak works closely with customers to deliver practical solutions that drive real business impact. He’s passionate about unlocking the power of data to drive innovation and improve operations.