Okta

How to Configure SAML 2.0 for Amazon Web Service


Contents


Supported Features

The Okta/AWS SAML integration currently supports the following features:


Overview

Okta's integration with Amazon Web Services (AWS) allows end users to authenticate to one or more AWS accounts and gain access to specific roles using single sign-on with SAML. Okta admins have the ability to download roles from one or more AWS into Okta, and assign those to users. In addition, Okta admins can also set the duration of the authenticated session of users via Okta.

When logging in to AWS, end users will be presented with an AWS screen with a list AWS roles assigned to them in one or more AWS accounts. They can select the role to assume for login, which defines their permissions for the duration of that authenticated session.

Important things to note before you begin:


CONNECT OKTA TO A SINGLE AWS INSTANCE

Connecting Okta to your AWS instance to provide SSO into AWS roles for your users is a simple four step process:

Step 1: Configure Okta as your Identity Provider in your AWS Account

In order to use SAML for AWS, you will have to set up Okta as an identity provider in AWS and establish the SAML connection. The steps in this section will walk you through this process.

  1. Log in to your AWS Console, then select Services.

  2. Click IAM under Security and Identity Compliance:

    aws_new_1.png

  3. Click on Identity Providers in the menu bar on the left side:

    aws_new_2.png

  4. Select Create Provider:

    aws_new_3.png

  5. In the Configure Provider screen, enter the following:

    • Provider Type: Select SAML from the dropdown menu.

    • Provider Name: Enter a name of your preference, for example: Okta.

    • Metadata Document: First click, download, then save the following metadata file:

      Sign into the Okta Admin dashboard to generate this value.

      Then click Choose File to locate and upload it to AWS.

    • aws_new_4.png

  6. Click Next.
  7. Click Create.
  8. Locate the Identity Provider you just created by the Provider Name in the list of Identity Providers. Click on the name, and make a copy of the Provider ARN value. You will need it later during this configuration:

    aws_new_5.png


Step 2: Add Okta Identity Provider as Trusted Source in your AWS Roles

Now that you have configured Okta as the Identity Provider in AWS, you can create or update existing IAM roles that Okta will be able to retrieve and assign to users in Okta. Note that Okta will only be able to provide SSO for your users to roles that have been configured to grant access to the Okta SAML Identity Provider you configured in the previous step (Step 1: Configure Okta as your Identity Provider in your AWS Account).

To grant SSO access to existing roles in your account:

  1. Go to Roles and select the role that you would like to permit Okta SSO access to.
  2. Select the Trust Relationship tab for the role, then click Edit Trust Relationship:

    aws_new_6.png

  3. You now need to modify the IAM trust relationship policy to permit SSO into Okta using the SAML IDP you configured in the previous step:

    1. If your policy is currently empty, you can copy and paste the policy listed below and replace <COPY & PASTE SAML ARN VALUE HERE> with the ARN value you copied from step 1 (Step 1: Configure Okta as your Identity Provider in your AWS Account).
    2. If you have a current trust relationship in place, then you may need to modify your existing policy document to also include Okta SSO access. At a minimum you will need to include everything within the Statement code block - including the configurations for Effect, Principal, Actions, and Conditions. Replace <COPY & PASTE SAML ARN VALUE HERE> with the ARN value you copied from step 1 (Step 1: Configure Okta as your Identity Provider in your AWS Account).
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "<COPY & PASTE SAML ARN VALUE HERE>" }, "Action": "sts:AssumeRoleWithSAML", "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } } } ] }

To grant SSO access to a new role:

  1. Go to Roles > Create New Role.
  2. Select SAML 2.0 federation, select Okta as the SAML provider and check Allow programmatic and AWS Management Console access:

    aws_new_aa.png

  3. Click Next on the Verify role screen.
  4. Select your preferred policy to be assigned to the role you're creating for end-users, then click Next.

Step 3: Generate the AWS API Access Key for Okta to Download AWS Roles

