How I Set Up Amazon WorkSpaces Pools with Okta for Call Center Agents

Aashish Jolly — Mon, 10 Mar 2025 09:47:14 +0000

Introduction

Recently, I worked on a project where I had to set up Amazon WorkSpaces Pools integrated with Okta for authentication and domain-joined using Microsoft Active Directory (AD). The goal was to provide a scalable and cost-effective virtual desktop solution for call center agents, ensuring seamless access to cloud-based desktops while optimizing costs. Instead of assigning individual WorkSpaces to users, I leveraged WorkSpaces Pools to dynamically allocate desktops based on demand, improving resource utilization.

This is the first post in a three-part blog series where I will cover:

Setting up basic WorkSpaces Pools (this post)
Configuring FSLogix for user profile persistence
Integrating WorkSpaces Pools with Amazon Connect for a seamless call center experience

This post will focus on setting up WorkSpaces Pools, the key considerations, challenges I faced, and best practices for deploying them in a call center environment.

Understanding WorkSpaces Pools

WorkSpaces Pools is a feature of Amazon WorkSpaces that provides shared, non-persistent virtual desktops for users. Unlike WorkSpaces Personal, which assigns dedicated desktops to individual users, Pools allocates desktops dynamically from a shared pool when users log in.

Key benefits for call centers include:

Initial Planning & Prerequisites

Before setting up WorkSpaces Pools, several factors need careful consideration to ensure a successful deployment.

Estimating the Number of WorkSpaces Needed:

Instead of provisioning WorkSpaces for every agent, focus on concurrent users. For example, if your call center has 500 agents but only 200 active per shift, you only need around 200 WorkSpaces in the pool.

Selecting the Right WorkSpaces Bundle:

Standard (2 vCPUs, 4GB RAM) – Best for general call center applications.
Performance (2 vCPUs, 8GB RAM) – For agents running multiple applications concurrently.
Power (4 vCPUs, 16GB RAM) – Rarely needed for call centers unless running intensive software.

Licensing Model:
Decide between AWS-provided licenses or BYOL (Bring Your Own License) if your organization has existing Windows Desktop licenses.

Architecture Overview

High Level Architecture Diagram

The diagram below is a high-level architeture of how WorkSpaces Pools fit into an organization’s AWS environment. I will expand this architecture in future posts.

User Authentication Flow

Deployment & Configuration

I won’t cover the deployment & configuration of constructs like VPC and Managed AD. You can use this CloudFormation template to get you up & running quickly.

Here’s a summary of steps for configuring WorkSpaces Pools.

Configure Active Directory (AD)
Store credentials in AWS Secrets Manager
Integrate OKTA with AD & WorkSpaces Pools
Setup AWS IAM for SAML Federation
Setup WorkSpaces Pools Directory
Create AWS IAM Role for SAML federation
Finalize Okta Configuration
Create the WorkSpaces Pool
Test the Deployment

The sections that follow provide detailed step-by-step instructions on setting up WorkSpaces Pools.

1. Configure Active Directory (AD)

Create an Organizational Unit (OU) dedicated for WorkSpaces. I prefer to create separate OUs for computer & user objects. This will enable you to apply Group Policies to enforce security & enterprise standards followed within your organization.

Create a service account that WorkSpaces Pools will use for creating computer objects. It is essential to follow the principle of least priviledge and this document covers the minimal permissions required.


Create Service Account for WorkSpaces Pools


Assign permissions to service account

While this section doesn’t cover creation of users & groups, create a dedicated group for WorkSpaces pools and assign users to it. Later on, we’ll assign this group access to WorkSpaces Pools in OKTA.

Create a service account with readOnly permissions. This is used for OKTA Directory Integration will use for synchronizing user & group objects. This document covers the minimal permissions required.

2. Store credentials in AWS Secrets Manager

The service account created in Step 2 above must be stored in AWS Secrets Manager and encrypted using a AWS Key Management Service (AWS KMS) customer managed key.

KMS Key Policy to use

{
  "Version": "2012-10-17",
  "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::000011112222:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow access for Workspaces SP",
            "Effect": "Allow",
            "Principal": {
                "Service": "workspaces.amazonaws.com"
            },
            "Action": "kms:Decrypt",
            "Resource": "*"
        }
    ]
}

