Integrate multiple identity providers with AWS IAM Identity Center using Okta

In this blog post we will guide you on how to use Okta as an identity hub to integrate multiple identity providers with AWS IAM Identity Center. This approach provides users with a consistent authentication experience, enhances security, and simplifies administration.

Introduction

In today’s rapidly evolving business landscape, enterprises face the complex challenge of managing multiple identity stores across their organization. This fragmented identity landscape often results from mergers, acquisitions, or cross-organizational collaboration initiatives, leaving IT teams to wrangle a diverse ecosystem of authentication systems. Whether it’s multiple on-premises Active Directory environments, cloud-based identity solutions like Microsoft Entra ID, or self-hosted Security Assertion Markup Language (SAML) identity provider solutions, organizations need a streamlined approach to manage access across these disparate systems. Integrating these diverse identity sources with cloud infrastructure presents significant operational, security, and governance challenges for many organizations. One way to solve this problem is using a 3rd party identity aggregation or hub solution. An identity hub gathers data about identities and related group memberships in a centralized location.

Organizations onboard different methods to consolidate user and group information from diverse identity sources into a centralized identity hub like Okta. The appropriate integration approach depends on your specific identity providers and business requirements. For enterprises with Active Directory environments, directory synchronization tools like Okta Active Directory agent provide automated user provisioning and attribute mapping. Organizations using cloud identity providers might leverage the System for Cross-domain Identity Management (SCIM) protocol, which automates user lifecycle management with real-time synchronization between systems that support this standard. When automated synchronization options aren’t available, alternative approaches remain viable.

You might choose to manage users and groups directly within the identity hub through manual processes or custom-developed automation scripts. Some implementations utilize SAML assertion attributes to dynamically determine and update group memberships during authentication flows, creating a just-in-time approach to access management. Each method presents different trade-offs regarding complexity, maintenance requirements, and synchronization timeliness. The optimal strategy often involves a combination of these approaches based on your organization’s technical environment and operational capabilities.

Solution overview

In our example, we’ll be using two Entra ID tenants as source identity providers. This solution adapts to SAML identity providers like Active Directory Federation Service (AD FS) and Shibboleth. The approach works effectively with identity providers that do not have a supported SCIM client. For this tutorial we have selected Entra ID because of the simple SAML IdP setup and configuration. We recommend using a supported SCIM client if you have access to one. The solution, as shown in Figure 1, allows you to manage access to your resources across multiple AWS accounts while maintaining authentication at the source identity provider.

Figure 1: Multiple SAML identity providers integrated with Okta to present a single external identity provider to AWS IAM Identity Center.

In this architecture, both Entra ID tenants are configured as identity providers for Okta. Okta serves as the single identity provider for AWS IAM Identity Center. The setup uses just-in-time provisioning, which populates Okta at login time. SCIM provisioning is used to synchronize changes between Okta and AWS IAM Identity Center. With the foundational architecture in place, you can get started with the configuration of your environment.

Prerequisites

You need to complete the following before you begin the walkthrough:

• Okta account with Okta’s IAM Identity Center application.
• AWS Account with IAM Identity Center enabled. For more information, see how to enable IAM Identity Center.
• Okta as an identity provider (IdP) and SCIM client for IAM Identity Center as described in steps 1, 2 and 3 of Configure SAML and SCIM with Okta and IAM Identity Center.
• Azure account subscription containing two Entra ID tenants. Microsoft Entra ID P1 or P2 licenses are required for group-based assignment.

Walkthrough

Step 1: Set Up Groups representing different access levels

Create three groups in each Entra ID tenant. Two groups represent different role-based access that will be used to grant your employees access to AWS resources. The third group is used for assignment to the Okta app.

1. Sign in to the Microsoft Entra admin center with your credentials
2. Select Groups > All groups > New group
3. In the Create group form:
   • For Group type, select Security
   • For Group name, enter IT Operations
   • For Group description, enter IT Admin access to AWS
   • Leave other settings as default
   • Click Create
4. Repeat steps 2-3 to create two more groups:
   • Group name: AWS All Staff and Group description: AWS read-only access
   • Group name: AWS IAM Identity Center Assignment and Group description: Assignment to the Okta app

Configure Second Entra ID tenant: Sign out of the first tenant if needed and sign in with administrator credentials for the second Entra ID tenant. Follow the same steps as above to create identical groups.

By the end of this step, you should have three groups in each Entra ID tenant (six groups total)

Step 2: Test user account creation

Next you will create a test user account in each of your Entra ID tenants by following the instructions in this QuickStart. Create a user account steps in the Entra ID. Be sure to change “anyorganizationx.onmicrosoft.com” to the name of your tenant domain.

Entra ID tenant 1

• User principal name: RichRoe@anyorganization1.onmicrosoft.com
• Display name: Rich Roe
• Email address: RichRoe@anyorganization1.onmicrosoft.com
• Group membership: AWS IAM Identity Center Assignment, IT Operations, and AWS All Staff