You now need to create an AWS User with specific permissions so that Okta can dynamically fetch a list of available roles from your account. This makes assigning users and groups to specific AWS roles easy and secure for your administrators. Use the following instructions:

  1. From the AWS Console, navigate to IAM and then to Users.
  2. Select Add user:

    aws_new_9.png

  3. Enter a User name, for example OktaSSOuser, select Programatic access as the Access type, then click Next.

    aws_new_10.png

  4. Select Attach Existing Policies Directly , then select Create Policy:

    aws_new_11.png

  5. A new tab in your browser will open. Select the JSON tab:

    aws_json.png

  6. Copy and paste the following into the Policy Document section:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:ListRoles", "iam:ListAccountAliases" ], "Resource": "*" } ] }
  7. Enter your preferred Policy Name, for example OktaMasterAccountPolicy, and a Description:
  8. Click Create Policy, then return to your first tab to continue assigning policies to your IAM User.

    aws_policy.png

  9. Back on the IAM User Page, select Refresh to re-load the list of available policies to attach to your user. Select the policy you just created, click Next: Review, then choose Create User:

    aws_new_13.png

  10. A screen now appears that displays your Secret Key and Access Key. Make a copy of these values as you will need these later on in STEP 4 (below) to configure the AWS app in Okta.

Step 4: Configure the Amazon Web Services app in Okta

Now you have finished the required steps to be performed in the AWS console, open the Amazon Web Services app integration configuration in Okta and perform the following steps to complete the set up:

  1. In Okta, select the Sign On tab for the AWS app, then click Edit.

    • Select your Environment Type  from the dropdown menu. If your environment type is not listed, you can set your desired ACS URL in the ACS URL field. Note that that ACS URL field is optional; if your environment type is listed in the dropdown, you do not need to enter your ACS URL.
    • Paste the Identity Provider ARN that you made a copy of earlier in this configuration into the Identity Provider ARN field.
    • Set the desired session duration for users in the Session Duration field.
    • Join all roles: This option enables merging all available roles assigned to user as follows:

      For example, if a user is directly assigned Role1 and Role2 (user to app assignment), and the user belongs to group GroupAWS with RoleA and RoleB assigned (group to app assignment), then:

      • Join all roles OFF: Role1 and Role2 are available upon login to AWS
      • Join all roles ON: Role1, Role2, RoleA, and RoleB are available upon login to AWS
    • Use Group Mapping enables CONNECT OKTA TO MULTIPLE AWS INSTANCES VIA USER GROUPS functionality.
    • Click Save/Next.

    aws_prov_new_1.png

  2. Still in Okta, select the Provisioning tab for the AWS app, then click Edit.

    Note: The Amazon Web Services app integration does not support provisioning. This setup under the Provisioning tab is required to provide API access to Okta to download a list of AWS roles to assign during the user assignment. It allows you to assign multiple roles to users and pass those roles in the SAML assertion.

    • Click Enable API Integration.

    • API URL (optional): If your Environment Type was listed in the dropdown under the Sign-on tab, you do not need to fill out this field. If your Environment Type was not listed in the dropdown, enter your API URL here. You may have to contact AWS to find out the API URL for your environment.

    • In the Access Key and Secret Key fields, enter the values you made copies of in Step 3 (Step 3: Generate the AWS API Access Key for Okta to download AWS Roles).
    • Click Test API Credentials to verify API credentials are working.
    • To be able to update Roles and Permissions from AWS you need to enable Update Attributes and Create Users:

      aws_new_a1.png

      Note: As a reminder, you are not creating or updating any users in AWS, but this activates necessary parts of the API to allow Okta to retrieve Okta-trusted roles from the AWS account.

    • Click Save.
  3. aws_new_b.png

  4. Scroll down and enable the Create Users feature (but not Update User Attributes). Note: As a reminder, you are not creating or updating any users in AWS, but this activates necessary parts of the API to allow Okta to retrieve Okta-trusted roles from the AWS account.
  5. Click Next (or Save).
  6. In the Assign People screen, select a test user you wish to use to test the SAML connection for the AWS app.
  7. In the User Assignment screen, go to SAML User Roles, and select all the roles you would like to assign to this user, then click Save. In this example, we have assigned two roles to our test user:

    aws_new_16.png

    IMPORTANT: If you see the attribute IdP and Role Pairs (internal attribute), ignore it. It is an internal attribute and it doesn't affect user assignment.

  8. Once the assignment is complete, an AWS chiclet will appear on the test user's Okta dashboard. Log in to your Okta org as the test user, and click on the AWS chiclet. 
  9. The user will be presented an AWS screen with a list of roles assigned to it in Okta. Here, select the role to assume when logging in to AWS:

    aws_new_17.png

  10. Ensure that there are no errors and the user is able to log in with the assumed role.
  11. Once this test is complete, you can go back in Okta and start assigning users and/or groups to the AWS app.
  12. Done!

