Connect Okta to multiple AWS instances using groups

If you have more than 60 AWS accounts and want to drive appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. assignment from groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups. within an external directory (AD or LDAPLightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services.), the preferred method is to connect to Okta using user groups.

The Okta-AWS integration does not use provisioning functionality.

There is no limitation on the number of AWS accounts and roles you can have.

Managing user and group access to accounts and roles


While this guide applies to an external directory, other applications (including profile-mastered ones and local Okta groups) can be used as well.

Connecting Okta to multiple AWS instances using groups is supported primarily in an external directory. Administrators work with two logical sets of external directory groups: AWS role-specific groups and management groups.

AWS role-specific groups

A group must exist within an external directory for each specific account and role combination for which you want to provide access. Think of these groups as AWS role-specific groups. The group name should follow a particular syntax.

A user who is a member of a role-specific group is granted a single-entitlement access to one specific role in one specific AWS account. A role-specific group can be created by a script, exported as a list from AWS, or created manually.

Management groups

It's not efficient to manage user access by assigning each user to specific AWS role groups. To simplify matters, create a number of groups—management groups, for all distinct user sets in your organization that require different sets of AWS entitlements.

These groups may already exist in your external directory hierarchy in the form of different department-specific groups, but you can also create them solely for AWS.

The management groups are the administration layer where you assign users (as groupMembers) and map these users to specific entitlements through AWS role groups (as Members Of).

Once you create the management groups in an external directory, all administrative tasks should be done using these groups. Use them to:

  • Add and remove users
  • Grant access to AWS accounts and roles
  • Update specific entitlements by adding or removing AWS Role Groups in the Member Of group property

High-level overview

Set up AWS for SAML

Each AWS account must be configured for SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. access in order to exchange authentication and authorization data between AWS and Okta. This requires adding Okta as a trusted IDPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta. to your AWS account and then creating a trust relationship for each role that permits access using the new IDP. These same steps provide SAML SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. in a single AWS account, but must be performed across all of your AWS accounts. For advanced organizations, this setup can be automated with AWS CloudFormationAWS CloudFormation provides a common language for you to describe and provision all the infrastructure resources in your cloud environment. CloudFormation allows you to use a simple text file to model and provision, in an automated and secure manner, all the resources needed for your applications across all regions and accounts. This file serves as the single source of truth for your cloud environment. or AWS API scripts for simple SAML setup in each account.

Create a management layer of groups in an external directory

Once SAML is configured, create AWS role groups in an external directory for each role and account you want users to be able to access using Okta. This can be completed using a script between AWS and an external directory, by exporting a CSV file to an external directory and scripting against the CSV file on the external directory side, or manually.

Next, create a link between the AWS role-specific groups and other external-directory groups by assigning management groups as Members Of the AWS role groups to which you want to grant them access. Assign users to the management groups to allow access to all of the AWS roles and accounts for which the management group is a member.

Configure the AWS app in Okta for group-based role assignment

In Okta, import both the external-directory management groups and role groups using the appropriate Okta external agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations..

Next, assign your management groups to the AWS application you set up earlier. 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 in order to list user roles in the Role Picker Page.

Step 1: Configure AWS accounts and roles for SAML SSO


You must configure each AWS account for SAML access in order to exchange authentication and authorization data between AWS and Okta.


  1. Create a new AWS app in Okta and then select SAML from the Single Sign-On tab.
  2. Connect Okta to a single AWS instance.

    Reference in-product guide

    To receive the necessary auto-generated variables, complete steps 1 and 2 of the "Connect Okta to a single AWS instance" section

    You can also view Step 1: Configure Okta as the identity provider in the AWS account and Step 2: Add Okta Identity Provider as a trusted source in your AWS roles of Connect Okta to a single AWS instance without receiving any auto-generated variables.

  3. Complete steps 1 and 2 for all of AWS accounts and roles for which you want to grant users access—and ensure that all of your accounts are configured with the same SAML metadata and have the same name.

    An account with a different SAML provider name or metadata document is not accessible.

