amazon-web-services single-sign-on adfs aws-control-tower aws-landing-zone

How do I use AWS Control Tower but ignore the AWS SSO feature in favor of a custom ADFS approach?

Goal: To use all of AWS Control Tower's features except AWS SSO, because the organization I'm working with doesn't want to change any aspect of identity management and single-sign-on at this time.

Currently, this organization uses ADFS in their datacenter for SSO with MFA and has some automation and processes for setting up a new AWS account with that identity solution.

I do not care if this integration with ADFS is triggered to run automatically upon a new account creation, since the organization hasn't had that level of automation for identity yet and the goal is not to change that.

The AWS Control Tower FAQs recommend using the Landing Zones solution instead of Control Tower if you have want a more custom approach:

While Control Tower automates creation of a new landing zone with pre-configured blueprints (e.g., AWS SSO for directory and access), the AWS Landing Zone solution provides a configurable setup of a landing zone with rich customization options through custom add-ons (e.g., Active Directory, Okta Directory) and ongoing modifications through a code deployment and configuration pipeline.

The CloudFormation templates and guides for the landing zones approach is here:

CloudFormation Landing Zone Initiation Template: https://s3.amazonaws.com/solutions-reference/aws-landing-zone/latest/aws-landing-zone-initiation.template
AWS Landing Zone Developer Guide: https://s3.amazonaws.com/solutions-reference/aws-landing-zone/latest/aws-landing-zone-developer-guide.pdf
AWS Landing Zone Implementation Guide: https://s3.amazonaws.com/solutions-reference/aws-landing-zone/latest/aws-landing-zone-implementation-guide.pdf
AWS Landing Zone User Guide: https://s3.amazonaws.com/solutions-reference/aws-landing-zone/latest/aws-landing-zone-user-guide.pdf

But I want it all: the ease of Control Tower and using a custom identity approach. Also, the organization uses Terraform, so I don't want to introduce a bunch of CloudFormation templates, and the AWS Terraform Landing Zone Accelerator (TLZ) has not been released yet despite having been announced over a year ago.

AWS Control Tower's Account Factory requires you to enter an AWS SSO email address, so it seems like there's no way around some use of AWS SSO, at least during initial setup, or "account enrollment":

Another aspect of this: since the organization uses ADFS to get into AWS, I cannot access an account created by AWS Control Tower via a switch role to the AWSControlTowerExecution which Control Tower creates, because I'm logged into the Control Tower (master) account via federation.

(The principal in the AWSControlTowerExecution role's trust relationship is the master account number. When you're authenticated via federation, AWS doesn't see your principal as part of the account you have federated into, therefore the AWSControlTowerExecution role doesn't trust me, the federated user, so to speak.)

Solution

You can use AWS SSO as the Control Tower defaults, including AWS SSO, use the SSO user to get into the new account and configure ADFS, and then render the SSO user useless via an AWS Service Control Policy (SCP).

So in Account Factory, enter an email address and name for the SSO fields as it asks.

As you mentioned, ControlTower automatically creates a role in each new account that an admin in the master account can switch into without additional configurations.

However, since you're in the master account through federation, you can instead get into the new accounts by accepting the SSO invitation received via email.

That will ask you to create a password, and then to log-in via the link you can find in Control Tower > Users and access > User portal URL.

Once you're in a newly created account via that AWS SSO log-in, you can set up ADFS using your organization's process.

Once you've confirmed the ADFS integration works and you can get into the new account via ADFS, you can deny all actions to the placeholder AWS SSO user you used during account setup, by adding the following SCP:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAWSSSOUser",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringLike": {
                    "aws:PrincipalArn": [
                        "*AWSReservedSSO*"
                    ]
                }
            }
        }
    ]
}

The SSO user would still be able to log-in to that account, but not be able to do or see anything.

However, in order to streamline this, you may want to wait until all accounts have been created to add this SCP. That way, you can first create the OU for the new accounts in AWS Organizations, then move the new accounts into that OU, and finally apply this SCP to the whole OU.

This SCP-attachment does not have the risk of locking you out, because as backup/break-glass access, you can still create an IAM user in the master account and switch roles into the Control Tower-created account.