CONNECT OKTA TO MULTIPLE AWS INSTANCES VIA USER GROUPS

Managing User and Group Access to Accounts and Roles

Note that although the following instructions apply to AD/LDAP, all other applications, including profile-mastered ones and local Okta groups can be used as well.


Currently, administration of this feature is primarily supported in AD and LDAP. From here, administrators work with two different logical sets of AD / LDAP groups, AWS Role Specific Groups and Management Groups, described below:

AWS Role Specific Groups

A group must exist in AD or LDAP for each specific account and role combination that you want to provide access to. You can think of these groups as AWS Role Specific Groups. The group name should follow a particular syntax as well (more details in Set Up Instructions).

aws_groups1.png

Any user who is a member of these role specific groups is granted a single entitlement: access to one specific role in one specific AWS account. These groups can be created by a script, exported as a list from AWS, or created manually.

Management Groups

However, it does not scale to manage user access by assigning each user to specific AWS Role Groups. To simplify administration, we recommend you also create a number of groups for all of the distinct user-sets in your organization that require different sets of AWS entitlements.

These groups may already exist in your AD/LDAP hierarchy in the form of different department specific groups, but can also be created solely for AWS.

aws_groups2.png

These management groups become the administration layer where you assign users (as groupMembers) and map these users to specific entitlements through AWS Role Groups (as Members Of).

aws_new_aaa.png

Once these groups have been created in Active Directory or LDAP, all administration should take place with the Management Groups. Add / Remove users to these groups to grant access to your listed AWS accounts and roles, and update the specific entitlements by adding or removing AWS Role Groups in the Member Of group property.


High-Level Design

aws_new_bb.png

Set Up AWS for SAML

Each of your AWS accounts must be configured for SAML access. This entails adding Okta as a trusted IDP to your AWS account and then creating a trust relationship for each of your roles that permits access via the new IDP. These are the same steps that one would follow to provide SAML SSO into any single AWS account, but must be performed across all of your accounts. For advanced organizations, this can be automated with Cloud Formation or AWS API scripts for simple SAML setup in each account.

Create a Management Layer of Groups in AD / LDAP

Once SAML has been configured, you create AWS Role Groups in AD/LDAP for each role and account you want users to be able to access via Okta. This can be completed via a script between AWS and AD/LDAP, by exporting a CSV to AD and scripting against the CSV on the AD side, or manually.

Next, you create a link between these AWS Role specific Groups and other AD /LDAP groups by assigning Management Groups as Members Of the AWS Role Groups you want to grant them access to. Once complete, assign users to these Management groups to allow access to all of the AWS roles and accounts that the Management Group is a member of.

Configure the AWS App in Okta for Group-Based Role Assignment

Finally, in Okta, import both the AD/LDAP Management Groups and Role Groups via Okta’s AD or LDAP Agent. Next, assign your management groups to the AWS application you set up earlier (Set Up AWS for SAML): This assigns the proper users to the AWS app. Lastly, set up Group Based Role Assignment to translate the names of each of your AWS Role Groups into a format that AWS can consume to list the proper roles on the Role Picker Page for your users.

Set Up Instructions

Preface

Step 1: Setting Up Your AWS Accounts and Roles for SAML SSO

First, setup all of your AWS accounts for SAML access with Okta.

  1. Begin by creating a new AWS app in Okta and select SAML from the Single Sign-On tab.

  2. Open the in-product guide, and perform steps 1 and 2 of CONNECT OKTA TO A SINGLE AWS INSTANCE:

  3. Do this for all of your AWS accounts and roles that you want to grant users access to – and ensure that all of your accounts have been set up with the same exact SAML metadata and have been named the same exact name. Any account with a different SAML provider name or metadata document will not be accessible.

Step 2: Creating AWS Role Groups in AD / LDAP

