[paranoidrobot]

I'm not sure I see the benefit of this over using the built-in functionality of AWS SSO[1] which is built into AWS and integrates with Control Tower.

If you want to use it's internal iDP - you can. If you want to authenticate against GSuite or another SAML provider, you can do that, too.

[1] https://aws.amazon.com/single-sign-on/

[solatic]

AWS SSO has one huge gotcha that makes it nigh impossible to use well (from a security perspective). Instead of using bog-standard IAM roles, AWS SSO reinvents the wheel and asks you to create a "Permission Set". What's the difference between a Permission Set and an IAM role? Whereas with an IAM role, you can attach multiple IAM policies to a single role, with a Permission Set you can only use a single inline policy or AWS managed policies. A single inline policy is nearly impossible to maintain, you reach maximum policy size extremely quickly, and AWS managed policies are a security nightmare with wildcards everywhere.

And behind the scenes, AWS SSO sets up the exact same SAML infrastructure that is available to you already in IAM, just with roles with unpredictable names (so that it's difficult to programmatically attach policies) with "DONOTDELETE" as part of the name but no actual SCP in place to prevent the role from being deleted. Because it's the same exact SAML infrastructure, but with additional redirects to allow you to login through the AWS SSO start page instead, it's slower compared to setting up SAML access per AWS account directly.

AWS SSO is a horrible product that actually encourages poor security practice (i.e. AWS managed policies, because a single inline policy is not large enough) and really the only reason why anybody bothers using it is because SAML login from the AWS CLI tooling is not well-supported by AWS.

[dhess]

Prior to AWS SSO and Control Tower, we followed best practices and used an "identity hub" account in our organization, tied to our IdP via SAML. Users authenticated via SAML into their identity hub role, and that role could then `sts:AssumeRole` to any other roles they needed to do their work.

We've since adopted AWS SSO and Control Tower, and to address the problems with it that you mention, we configure the SSO permission set so that the only thing the user can do is assume their identity hub role. Because you can chain `AssumeRole`, it's an extra indirection, but everything works just like it did before.

So while I agree that AWS SSO is not the right place to configure fine-grained permissions, I think that overall I prefer the benefits of Control Tower and the relatively easy SAML integration provided by AWS SSO over the previous bespoke SAML configuration we used. It's a bit inconvenient to set up the extra hoop to jump through to go from SSO permission set to identity hub IAM Role, but that's a one-time cost and is trivial to maintain.