OKTA

Overview

In this lab we will walk through how to deploy *Okta* with AWS Control Tower. We will effectively be deploying the Okta customization landing zone manually using StackSets.

Prerequisites

  1. This lab requires an account with Administrator privileges and Control Tower. Ask a lab assistant for help if you do not have account credentials.

  2. This lab assumes you already have an Okta account. You should have received a sheet with Okta credentials to use for this lab. Ask a lab assistant for help if you do not have account credentials.

Steps

1. Add a new Amazon Web Services Application on the Okta console

1.1) Login to Okta with the provided URL and credentials. Click on the username on the top right

1.2) Select Applications then Add Application

1.3) Search for “Amazon Web Services” and click Add

2. Add your AWS Login URL to the Okta Account

2.01) Login to the AWS console using the SSO portal link with the credentials provided to you. Select the Master account and click on the Management Console hyperlink

2.1) In the AWS console, navigate to the IAM service landing page. Below Welcome to Identity and Access Management you can find and copy your AWS Login URL under the IAM users sign-in link

2.2) On the Okta console, in the General Settings tab, add the copied IAM users sign-in link to the Your AWS Login URL field

Example:

https://123456789012.signin.aws.amazon.com/console

2.3) Click Next

3. Define the Okta Sign-On Method

3.1) On the Sign-On Options page, in the SIGN ON METHODS section, select SAML 2.0

3.2) On the yellow section that shows up below SAML 2.0, right-click the hyperlink that says Identity Provider metadata and select Copy Link Address

3.3) Copy the URL into a notepad and save this for a later step

Example

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

3.4) Leave everything else as default and click Done

4. Deploy Okta within AWS Control Tower

4.1) Download and unzip this CloudFormation template aws-okta-integration.template

4.2) In the AWS Console, go to the CloudFormation service landing page and navigate to StackSets on the left pane. Click Create StackSet

4.3) On the Choose a template page, under Specify template, select Upload a template file and then click Choose file

Browse for the aws-okta-integration.template file downloaded in Step 4.1. Click Next

4.4) Under StackSet name, enter OktaIntegration

4.5) In the OkataMetadataUrl field, enter the Okta Identity Provider metadata URL you copied in Step 3.3

4.6) In the IdentityAccount field, enter your Audit account number

4.6a) To find this number, navigate to the AWS Control Tower service landing page

4.6b) Click Accounts on the left pane and then click Audit

4.6c) Copy the Account ID under Account Details into a notepad and save this for a later step

4.7) Enter the account number in the IdentityAccount field and click Next

4.8) Under Permissions and IAM admin role ARN, select AWSControlTowerStackSetRole

Confirm that the IAM execution role name is “AWSControlTowerExecution”, if not manually change it

Ignore warnings. Leave everything else as default and Click Next

4.9) Specify the Accounts and Region to deploy into

4.9a) Under Deployment Options, in the Account numbers field, add the Audit account number from Step 4.6c

4.9b) Under Specify regions select US West (Oregon) from the drop-down list. Click Next

4.10) Review the configuration and click the box I acknowledge that AWS CloudFormation might create IAM resources with custom names. Click Submit

4.11) Wait for the stack to complete and for all of the instances to be created successfully

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.12) Create user keys for the OktaSSOUser in the Audit account

4.12a) Before continuing, switch into the Audit account via the SSO portal link from your credentials sheet

Click Management Console to be redirected into the Audit account console

4.12b) Navigate to IAM and click Users in the left pane. Find OktaSSOUser

4.12c) Select the OktaSSOUser and click on the Security Credentials tab. Click Create access key and write down or save the AccessKey and SecretKey for use later

5. Complete Okta Application configuration

5.1) Add the user ARN to the Okta Amazon Web Services application

5.1a) Navigate to the Okta dashboard and click the Sign On tab, then click Edit

5.1b) Scroll down to the Identity Provider ARN field and type the ARN. Leave everything else as default and click Save

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

Where [account_id] is the Audit account number from previous steps

5.2) Configure the API Integration with the OktaSSOUser

5.2a) Navigate to the Provisioning tab in the application dashboard and click Configure API Integration

5.2b) Click Enable API Integration

5.2c) Add the Access Key, Secret Key and Audit Account ID in the appropriate fields and click Test API Credentials. If successful you’ll get a success message. Click Save when done

­­­

5.3) Enable user creation

5.3a) Back on the Provisioning tab click Edit and select the Enable checkbox for Create Users. Click Save

5.4) Assign proper roles to users

5.4a) Navigate to the Assignments tab in the application dashboard

5.4b) Click on Assign and then Assign to People

5.4c) Select the Okta user by clicking Assign

5.4d) In the new window, assign roles to your selected user

For this lab choose the AdministratorAccessRole then click Save and Go Back and Done

6. Login to Okta

6.1) Login to the Okta Console

6.1a) Login to the Okta portal using the URL provided on your credentials sheet

Example: *https://egglz4ct.okta.com/* 

6.1b) Click on the AWS Application. You’ll now be redirected to the AWS Console in the Audit Account with Administrator privileges

Exploring the Solution

  • Customizing the AWS Account Link changes the Okta page where the user selects a Role by displaying AWS Account Aliases instead of Account numbers. Example

  • Try the Okta browser plug-in

  • 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:

  1. Delete the Stacks deployed from the OktaIntegration StackSet

  2. Delete the StackSet OktaIntegration itself

  3. 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.