Lab A3 – Use with AWS ControlTower

Overview

In this lab we will walk through how to deploy Okta with AWS Control

Tower. We will be effectively deploying the landing zone v2.x Okta

customization manually using StackSets.

Prerequisites

This lab requires an account with Administrator privileges and

Control Tower.

This lab assumes you already have an Okta account. If you don’t

you can sign up for a free account to access AWS console – https://

www.okta.com/aws

Steps

1. Add a new Amazon Web Services Application on the

Okta console

1.

2.

1.1) Login to Okta as an administrator and click on [Admin] at the

upper right of the console

E3C9

E313

1.2) Select Applications then [Add Application]E3C9

E313

1.3) Select Add Amazon Web Services Application E3C9

E313

2. Set the AWS Login URL to your Master’s Account sign-

in link

2.1) You can find, customize, and copy your AWS Account URL in

the Dashboard of your IAM Concole.

Expected format:

Examples:

[optional] You can also customize your alias but it must be globally unique.

E3C9

E313

https://<your-account-number>.signin.aws.amazon.com/console<!-- or customized with a globally unique name -->https://<your-alias>.signin.aws.amazon.com/console

https://151050842581.signin.aws.amazon.com/console<!-- or customized with a globally unique name -->https://my-own-name.signin.aws.amazon.com/console

2.2) Set the AWS Login URL to your Okta’s Account sign-in link and

click [Next].

Example:

E3C9

E313

https://my-own-name.signin.aws.amazon.com/console

3. Define the Okta Sign-On Method

3.1 Select SAML 2.0 as the Sign-On Method E3C9

E313

3.2 Write down the link shown on “_Identity Provider Metadata_”

and click [Done]

It should look like

E3C9

E313

https://mytestapplication123.okta.com/app/eykao293jMyS6Wc5L355/sso/saml/metadata

4. Deploy Okta within AWS Control Tower

It is a publicly accessible URL and YOU WILL NEED THAT URL LATER

[INFORMATION ONLY] This is based on the Landing Zone add-on for

Okta

E3C9

E313

Refactoring was done since the Okta Add-On is not publicly available

4.1) Download and unzip the CloudFormation template aws-okta-

integration.template

IF YOU ARE USING A SHARED ACCOUNT: Modify the aws-okta-integration.template

as stated below:

[~ line 26] Search _OktaID_ and modify the value to aliasOktaIDP to avoid collisions

in the shared account. This has only been tested with 8 characters, so use more at

your own risk.

E3C9

E313

[~ line 337] Modify the OktaUser Username OktaSSOUser to aliasOktaSSOUser

Only one participant must run the template as is-now so that the Okta cross

account role is created in the identity account – most likely the audit account – ask

the lab leader

[~ line 84] Add the condition CreateOktaCrossAccountRole: !Not [!Condition

'CreateOktaUser'] to the end of the Conditions section

Add the condition statement Condition: CreateOktaCrossAccountRole to the

OktaListRolesRole resource.

4.2) Go to the CloudFormation StackSet console in the Master

account and click [Create StackSet]

E3C9

E313

4.3) Select Upload a template to Amazon S3 and select the aws-

okta-integration.template

E3C9

E313

4.4) Give the StackSet a good name like OktaIntegration.

If using a shared account, use your alias myaliasOktaIntegration

E3C9

E313

4.5) Enter the Okta Identity Provider Metadata URL you copied

from your Okta application configuration in Step 3

E3C9

E313

4.6) Change the roles that are pre-populated.

This is OPTIONAL unless you use a SHARED account

IF YOU ARE USING A SHARED ACCOUNT , you will need to make these unique by

adding your ALIAS to each role name. To prevent role clashes with a fortcoming lab,

you can add the lab number to your prefix. Example: alias05

E3C9

E313

4.7) Enter the account number of the Audit account for the Identity

Account.

E3C9

E313

4.8) Click Next (twice)no_details E3C9