Key/Value Pairs must be created with the following names

Key	Value
Service Account Name	domain\username
Service Account Password	< Password >

Following the priniple of least priviledge, use the below permission policy to allow WorkSpaces to the specific secret only.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "workspaces.amazonaws.com"
            },
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:aws:secretsmanager:ap-southeast-2:00001111222:secret:DemoSecret-e0nmLJ"
        }
    ]
}

3. Integrate OKTA with AD & WorkSpaces Pools

Setup OKTA AD Agent

Setting up Active Directory Integration for OKTA is quite straight forward as OKTA provides a wizard to set it up. All you need is a domain-joined Windows Server 2016 or later that runs OKTA AD Agent a lightweight application. This server will require connectivity to OKTA. OKTA recommends running the wizard from the Windows Server.

Path to the wizard: OKTA Portal → Directory → Directory Integrations → Add Directory → Add Active Directory.

Setup SAML application for WorkSpaces Pools

To create a SAML application in OKTA:

Login to the OKTA Admin portal → Applications → Applications → Create App Integration.
Select SAML 2.0 and click Next.
Under General Settings, enter the following:
App name: aajolly-workspaces-pools
App logo: Upload a picture. This icon is displayed to users when they login to their OKTA portal
App visibility: Un-checked
Under SAML Settigs, enter the following:
Single sign-on URL: https://signin.aws.amazon.com/saml
Audience URI (SP Entity ID): urn:amazon:webservices
Default RelayState: https://workspaces.euc-sso.ap-southeast-2.aws.amazon.com/sso-idp?registrationCode=PLACEHOLDER

We’ll update the registration code later once WorkSpaces Pools Directory is created. For more on relay state, please refer to the documentation here.

Name ID format: Peristent
Application username: Okta username
Update application username on: Create and update

Under Attribute Statements, enter the following:

Key	Name format	Value
`https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email`	Unspecified	user.email
`https://aws.amazon.com/SAML/Attributes/RoleSessionName`	URI Reference	userName
`https://aws.amazon.com/SAML/Attributes/SessionDuration`	Basic	28800
`https://aws.amazon.com/SAML/Attributes/Role`	URI Reference	`PLACEHOLDER`

Leave the defaults under Group Attributes.
There are a few tasks to be completed on the final page.
Under Settings → Sign on methods → SAML 2.0, click more details. Now copy the Sign on URL and Issuer to your favorite note taking app, we’ll need this to configure the AWS IAM Identity Provider.
Scroll down to the section SAML Signing Certificates and click on View IdP metadata as shown in the screenshot below

It’ll open a new webpage, save it as an xml. This will be needed when configuring the IAM Identity Provider.

4. Setup AWS IAM for SAML Federation

With an AWS IAM identity provider (IdP), you can manage your user identities outside of AWS and give these external user identities permissions to use AWS resources in your account, in our case its the WorkSpaces Pools.

I recommended creating a dedicated AWS Account for this purpose. It helps with cost attribution and security enforcement apart from other benefits.

From the left-pane select Identity providers and then Add provider, provide a name and upload the metadata file you downloaded from OKTA earlier. Use the screenshot below as a reference

5. Setup WorkSpaces Pools Directory

Browse to the WorkSpaces Service and select Directories from the left panel.
Click Create directory and for WorkSpace type, select Pool.
Use the screenshots below for reference

The IAM role is optional and its use will depend on your use case. I created one with the following trust relationship:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "Service": "workspaces.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

The permission policy will depend on your use case.

Once the directory is created, select it and copy the values for the following attributes: Registration code and Directory ID. We’ll need these for the upcoming configuration.

6. Create AWS IAM Role for SAML federation

Configure an IAM role with the following trust relationship and permissions policy.

### Trust relationship ###
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::000011112222:saml-provider/wspools"
            },
            "Action": [
                "sts:AssumeRoleWithSAML",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "SAML:sub_type": "persistent"
                }
            }
        }
    ]
}

### Permissions Policy ###
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Action": [
                "workspaces:Stream"
            ],
            "Resource": [
                "arn:aws:workspaces:ap-southeast-2:000011112222:directory/wsd-abcdef123"
            ],
            "Condition": {
                "StringEquals": {
                    "workspaces:userId": "${saml:sub}"
                }
            }
        }
    ]
}

