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:
- 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!!!)
- 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)
- The "source" IAM systems don't have to be exposed externally as only one "visible" IDP is created
- 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.
- 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
- 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!!