Once all AWS accounts have been configured for SAML, groups must be created in AD for each AWS role in each account that you want users to have access to. This can be accomplished in a few different ways:

Regardless of how you choose to create these AWS Role Specific Groups in your directory, we recommend the following procedure:

  1. Create a new OU somewhere in your directory so that you can isolate all of your AWS Role Specific groups. This is not required, but recommended in order to make group management simple for your administrators. Potential OU names could be AWS Role Groups, AWS Entitlements, etc.

  2. Create AD security groups for each role following a standard syntax. For simplicity, Okta recommends the following syntax:

    aws#[account alias]#[role name]#[account #]

    For example:

    aws#northamerica-production#Tier1_Support#828416469395

If you prefer to use your own group syntax, make sure to include account alias, role name, and account # with recognizable delimiters in between each. This will also require you to be able to create a custom regex expression in later steps and therefore should only be done if you are comfortable with these advanced topics.

Step 3: Configuring AD / LDAP Management Groups to Map Users to AWS Accounts and Roles

Next, another set of AD / LDAP groups will be created or used to establish a link between sets of users, and the specific AWS accounts and roles they should have access to.

  1. If you do not already have groups in AD that you want to use to manage the AWS entitlements that different users should have access to, then:

    • Create another OU in your directory for AWS Management Groups. Alternatively, you can place these groups wherever you prefer in your directory; a different OU is recommended to simply aid in ease of administration.

    • Create groups for each different user population that requires a different set of AWS roles and accounts. Name these however you see fit, for example: Tier 1 AWS Support, Database Admins, AWS Super Admins, etc.

  2. Once you have management groups you would like to use, make each of these groups a member of all of the AWS Role Groups that this group should have access to. This establishes a link between the management groups and the entitlements in all of your AWS accounts that group users should have access to. You can add, remove, modify, and audit AWS entitlements from this page for each of your management groups.

  3. aws_new_cc.png

  4. Next, you can begin assigning users directly to the group by making users members of these groups. Similarly, you can add, remove, modify, and audit user membership of each group from this page as well.

These management groups become the central control point for you to manage and audit user access to different sets of AWS entitlements.

aws_new_dd.png

Step 4: Importing AWS Role Groups and Management Groups into Okta

Next, both AWS role groups and management groups need to be imported into Okta and configured for use in the AWS app you set up earlier (Set Up AWS for SAML).

Importing these groups is typically done via the Okta AD or LDAP Agent. Instructions on installing the Okta AD / LDAP Agent can be found in product by navigating to Directory > Directory Integrations.

Upon completion, you should be able to see both your AWS Role groups and Management groups from the Groups page in the Okta Admin Console:

aws_groups3.png

Step 5: Enabling Group Based Role Mapping in Okta

Once the groups have been imported into Okta, the AWS app you set up earlier (Set Up AWS for SAML) must be configured to translate AWS Role group membership into entitlements that AWS can understand syntactically:

  1. Navigate to the AWS app you set up earlier (Set Up AWS for SAML).

  2. Select the Sign On tab, then click Edit.

  3. Locate the App Filter, Group Filter, and Role Value Pattern fields. These fields control how Okta maps your AWS role groups into entitlements for this feature. Configure these fields as follows:

    • App Filter: This filter narrows the list of groups that Okta can use for AWS entitlement mapping to a specific app or directory. This exists for security purposes, to avoid possible situations where rogue admins create groups following a certain syntax in order to intentionally gain unauthorized access to a specific AWS account / role. If you created your groups in Active Directory, you can input active_directory, if you want to limit usage by local Okta groups, input okta. For other application(s) you can use values such as: bamboohr for Bamboo HR app or okta, egnyte for Okta + Egnyte groups.

    • Group Filter: This filter field uses a Regex expression to only inspect groups from your chosen app filter that follow a specific syntax. If you did chose to use the Okta recommended default AWS role group syntax listed above, then you can simply use the following regex string:

      ^aws\#\S+\#(?{{role}}[\w\-]+)\#(?{{accountid}}\d+)$

      This regex expression logically equate to: find groups that start with AWS, then #, then a string of text, then #, then the AWS role, then #, then the AWS account ID.

      If you didn’t use the default recommended AWS role group syntax, then you must create a regex expression that properly filters your AWS role groups, and captures the AWS role name and AWS Account ID within two distinct Regex groups named {{role}} and {{accountid}} respectively.

      aws_groups4.png

    • Role Value Pattern: This field takes the AWS role and account ID captured within the syntax of your AWS role groups, and translates it into the proper syntax AWS requires in Okta’s SAML assertion to allow users to view their accounts and roles when they sign in.

      This field should always follow this specific syntax:

      arn:aws:iam::${accountid}:saml-provider/[SAML Provider Name],arn:aws:iam::${accountid}:role/${role}

      Replace [SAML Provider Name] with the name of the SAML provider that you set up in all of your AWS accounts (Set Up AWS for SAML). The rest of the string should not be altered, only copied and pasted.

