-
I appreciate your answer, but I still find it hard to visualize the actual flow in the light of everything I’ve read on custom broker identity federation. Could you please help me to see where I am erring?
The web application is deployed in VPC rather than on-premises and you are suggesting that the web application will be calling on-premises custom identity broker, which seems like an architectural antipattern for multiple reasons.First, you are basically allowing an on-premises user to directly access a VPC resource before figuring out whether the user has this entitlement.
Second, you make the application deployed in VPC an authorization orchestrator in addition to providing its core business function which violates the basis of separation of concerns principle. Under your scenario the web application in VPC would first have to call a custom broker on-prem and than also be responsible for calling STS to get temporary credentials that it would later possibly use to make any AWS APIs calls. By extension, if you later developed a second application in your VPC, you would also have to include the authorization orchestrator logic in that app. Yes you could factor this logic out, but under your scenario, the factored out logic would also reside inside your VPC. This is contrary to AWS recommendation that if you use STS directly, rather than using it through Cognito, you would would call STS from on-premises-hosted authorization orchestrator (that would wrap an on-premises-hosted custom broker) and have the same orchestrator redirect to a VPC-hosted app with temporary credentials supplied from a previous call to STS.