Entra ID tenant 2

• User principal name: JohnStiles@anyorganization2.onmicrosoft.com
• Display name: John Stiles
• Email address: JohnStiles@anyorganization2.onmicrosoft.com
• Group membership: AWS IAM Identity Center Assignment and AWS All Staff

Step 3: Configure Okta as a service provider for Entra ID

You need to delegate authentication to your two Entra ID tenants. This allows user authentication to be controlled at the source tenant enabling Okta to redirect authentication requests to the appropriate identity source based on the user account domain name.

1. Follow Okta’s integration guide to add Entra ID as an Identity Provider
2. Follow the instructions in Map Azure Active Directory attributes to Okta attributes. When you map the Entra ID attributes to Okta use the following mappings, as shown in Figure 2:
   • userName → login
   • firstName → firstName
   • lastName → lastName
   • email → email

Figure 2: Mapping Entra ID attributes in the SAML assertion to Okta.

3. Enable group claims in Entra ID, as shown in Figure 3:
   • In Entra admin center, go to Identity > Applications > Enterprise applications
   • Select your Okta enterprise application
   • Navigate to Single-sign-on > Attributes & Claims
   • Select Edit and then Add a group claim
   • Select the Groups assigned to the application option
   • Select Cloud-only group display names from the Source attribute drop-down menu
   • Save the configuration

Figure 3: Adding a group claim to the Entra ID SAML assertion.

4. Ensure that the groups for SSO are added to the users and groups of this application
5. Follow the instructions in Test the Azure Active Directory integration

Note: Repeat the actions above for the second Entra ID tenant.

With the current configuration that you have of Okta as service provider and Entra ID tenants as identity providers, Entra ID initiated authentication will be required. For example, when a user launches the enterprise application from the My Applications portal, the SAML token will be sent to and processed by Okta. You need to configure Okta routing rules so that your when users access the application using the Okta login portal or the AWS access portal they will be directed to the appropriate identity provider. Read more about this in Okta’s documentation on the subject. To create identity provider routing rules:

1. Sign in to the Okta Admin Console, go to Security > Identity Providers
2. On the Routing Rules tab, select Add Routing Rule.

Be sure to change “anyorganizationx.onmicrosoft.com” to the name of your tenant domain.

• Entra ID tenant 1
  • Rule Name: anyorganization1.onmicrosoft.com
  • AND User matches: Domain list on login
  • anyorganization1.onmicrosoft.com
  • THEN Use this identity provider: Entra ID tenant 1
• Entra ID tenant 2
  • Rule Name: anyorganization2.onmicrosoft.com
  • AND User matches: Domain list on login
  • anyorganization2.onmicrosoft.com
  • THEN Use this identity provider: Entra ID tenant 2

3. Click Create Rule and Activate to immediately apply the configuration.

Step 4: Configure Okta groups

In this example we are operating under the assumption that SCIM or another automated user/group synchronization is unavailable. Without an automated means of populating the user and group data in Okta, and eventually downstream to AWS, you will need to manually create the groups in Okta. To create the groups, as shown in Figure 4, follow these steps:

1. Sign in to the Okta Admin Console, go to Directory > Groups > Add Group
2. For the assignment group:
   • Enter AWS IAM Identity Center Assignment in the Name field
   • Enter All AWS Users in the Description field
   • Click Save
3. For the first push group:
   • Click Add Group again
   • Enter IT Operations in the Name field
   • Enter IT Admin access to AWS in the Description field
   • Click Save
4. For the second push group:
   • Click Add Group again
   • Enter AWS All Staff in the Name field
   • Enter AWS read-only access in the Description field
   • Click Save

Figure 4: Creating the Okta assignment group, push groups, and mapping groups.

Important: In Okta, a group cannot be both an assignment group and a push group, which is why we’ve created separate groups for these purposes. The assignment group controls access to the Okta application, while the push groups determine which groups will be SCIM provisioned to AWS IAM Identity Center. As illustrated in Figure 5, create the app assignments:

1. Sign in to the Okta Admin Console
2. Select Applications > Applications
3. Select your AWS IAM Identity Center application and view the Assignments tab
4. Select the Assign button and choose Assign to Groups from the dropdown options.
5. Select Assign next to your AWS IAM Identity Center Assignments group
6. Select Done.

Figure 5 – Assign AWS IAM Identity Center Assignment group to Okta application.

As shown in Figure 6, assign your groups to Push Groups:

1. In the Okta Admin Console, select Applications > Applications
2. Select your AWS IAM Identity Center application and view the Push Groups tab
3. Select the Push Groups button and choose Find groups by name from the dropdown options.
4. Enter IT Operations for the Name.
5. Select the Save & Add Another button.
6. Enter AWS All Staff for the Name.
7. Select the Save button.

