Sync users and groups from Okta with Amazon QuickSight

Amazon QuickSight is cloud-powered, serverless, and embeddable business intelligence (BI) service that makes it straightforward to deliver insights to everyone in your organization. As a fully managed service, QuickSight lets you create and publish interactive dashboards that can then be accessed from any device and embedded into your applications, portals, and websites.

QuickSight supports identity federation through Security Assertion Markup Language 2.0 (SAML 2.0) in both Standard and Enterprise editions. With federation, you can manage users using your enterprise identity provider (IdP) and pass them to QuickSight at login. IdPs include Microsoft Active Directory Federation Services, Ping One Federation Server, Okta, and more.

As of this writing, QuickSight supports federated single sign-on (SSO) and Active Directory (AD) integration as enterprise-grade authentication mechanisms. The latter allows for seamless synchronization of native AD groups for role assignments and content authorization. However, when doing federated SSO with SAML, you can automatically provision users with the appropriate role. Currently, this integration lags the automatic sync of groups and user or group memberships between the IdP and QuickSight. This is important for authorization and granting permissions for appropriate access to assets to automatically provisioned users.

The three main challenges are:

  • Automatic sync of users and groups from third-party IdPs
  • Automatic assignment of users to groups
  • Deprovisioning of users and groups from QuickSight when they are removed from the IdP

This post provides steps and code samples to overcome these challenges in a scalable way. We demonstrate the solution using Okta, but you could use other IdPs as well. This is a proven solution and has been used and implemented by several QuickSight customers.

Solution overview

This solution uses QuickSight along with the following AWS services to automatically sync users, groups, and their memberships from an IdP. In this case, the IdP acts as the single source of truth.

  • AWS Lambda is a serverless, event-driven compute service that lets you run code for virtually any type of application or backend service without provisioning or managing servers. You can trigger Lambda from over 200 AWS services and software as a service (SaaS) applications, and only pay for what you use.
  • AWS Step Functions is a visual workflow service that helps developers use AWS services to build distributed applications, automate processes, orchestrate microservices, and create data and machine learning (ML) pipelines.
  • Amazon EventBridge is a serverless service that uses events to connect application components, making it effortless to build scalable, event-driven applications. You can create rules to match events and route them to one or more target functions or streams.
  • AWS Identity and Access Management (IAM) helps you securely control access to AWS resources for your users. You can use IAM to control who can use your AWS resources (authentication), what resources they can use, and how they can use them (authorization). For more information, see the IAM User Guide.

The following diagram shows the workflow to perform user and group sync from a third-party IdP.

You can implement the solution in either on-demand or scheduled modes. In both cases, the first thing that this solution does is trigger a Step Functions workflow (Okta-QuickSight-Sync), which orchestrates running a series of Lambda functions:

  • QuickSight-Okta-Group-Sync – Syncs groups between the IdP and QuickSight
  • QuickSight-Okta-User-Sync – Creates users and their group memberships
  • QuickSight-Okta-User-Deprovisioning – Deprovisions users from QuickSight and transfers orphaned assets to a dedicated QuickSight admin user

In the following sections, we explain the steps to configure the solution resources using AWS CloudFormation. You first need to retrieve the necessary parameters for the CloudFormation stack:

  • OKTAAPIToken
  • OKTADomain
  • OKTAQuickSighAPPId
  • QuickSightAdminUserName
  • QuickSightAdminIAMRole
  • QuickSightAuthorIAMRole
  • QuickSightReaderIAMRole

Prerequisites

You should have the following prerequisites:

Retrieve OKTAAPIToken from the IdP to make API calls from Lambda

We first create an API token to use as a parameter in our CloudFormation stack. Complete the following steps:

  1. Log in to your Okta domain with your administrator account.
  2. In the navigation pane, under Security, choose API.
  3. On the Tokens tab, choose Create token.
  4. Enter a token name (for example, Okta API token for QuickSight user and group Sync) and choose Create token.

Okta generates the token value.

  1. Copy the token value and store it to use in later steps.
  2. Choose OK, got it to close the modal window.

The details of the token are found on the API page. Details include timestamps of when it was created, when it expires, and when it was last used.

The validity of the API token varies by Okta account configuration. If the Lambda code fails due to token expiration, generate a new token and update it in the Lambda configuration.

Retrieve OKTADomain for the IdP

To locate your Okta domain name, complete the following steps:

  1. Sign in to your Okta organization with your administrator account.
  2. Look for the Okta domain in the global header located in the upper-right corner of the dashboard.
  3. Copy the complete domain URL and store this for use in later steps.

Retrieve OKTAQuickSighAPPId for the QuickSight application configured in Okta

To obtain your application ID, complete the following steps:

  1. Sign in to your Okta organization with your administrator account.
  2. In the navigation pane, under Applications, choose Application.
  3. Choose the QuickSight application.
  4. Copy the application ID show in the browser URL and store this to use in later steps.

Retrieve QuickSightAdminUserName to transfer assets to the admin user

We use this admin user for transferring asset ownership when deprovisioning a user with admin or author roles. Complete the following steps:

  1. Sign in to your QuickSight account with administrator access.
  2. Choose the user profile icon and choose Manage QuickSight.
  3. Copy the admin user name (for this post, we use OktaSSOUser) under Manage Users and store this to use in later steps.

Create QuickSight IAM roles from the IdP to make API calls from Lambda

