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.
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.
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.
Quoting original link:
> The regular approach taken by many software companies is either:
> Using expensive SSO solutions (3rd party single sign-on SaaS platforms) and writing custom CLI toolkits for integrating with said platforms for programmatic AWS access (early and unnecessary complexity, financial and development time costs). > Or not using any MFA at all and just using plain permanent AWS IAM user credentials (terribly insecure).
saml2aws is open-source code that anybody can use and contribute to, and can be used off-the-shelf. Google Workspace is "free" in that we were already using it and paying for it. Meanwhile the approach asked for in the parent, with a hub and spoke model, requires long-lived IAM users in the hub account that need to be managed separately from the company's SSO directory and thus violates SSO principles.
Sorry, it's hard to find a new problem these days with all these engineers around. Your learned some things along the way though, I'm sure, so all is not lost.
This extends well to my kubeconfig which make use of these specified profiles to login. So I just run saml2aws, and my kubectl contexts also automatically get configured
New tools covering a specific niche, even if that niche is already covered by a bigger, more established tool, are frequent. Not everyone needs or wants the kitchen sink approach. If you're using only CloudFormation to manage AWS, why would you force misery upon yourself to use Ansible just for AWS auth?
* I slightly exaggerate, but i genuinely consider Ansible to be the worst CM tool of the "modern" ones (so excluding CFEngine) at any sort of scale/enterprise. It has so many things wrong it's baffling for me people are removing existing Puppet, Chef, Salt envs to replace them with Ansible. It's awesome for homelabs or similar though.
