Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

AWS IAM Identity Center w/ multiple of the same external IdP's - Architecture Advice

0

Looking to create an architecture with the following:

AWS workspaces secure browser with IAM Identity Center to allow my external users to use SSO capabilities using their current IdP's.

There are multiple external source IdP tenants but they are all the same IdP (e.g. CyberArk), I want to connect all of them. I'm reading conflicting information on AWS Articles and some in the docs on what IAM Identity Center actually supports in terms of multiple external IdP's.

I see some having to create a hub and spoke model (congregate all of the external idps into one central IdP before connecting to IAM Identity Center) and others suggest you can just set up each separate IdP tenant to an integrated connection in IAM Identity Center.

Does anyone have experience or advise on this / a reference architecture I can use?

  • Florian Turnwald EXPERT
    a month ago

    If my answer helped, I would appreciate it if you click on “accepted answer”

Topics
End User ComputingSecurity, Identity, & Compliance
Tags
AWS IAM Identity CenterAmazon WorkSpaces Secure BrowserAWS Identity and Access ManagementSecurity, Identity, & Compliance
Language
English
asked a month ago111 views
2 Answers
5
Accepted Answer

The short answer is: No, AWS IAM Identity Center does not natively support multiple external SAML Identity Providers (IdPs) simultaneously. You can only configure one external identity source per AWS Organization.

The conflicting information you encountered usually refers to connecting multiple applications to AWS, but for the inbound workforce identity source, the ratio is strictly 1:1. For your use case, the Hub-and-Spoke model is the standard industry reference architecture.

evidenz

"No. At any given time, you can have only one directory or one SAML 2.0 identity provider connected to IAM Identity Center."

Source: https://aws.amazon.com/iam/identity-center/faqs/

To achieve your goal with multiple CyberArk tenants, you have two primary architectural options:

1. The Hub-and-Spoke Model (Recommended)

You must use an Identity Aggregator / Broker (like Okta, Entra ID, or a central PingFederate instance) as the "Hub."

  • Flow: IAM Identity Center connects to your one central Hub IdP. The Hub IdP then manages the federation/trust relationships with the various external CyberArk "Spoke" tenants.
  • Why: This is the only way to maintain the centralized management benefits of IAM Identity Center (Permission Sets, Assignment, etc.).

2. Direct IAM Federation (The "Non-Identity Center" Way)

If a central broker is not an option, you cannot use IAM Identity Center for these users. Instead, you must set up standard IAM SAML 2.0 Identity Providers directly within each target AWS account.

  • Flow: Each CyberArk tenant is added as an IdP in the IAM console of the respective accounts.
  • Cons: You lose the central SSO portal and the ease of managing permissions across the organization via the Identity Center.
EXPERT
answered a month ago
EXPERT
reviewed a month ago
  • SoundsAndNothing
    a month ago

    Thank you for the clarification, I'll accept that post as the answer, a follow up question - I was pushed into IAM Identity Center because of the use of the AWS Workspace Secure Browsers to enable BYODs, I thought Identity Center was required for workspace secure browser but I can see now theres a "Standard" authentication option. Knowing I am dealing with Multiple external customer IdP's (these are not within external AWS accounts or any accounts owned by my AWS Organisations service) would the IAM Identity Center with Hub and Spoke model still remain the most appropriate approach?

4

Regarding your comment - hat is an excellent follow-up question.

You are correct: WorkSpaces Secure Browser offers a 'Standard' authentication type that allows you to bypass IAM Identity Center and connect a SAML 2.0 IdP directly.

In short: While the 'Standard' option removes the IAM Identity Center requirement, it shifts the complexity to portal management. For a multi-tenant BYOD strategy, the Hub-and-Spoke model is still the professional gold standard."

However, even with this option, the Hub-and-Spoke model (using IAM Identity Center or a central Broker) remains the most appropriate approach for your specific scenario for the following reasons:

1. The 1:1 Mapping Limitation

In the 'Standard' configuration, one WorkSpaces Secure Browser portal maps to exactly one SAML IdP.

  • The Problem I see here: If you have 5 different customer CyberArk tenants, you would have to deploy and manage 5 separate Secure Browser portals.
  • Hub-and-Spoke Advantage: You deploy one single portal. Your central Hub (the Broker) handles the "Identity Discovery" and routes users to their respective CyberArk tenant.

2. User Experience (URL Management)

  • Without a Hub: Each group of customers needs a different URL to access their browser instance. This becomes an administrative nightmare as you scale.
  • With a Hub: Every user, regardless of their source IdP, goes to the same URL.

3. Infrastructure Overhead

Managing multiple Secure Browser portals means managing multiple sets of networking configurations, security groups, and potentially different access policies across your AWS environment. Centralizing this via IAM Identity Center keeps your AWS footprint "clean."

My Recommendation here:

  • Use "Standard" Auth if: You only have 1 or 2 external IdPs and don't mind managing separate portals for them.
  • Use Hub-and-Spoke if: You expect to onboard multiple customers/tenants over time. It is the only way to provide a unified entry point and keep your AWS configuration DRY (Don't Repeat Yourself).

Hope this finally answers the follow up question !?!

Regards, Florian

EXPERT
answered a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content