You need to set up your IdP federated roles using IAM. For instructions, refer to Setting up IdP federation using IAM and QuickSight.

First, you create the IAM role for QuickSight admin permissions:

  1. On the IAM console, under Access management in the navigation pane, choose Roles.
  2. Choose Create role.
  3. For Trusted entity type¸ select SAML 2.0 federation.
  4. For SAML 2.0-based provider, choose Okta.
  5. Select Allow programmatic and AWS Management Console access.
  6. Choose Next.

Next, you add permissions to the role.

  1. Choose Create policy to create a new IAM policy.
  2. Choose JSON for your policy editor.
  3. Enter the following policy:
    {
    	"Version": "2012-10-17",
    	"Statement": [
    		{
    			"Sid": "VisualEditor0",
    			"Effect": "Allow",
    			"Action": "quicksight:CreateAdmin",
    			"Resource": "*"
    		}
    	]
    }

  4. Choose Next.
  5. Enter a policy name and optional description.
  6. Choose Create policy.
  7. For Permission policies, select the policy you created.
  8. Choose Next.
  9. Enter a name for your role (for this post, OktaCreateAdminRole) and an optional description.
  10. Choose Create role.
  11. Save the role name to use in later steps.
  12. Repeat these steps to create IAM roles for the QuickSight reader and author permissions.

The following is the IAM policy to create the reader role:

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "VisualEditor0",
			"Effect": "Allow",
			"Action": "quicksight:CreateReader",
			"Resource": "*"
		}
	]
}

The following is the IAM policy to create the author role:

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "VisualEditor0",
			"Effect": "Allow",
			"Action": "quicksight:CreateUser",
			"Resource": "*"
		}
	]
}

Now you have the required parameters for the CloudFormation template.

Create resources with AWS CloudFormation

Choose Launch Stack to provision your resources:

Provide the parameters you captured in previous steps.

After the CloudFormation is successfully deployed, all the resources are deployed in their respective accounts.

Enable EventBridge rule

As part of the deployed resources, an EventBridge rule is created. It’s disabled by default to avoid accidental runs of scripts. The rule is set to trigger at 12:00 UTC every day; you can modify this as per your requirements.

Complete the following steps to enable the rule:

  1. On the EventBridge console, under Buses in the navigation pane, choose Rules.
  2. On the rules list, choose the rule created by the CloudFormation template (OktaQSSyncEventsRule).
  3. To edit the existing rule configuration from 12:00 UTC to set your own schedule, choose Edit in the Event schedule section.
  4. Choose Enable to enable the rule.

After you enable the rule, it triggers the run of the Step Functions workflow and starts the automatic sync of users and groups from Okta to QuickSight.

Considerations

The Okta domain, Okta application ID, API keys, and dedicated QuickSight admin, users, and groups assigned to the QuickSight application in Okta are the only groups that are being synced in QuickSight. Not all the users and groups in Okta will be synced.

When deprovisioning or deleting a user from QuickSight, the ownership of orphaned assets will be transferred to the dedicated admin user configured in the QuickSight-Okta-User-Deprovisioning Lambda function environment variables.

Clean up

To clean up, delete the CloudFormation stack to deprovision all the resources that it created. This will remove the three Lambda functions and associated roles and policies, Step Functions workflow and associated role, and EventBridge rule and associate role.

Conclusion

This post provided instructions to set up automatic user and group sync between Okta and QuickSight. This solution eliminates the need to manually manage the groups and its memberships from QuickSight, and eliminates the need to deprovision users from QuickSight when they are removed from Okta.

If you have any questions or feedback, please leave a comment.

For additional discussions and help getting answers to your questions, check out the QuickSight Community.


About the authors

Ashok Dasineni is a Solutions Architect for Amazon QuickSight. Before joining AWS, Ashok worked with clients and organizations in Banking and financial domain, focusing on fraud research and prevention. He designed and implemented innovative solutions to improve business process, reduce cost and increase revenue, enabling companies around the world to achieve their highest potential through data.

Srikanth Baheti is a Specialized World Wide Principal Solution Architect for Amazon QuickSight. He started his career as a consultant and worked for multiple private and government organizations. Later he worked for PerkinElmer Health and Sciences & eResearch Technology Inc, where he was responsible for designing and developing high traffic web applications, highly scalable and maintainable data pipelines for reporting platforms using AWS services and Serverless computing.

Raji Sivasubramaniam is a Principal Solutions Architect at AWS, focusing on Analytics and AIML. Raji is specialized in architecting end-to-end Enterprise Data Management, Business Intelligence and AIML solutions for Fortune 500 and Fortune 100 companies across the globe. She has in-depth experience in integrated healthcare data and analytics with wide variety of healthcare datasets including managed market, physician targeting and patient analytics.


This is a companion discussion topic for the original entry at https://aws.amazon.com/blogs/business-intelligence/sync-users-and-groups-from-okta-with-amazon-quicksight/

My company is an odd bird, in that we have both AD and Okta as IdP providers (AD for about 1k internal users & Okta for about 20k external user). AD users & roles are synced automatically. We have a home grown lambda process that creates Okta users in QS and programmatically assigns these Okta users to a small and fixed number of QS groups. there is no syncing of groups between Otka and QS.
Here’s my question. Can we use the functionality described in this article and keep our existing AD sync functionality? Right now we have just one QS namespace. If going to two namespaces would be helpful(one for AD and one for Okta), let us know.