Step 6: Assign All AWS Management Groups to the AWS App in Okta

Lastly, now that the AWS app has been properly configured to map AWS role groups to entitlements, assign all of your AWS Management Groups to the application in Okta. This will automatically assign all of the appropriate users to the AWS app, and the instructions you completed in Step 5 (above) will ensure that they only see the appropriate entitlements they should have access to.

Setup is now complete! Verify that users can access the AWS app from their Okta end-user dashboard and sign-on is seamless.

aws_groups5.png


CONNECT OKTA TO MULTIPLE AWS INSTANCES VIA AWS API

Okta can also provide single sign on into roles across multiple AWS instances. The Okta Console is also able to dynamically fetch the list of available roles across all of your AWS instances so that assigning users and groups to these roles is simple and secure for administrators. 

High-Level Design

Okta is able to provide SSO and fetch roles across multiple AWS accounts through the use of an IAM User with permissions to read IAM roles and account info across all of your connected accounts:

The following diagram is provided below for your reference:

aws_new_18.png

Step 1: Configure Okta as your Identity Provider in all of your AWS Accounts

Begin by configuring Okta as a trusted SAML SSO Identity Provider in all of your AWS accounts. Follow the steps in Step 1: Configure Okta as your Identity Provider for your AWS Account using the same metadata and name throughout all of your accounts. This includes your Master account as well as your Connected accounts.

Step 2: Add Okta Identity Provider as Trusted Source in your all AWS Roles across all AWS Accounts

Repeat the same steps from Step 2: Add Okta Identity Provider as Trusted Source in your AWS Roles for each role in all accounts you wish to set up. This also includes roles that you would like to access from your Master account as well as your Connected accounts.

Step 3: Generate the AWS API Access Key for Okta to download AWS Roles from all Accounts

Next, you need to create an AWS User with specific permissions in the AWS account that you've designated to be the Master so that Okta can dynamically fetch a list of available roles from all of your accounts. This makes assigning users and groups to specific AWS roles easy and secure for your administrators. Use the following instructions:

  1. From the AWS Console of your Master Account, navigate to IAM and then to Users.

  2. You need to create a new IAM user. Select Add user:

    aws_new_19.png

  3. Select a name for the user, for example OktaSSOuser, select Programmatic access for Access type, then click Next:

    aws_new_20.png

  4. Select Attach existing policies directly, then select Create policy:

    aws_new_21.png

  5. A new tab in your browser will open. Select the JSON tab:

    aws_new_c.png

  6. Copy and paste the following into the Policy Document section:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:GetAccountSummary", "iam:ListRoles", "iam:ListAccountAliases", "iam:GetUser", "sts:AssumeRole" ], "Resource": "*" } ] }
  7. Enter your preferred Policy Name, for example OktaMasterAccountPolicy, and a Description.
  8. Click Create Policy, then return to your first tab to continue assigning policies to your IAM User.

    aws_new_22.png

  9. Back on the IAM User Page, choose Refresh to re-load the list of available policies to attach to your user. Select the policy you just created and then select Next: Review, then click Create User:

    aws_new_23.png

  10. A screen now appears that displays your Secret Key and Access Key. Make a copy of these values as you will need these later on in Step 5 (Step 5: Configure the Amazon Web Services App in Okta) to configure the AWS app in Okta.

Step 4: Set up an IAM Role in each of the Child Accounts

Now that you have created an AWS User with read permissions for accounts and roles in your Master account, you need each of your remaining connected accounts to trust the master account user and permit it to read roles. 