Figure 6 – Assign Groups to Push Groups that will be synchronized to AWS IAM Identity Center.

Step 5: Create Permission Sets in AWS IAM Identity Center

1. Open the IAM Identity Center console.
2. Under Multi-account permissions, choose Permission sets.
3. Choose Create permission set.
4. On the Select permission set type page, under Permission set type, select Custom permission set, and then select Next.
5. On the Specify policies and permissions boundary page, expand AWS managed policies.
6. Search for and choose AdministratorAccess policy, and then select Next.
7. On the Specify permission set details page enter IT-Operations for the Permission set name and select Next.
8. On the Review and create page, review the selections, and choose Create.

Step 6: Assign Group Access in Your AWS Organization

1. In the navigation pane, under Multi-account permissions, choose AWS accounts.
2. On the AWS accounts page, select the check box next to one or more AWS accounts to which you want to assign access.
3. Choose Assign users or groups.
4. On the Groups tab, select the Entra ID Group ID name that maps to the IT Operations group and select Next
5. On the Assign permission sets to “AWS-account-name” page, select the IT-Operations permission set.
6. Check that the correct permission set selected and choose Next.
7. On the Review and submit page, verify that the correct group and permission set are selected, and choose Submit.

Repeat the actions in Step 5 and Step 6 for the AWS All Staff group. For AWS All Staff, use a predefined permission set and select ViewOnlyAccess.

Step 7: Configure Just-In-Time provisioning for users and groups

Enable automatic user and group provisioning in Okta when Entra ID users authenticate, as shown in Figure 7:

1. Sign in to the Okta Admin Console, go to Security > Identity Providers
2. Select Actions next to your first Entra ID tenant and choose the Configure Identity Provider option.
3. Select the Edit option and configure JIT settings:
   • Check all available options in the JIT Settings section
   • Select Full sync of groups from the Group Assignments dropdown
   • Enter the following for the SAML Attribute Name http://schemas.microsoft.com/ws/2008/06/identity/claims/groups
4. Enter the names of the groups associated with the first Entra ID tenant. In the Group Filter field. The Group Filter limits the IDP SAML assertion to modification of specific groups that you permit.
5. Select Update Identity Provider.

Figure 7 – Configure Just-in-Time group user and group settings.

Note: Repeat this process for your second Entra ID tenant to enable JIT provisioning for all identity sources.

Test the Configuration

To verify your setup works correctly, test access with users from both Entra ID tenants:

1. Test Rich Roe (Tenant 1):
   • Sign into My Apps portal, as shown in Figure 8, and select the Okta app

Figure 8 – Select the Okta application from Microsoft My Apps portal.

• Select the AWS IAM Identity Center application from the Okta My Apps portal, as shown in Figure 9.

Figure 9: Selecting the AWS IAM Identity Center application from the Okta My Apps portal

• Verify both IT Operations and AWS All Staff permission sets appear.
• As shown in Figure 10, Select either permission set to confirm appropriate access

Figure 10 – Verify permissions using AWS access portal

2. Test John Stiles (Tenant 2) in a separate browser/private window:
   • Sign into My Apps portal and select the Okta app
   • Verify AWS All Staff permission set appears
   • Select it to confirm read-only access

Note: If permission sets don’t appear immediately, wait a moment for synchronization to complete before retrying.

Troubleshooting

Cleanup

Configuring AWS services from this post will provision resources which incur cost. It is a best practice to delete configurations and resources that you are no longer using so that you do not incur unintended charges. AWS IAM Identity Center is available at no extra charge.

To avoid ongoing charges and maintenance for the resources that you created in Okta and Entra ID, follow these steps:

1. Delete the enterprise application that you created from both Entra ID tenants.
2. Delete the test users and groups that you created from both Entra ID tenants.
3. Delete the Okta app integration for AWS IAM Identity Center.
4. Delete both Okta identity providers.
5. Delete the users and groups that were synchronized to the Okta directory.

Conclusion

In this blog, we’ve shown how to use Okta as an identity hub to connect multiple SAML identity providers with AWS IAM Identity Center. By implementing this pattern, you will address the challenges of managing multiple identity providers, ensure secure, consistent access to your AWS environment, allowing your organization to focus on innovation rather than identity integration complexities.

Additional Resources

• AWS IAM Identity Center Documentation
• Okta Integration Network
• Microsoft Entra ID Documentation
• SAML 2.0 Technical Overview
• Okta Plans and Pricing

AWS has significantly more services, and more features within those services, than any other cloud provider, making it faster, easier, and more cost effective to move your existing applications to the cloud and build nearly anything you can imagine. Give your Microsoft applications the infrastructure they need to drive the business outcomes you want. Visit our .NET on AWS and AWS Database blogs for additional guidance and options for your Microsoft workloads. Contact us to start your migration and modernization journey today.