E313

Did you know there are 11 AWS Certifications?

4.9) Specify the Admin and Execution Roles, and click [Next]

Select AWSControlTowerStackSetRole from the list under IAM Admin Role ARN. Type

AWSControlTowerExecution for IAM Execution Role Name and click on Next

E3C9

E313

4.10) Specify the Accounts and Region to deploy into, and click

[Next]

Include the Audit account (or whatever Identity Account you picked) and decide on

your own whether you also want to deploy stacks in: * Accounts * Organizational

Units (OUs) * or a CSV list of valid accounts. These are the accounts that you will

configure to all Okta access to.

IF YOU ARE USING A SHARED ACCOUNT , then deploy only into the audit account

and your Account Factory account).

E3C9

E313

4.11) Review, Acknowledge the IAM box, and [Submit]

E3C9

E313

4.12) Wait for all of the instances to be created successfully. E3C9

E313

TIP: When integrating with a third party IdP it is a good practice to keep AWS SSO

available for break glass scenarios. For example access can be restricted only to the

Infosec team but quickly expanded to others. Unlike other IdP AWS SSO can

dynamically generate IAM policies to all accounts of the Organization without going

through stackset deployments

4.13) Create user keys for the OktaSSOUser in the Audit account

you selected for Identity Management

a) Check for an IAM user OktaSSOUser (if using a SHARED account, use

aliasOktaSSOUser).

b) Create access key and write down the AccessKey and SecretKey for the user

E3C9

E313

5. Complete Okta Application configuration

5.1) Add the Identity Provider ARN on the Okta Amazon Web

Services Sign-On console

Format is arn:aws:iam::[account_id]:saml-provider/OktaIDP where [account_id] is the

Audit account you selected for Identity management. If using a SHARED account,

add your alias to OktaIDP, i.e. aliasOktaIDP.

TIP: You can lookup your IdP ARN in your Audit account/IAM Console/Identity

providers

E3C9

E313

5.2) Configure the API Integration with the OktaSSOUser E3C9

E313

5.3) Enable user creation E3C9

E313

5.4) OPTIONAL: Create more users E3C9

E313

5.5) Assign proper roles to users

Go back to Application User Assignment

E3C9

E313

Assign roles to your selected user

6. Login to Okta

6.1) Login to the Okta Console as a regular user

Use a different user and the same login portal URI. Example: https://

egglz4ct.okta.com/

Click on the AWS Application

Assign roles to your selected user

E3C9

E313

Exploring the Solution

Customizing the AWS Account Link changes the Okta page where

the user select a Role by displaying AWS Account Aliases instead of

Account numbers. Example

Try the Okta browser plug-in

6.2) Select the Account and Role you want to assume and access

the AWS Console

Click on the AWS Application

E3C9

E313

•

•

Okta supports AD integration through batch import and dynamic

AD integration through an Okta AD Agent. See Automate AD

Groups mapping to roles

Once logged in, users and quickly switch to other accounts directly

from the console. This can be done natively with the AWS Console

but there are some useful browser plug-ins that extend that

behavior. Examples of open source add-ons:

Chrome: AWS Extend Switch Roles

Firefox: AWS Extend Switch Roles

CLI Access: see Okta AWS CLI Assume Role Tool

Deleting AWS resources deployed in this lab

There is nothing that incurs charges but you can:

Delete the Stacks deployed from the OktaIntegration StackSet

Dele the StackSet OktaIntegration itself

Delete the application and users created in the Okta portalß

REFERENCES

Okta AWS CLI Assume Role Tool

Automate AD Groups mapping to roles

Okta SAML Integration Guide

Okta AWS CLI Assume Role Tool

OKTA: How to Configure SAML 2.0 for Amazon Web Service

Okta/ECS Case Study

Copyright 2019, Amazon Web Services, All Rights Reserved.

•

•

•

•

•

1.

2.

3.

•

•

•

•

•

•