Replace 000011112222 and wsd-abcdef123 with the respective AWS Account ID and Directory ID of the WorkSpaces Pools created earlier. For more details, please refer to the documentation here.
Copy the arn of the IAM Role and the IAM Identity Provider.

7. Finalize Okta Configuration

In this section we’ll update the OKTA configuration.

Login to the OKTA Portal → Applications → Applications.
Select the application created earlier aajolly-ws-pools and click the General tab.
Edit SAML Settings and Click Next.
Under SAML Settings, update the Default Relay State attribute and replace PLACEHOLDER with the registration code of the WorkSpaces Pools Directory created earlier.
Update the Attribute Settings and replace the value for https://aws.amazon.com/SAML/Attributes/Role from PLACEHOLDER to ARN_OF_IAM_ROLE,ARN_OF_IAM_IDENTITY_PROVIDER. For more details, please take a look at the documentation here.
Follow the prompts without making any changes and click Finish.
Once done, select Assignments and Click Assign → Assign to People/Groups and select the group synced from AD, select Assign followed by Done.

8. Create the WorkSpaces Pools

Back to AWS and WorkSpaces, select Pools under WorkSpaces in the left panel.
Click Create WorkSpace
For the Onboarding section, select I know what WorkSpace options I need for my use case. and click Next.
Give a name and description.
Select a custom bundle if you created one earlier.
Change the Minimum Capacity to 3 and leave the rest to defaults, click Next.
Select the Directory created earlier and click Create WorkSpace pool.
Once created, click Start and wait till the State == Running

9. Test the deployment

It’s time to test!

User Perspective: The user starts by navigating to the OKTA portal and is redirected to a WorkSpaces Pools portal, without having to enter AWS credentials. Only an Active Directory domain password is required.


Login Experience

Lessons Learned & Best Practices

At this point, we have successfully configured WorkSpaces Pools with Okta, AWS Managed AD and AWS IAM. Now, let's discuss some challenges I faced during setup and how to overcome them.

Networking

Ensure that the VPC assigned to WorkSpaces Pools has a DHCP option set that points to the AD DNS servers. Otherwise, domain-join operations will fail.
If using Managed AD, the DHCP option set is sufficient. If using self-managed AD, configure a conditional forwarder. This blog post explains it.
The Security Group assigned to WorkSpaces Pools must allow necessary ports for WorkSpaces IP ranges. This document lists all the ports required.

AWS Secrets Manager

WorkSpaces Pools require encrypted secrets in AWS Secrets Manager. Using an unencrypted secret will cause directory configuration errors.
Once a service account secret is assigned to a WorkSpaces Pool, it cannot be changed after directory creation.
The Service Account Name secret must be domain\username. Using / instead of \ can cause DOMAIN_JOIN_INTERNAL_SERVICE_ERROR.

Directory Setup

Shared directories are not currently supported for use with Amazon WorkSpaces.
WorkSpaces Pools Directory and Okta applications have a 1:1 relationship. If multiple WorkSpaces Pools are needed, create separate applications in Okta.
The Active Directory domain name in WorkSpaces Pools directory settings cannot be changed after setup.
If using Okta, configure Directory Integration via Okta AD Agent to sync users and groups from Active Directory.
If using Microsoft Entra ID, deploy Microsoft Entra Connect Sync on a domain-joined Windows server.

Miscellaneous

WorkSpaces Pools use bundles created via WorkSpaces Personal.
Adjust Minimum Capacity to at least 3 to ensure sufficient available WorkSpaces.
Use CloudWatch Metrics to monitor WorkSpaces Pools usage and performance.

Conclusion & Next Steps

Setting up Amazon WorkSpaces Pools with Okta SAML authentication and AWS Managed AD provides a scalable, cost-efficient virtual desktop solution for call center agents. By leveraging dynamic WorkSpace allocation, organizations can reduce costs while ensuring seamless agent access.

Through this process, I encountered challenges, including networking configurations, Okta integration, but overcoming them provided valuable insights.

In the next post, I’ll cover how to configure FSLogix for user profile persistence, ensuring a consistent experience across WorkSpaces sessions. Stay tuned!

DEV Community: Aashish Jolly