Step 2: Create AWS role groups in an external directory


In order to have access to each AWS account, you need to create groups in an external directory for each AWS role in each of these accounts. These group names are utilized by a filter to tie them to the corresponding AWS roles.


  1. Create AWS role-specific groups in your directory using one of the following methods:

Regardless of how you choose to create the AWS role-specific groups in your directory, we recommend completing the following steps:

  1. To simplify group management in AD, create an organizational unit (OUAn acronym of Organizational Unit. Organizational units are Active Directory containers into which you can place users, groups, computers, and other organizational units. It is the smallest scope or unit to which you can assign Group Policy settings or delegate administrative authority.) in your directory to contain all AWS role-specific groups to be tied to AWS roles.

    Possible OU names could be AWS Role Groups and AWS Entitlements.

  2. Using a standard syntax, create external directory-security groups for each role.

    Recommended syntax:

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



    Also available is a regex expression to filter AWS related groups and extract accountid and role.




If you prefer to use your own group syntax, make sure to include an account alias, role name, and account # with recognizable delimiters in between each. This will also require the creation of a custom regex expression (see Step 5: Enable group-based role mapping in Okta). Therefore, this should only be done if you are comfortable with these advanced topics.

Step 3: Configure AD or LDAP management groups to map users to AWS accounts and roles


It's necessary to create another set of external-directory groups in order to establish a link between sets of users and the specific AWS accounts and roles to which they want access.


  1. If you have no groups in AD to manage AWS entitlements for users, then:

  2. Assign each management group to the AWS role group or groups for which it requires access.

    This establishes a link between the management groups and the entitlements in all AWS accounts to which group users should have access.

    For each management group, you can add, remove, modify, and audit AWS entitlements in the Members Of tap of the DevOps Sys Admins Properties dialog box.

  3. Assign individual users to the management groups to make them members of the desired AWS role group.

    Similarly, you can add, remove, modify, and audit user membership of each group from the Members tab of the DevOps Sys Admins Properties dialog box as well.

The management groups become the central control point to add, remove, and audit user access to different sets of AWS entitlements.

Step 4: Import AWS role groups and management groups into Okta

AWS role groups and management groups need to be imported into Okta and configured for use in the AWS app you set up earlier. Importing these groups is typically done using the Okta external directory agent (AD or LDAP).

Reference in-product guide

Access the instructions on installing the Okta external directory (AD or LDAP) agent (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 AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. Dashboard.

Step 5: Enable group-based role mapping in Okta


Once the groups have been imported into Okta, the AWS app you set up earlier must be configured to translate AWS role-group membership into entitlements that AWS can understand syntactically.


  1. From the Okta Admin Dashboard, choose Applications > Applications.

  2. Click the Sign On tab for the AWS app and then click Edit.
  3. Complete the App Filter, Group Filter, and Role Value Pattern fields with the appropriate information.

    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 or role. If you created your groups in Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management., you can input active_directory, if you want to limit usage by local Okta groups, input okta. For other applications, you can use values such as: bamboohr for the Bamboo HR app or okta, egnyte for Okta + Egnyte groups.

    • Group Filter

      This filter field uses a regex expression to inspect groups from your chosen app filter that follow a specific syntax. If you chose to use the Okta-recommended default AWS role group syntax (aws#[account alias]#[role name]#[account #]), then you can simply use the following regex string:


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

      Also available is another regular expression by default:


      If you didn’t use the default, recommended AWS role group syntax, then 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.

    • 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 the Okta SAML assertion. This enables users to view their accounts

      and roles when they sign in.

      Field syntax:

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

      Replace [SAML Provider Name] with the name of the SAML provider that you set up in all of your AWS accounts (see 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

  1. With AWS configured to map AWS role groups to entitlements, assign all AWS management groups to AWS in Okta.


    If you have a configuration with provisioning enabled, you may not be able to assign a management group. In this case, disable provisioning in your configuration and then assign all AWS management groups to the AWS app in Okta.

  2. Verify that users can access AWS from their Okta end-user Dashboard and sign-on is seamless.