In each of your remaining Connected accounts:

  1. Go to Roles > Create Role.
  2. Select Another AWS account and input the master Account ID (see below how to get the value) .
  3. aws_newd.png

    The Master Account ID can be found by choosing My Account from the dropdown in the top-left of the AWS console:

    aws_new_25.png

  4. Attach a policy with read access to IAM roles, for example IAMReadOnlyAccess:

    aws_new_27.png

    Alternatively, you can create a new policy and attach minimum required read permissions shown below, and attach it to the Role you are creating:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:ListRoles", "iam:ListAccountAliases" ], "Resource": "*" } ] }
  5. Set the Role name as Okta-Idp-cross-account-role.

     

    IMPORTANT: This is a predefined name for this integration, please ensure it is set this up correctly. You cannot use a different name.

  6. Repeat these steps for every child account, ensuring that you use the same Master Account ID, and the same Role nameOkta-Idp-cross-account-role.

Step 5: Configure the Amazon Web Services App in Okta

Now that you have finished the required steps to be performed in the AWS console, open the Amazon Web Services app integration configuration in Okta and perform the following steps to complete the setup:

  1. In Okta, select the Sign On tab for the AWS app, then click Edit.
  2. Select your Environment Type  from the dropdown menu. If your environment type is not listed, you can set your desired ACS URL in the ACS URL field. Note that that ACS URL field is optional; if your environment type is listed in the dropdown, you do not need to enter your ACS URL.
  3. Paste the Identity Provider ARN that you made a copy of earlier in this configuration into the Identity Provider ARN field.
  4. Set the desired session duration for users in the Session Duration field.
  5. Click Save/Next.
  6. aws_new_28.png

  7. Still in Okta, select the Provisioning tab for the AWS app, then click Edit.

     Note: The Amazon Web Services app integration does not support provisioning. This setup under the Provisioning tab is required to provide API access to Okta to download a list of AWS roles to assign during the user assignment. It allows you to assign multiple roles to users and pass those roles in the SAML assertion.

    • Click Enable API Integration.
    • API URL (optional): If your Environment Type was listed in the dropdown under the Sign on tab, you do not need to fill out this field. If your Environment Type was not listed in the dropdown, enter your API URL here. You may have to contact AWS to find out the API URL for your environment.
    • In the Access Key and Secret Key fields, enter the keys you retrieved and stored in Step 3 (Step 3: Generate the AWS API Access Key for Okta to download AWS Roles from all Accounts) while setting up the AWS user in your Master Account.
    • aws_newb.png

  8. Next, provide a comma-separated list of all of the IDs of your Connected accounts. Once again, you can find this in each AWS account from the My Accounts page in the top-left hand corner of the AWS Console.

    aws_newe.png

  9. Click Test API credentials to ensure the credentials work for all Connected accounts. Fix any errors before proceeding.
  10. To be able to update Roles and Permissions from AWS you need to enable Update Attributes and Create Users:

    aws_new_a1.png

    Note: As a reminder, you are not creating or updating any users in AWS, but this activates necessary parts of the API to allow Okta to retrieve Okta-trusted roles from the AWS account.

  11. Scroll down and enable the Create Users feature (but not Update User Attributes). Note: As a reminder, you are not creating or updating any users in AWS, but this activates necessary parts of the API to allow Okta to retrieve Okta-trusted roles from the AWS account.
  12. Click Next (or Save).
  13. Assign the app to a test user; under the User Assignment page you will see a list of roles from your Master account, as well as your Connected (secondary) accounts. 

    Note: Okta will use the following format to display the list of roles: Account Name - Role Name. If your AWS accounts have an alias set up, then Okta will use the account alias instead of the account name such as: [Account Alias] - Role Name. We are using starks as the Account alias in the following screenshot:

    aws_new_31.png

  14. Complete the app assignment.
  15. Log in to your Okta org as the test user, and click on the AWS chiclet. The user will be presented an AWS screen with a list of roles pertaining to different AWS accounts assigned to it in Okta. Here, select the role to assume when logging in to AWS.

    aws_new_32.png

  16. Ensure that there are no errors and the user is able to log in with the assumed role.
  17. Once this test is complete, you can go back in Okta and start assigning users and/or groups to the AWS app.

Notes