0

My client has 5 different identity and access management solutions. Until now they have been asking each one of their suppliers to add 5 trusted parties to their IAM solution, implement different URLs that will trigger SSO etc. It is now proposed that a new component is introduced in between the company's IAM and the suppliers' so that there is a single point for managing logs and reducing the effort required from the suppliers.

Is it technically possible to implement it, for example using ADFS or Azure AD? Has anyone implemented a chain of 3 IdPs in the past?

diagram showing company's IAMs on the left, suppliers' IAMs on the right and a new IAM in the middle

aquaman
  • 73
  • 5

1 Answers1

2

I've seen implemented a similar pattern - where a number of "originating" IAM solutions that was where users "lived" where mapped to an external supplier (in this case, a Salesforce based app), by creating a single "externally visible" IDP.

The advantages of this approach are several:

  1. The biggest one, the external suppliers are simpler to configure and maintain as they don't have to add "n" external IDPs (if they support having more than one IDP for a given customer/tenant!!!)
  2. The security of the service offered by the supplier is enhanced, as there's a single point for configuration/validation (vs having 5 "peer" trust sources that open up 5x the potential attack surface)
  3. The "source" IAM systems don't have to be exposed externally as only one "visible" IDP is created
  4. The "bridge" IDP/IAM solution can apply transforms and enforce a consistent set of claims and attributes that are exposed to the external suppliers, without needing to re-configure the source systems. This makes easier to adopt to changes in the suppliers, or to different requirements in the suppliers federation config.
  5. You can also do protocol transformation. In the case I'm familiar with, the left-hand internal IAM systems were using a mix of SAML and OIDC, while the outgoing federation was using OIDC
  6. Specific to this implementation, but not strictly needed, the "New IAM" solution included a user repository and a unified/centralized identity per "real" user was created for the users in the "source" IAM systems; a given living user could have different accounts in the different source IAMs, and the objective was to ensure that the externally visible account was the same, regardless of how the user was logged-on internally...

The way this worked was, the "New IAM" solution was configured to act as an SP for the left hand "source" IAM systems, that were acting as IDPs. The "incoming" federation request was validated, the specific policies configured in the NewIAM stack for access and transformation are checked, and if all matches, the user is redirected to the external supplier. The external supplier is configured to query the "New IAM" solution, that in this case acts as IDP.

It sounds somewhat convoluted, but it's simpler in practice than it sounds... the system is working fine, and orchestrating ~5 M users and expecting bigger growth.

Hope this helps!!

JJarava
  • 232
  • 1
  • 4
  • 9