Continuing the latest theme of Control Tower and the recent deep-dive journey into it, I’ve come to appreciate that there are a lot of things it does well and have learned what to avoid to keep it running smoothly. In this blog, I’ll share my experience with what was a rather innocuous task – changing the URL of Identity Center login portal. Strap yourself in – it is a doozy!
What Is AWS Identity Center?
The AWS Identity Center service (formerly AWS Single Sign-On) is a managed identity platform for managing users and groups outside of IAM Users. The Identity Center users and groups share nothing in common with IAM Users. They are independent entities. It is also designed to integrate with third-party identity providers. Your identity source in IAM Identity Center defines where your users and groups are managed. After you configure your identity source, you can look up users or groups to grant them single sign-on access to AWS accounts, applications, or both.
You can have only one identity source per organisation in AWS Organizations. You can choose one of the following as your identity source:
- External identity provider – Choose this option if you want to manage users in an external identity provider (IdP) such as Okta or Microsoft Entra ID.
- Active Directory – Choose this option if you want to continue managing users in either your AWS Managed Microsoft AD directory using AWS Directory Service or your self-managed directory in Active Directory (AD).
- Identity Center directory – When you enable IAM Identity Center for the first time, it’s automatically configured with an Identity Center directory as your default identity source unless you choose a different identity source. With the Identity Center directory, you create your users and groups, and assign their level of access to your AWS accounts and applications.
Permission Sets
A concept Identity Center has is called Permissions Sets. A Permission Set has users or groups assigned to them and an accompanying IAM policy or set of policies associated to it. A Permission Set is assigned to AWS Accounts, thereby granting access for a user or group to those accounts with an associated IAM policy governing what actions a user can do. When paired with an identity provider, users and groups from that provider are automatically populated into the Identity Center directories. These can then be used to map to a Permissions Set – granting those identities access to accounts they can access.
IAM Access and Secret Keys
Another distinguishing feature of Identity Center is that you can not create long-lived IAM Access and Secret keys for Identity Center users. Instead, temporary Access and Secret keys along with a session token are generated each time a user logs onto the portal. The keys and token are only valid for the duration of the session timeout (default 1 hour – can be set up to 8 hours max). This improves the default AWS security posture substantially.
Deploying AWS Identity Center
The Identity Center console allows you to build one and setup your identity providers as part of the setup or you can use Control Tower to build this for you as part of the secure Landing Zone. When creating your own, you need to manually configure groups.
When deploying Control Tower, it builds an Identity Center instance on your behalf, configures it with pre-defined permissions sets, pre-defined groups, creates a new Identity Center user matching the root account user and invites the root user into the Identity Center instance via email – all very useful in bootstrapping Identity Center.
Accessing AWS Console via Identity Center Web Portal
The default web portal URL represents the unique ID of a given Identity Center instance like this:
“https://d-12345abcd.awsapps.com/start”
Identity Center allows you to edit this URL to something more meaningful to you, such as your sub-domain name. It doesn’t have to be the name of a domain you own, however it must be globally unique. It’s a trivial task that takes seconds to set and away you go. Users access the web portal to login to the AWS Console instead of the IAM user console. For example:
“https://bobschickenlickinemporium.awsapps.com/start”
Relationship Between Identity Center and Control Tower
It is important to understand that Control Tower manages a configuration state as part of a manifest that we cannot see. This comprehensive manifest contains everything that is managed by Control Tower, including the details of the Identity Center instance it created during the creation of the secure Landing Zone. This means that messing with this configuration causes drift – something Control Tower does not like. After all, this is the whole point of using Control Tower – to protect the resources it manages.
Changing Web Portal for Identity Center
What happens when you need to change it though (such as a typo, a company merger name change or a rebranding takes place and the old one is no longer relevant?
No big deal – I’ll just go in and change it like I did before in the console, right? Wrong!
You CANNOT change the URL once it is set in your Identity Center instance!
Don’t believe me? Here is the document with the warning all over it!
Customising the AWS access portal URL
So, how do we solve this if Control Tower manages the underlying Identity Center and we can’t change or influence the configuration manifest?
The answer is we don’t “fix” it – we rebuild!
Why is this so?
Interestingly, this makes a lot of sense. When integrating with third-party identity providers, there is metadata mutually shared between the identity provider and Identity Center. This metadata contains the access URL’s. Imagine for a moment you had no IAM users (the whole point of Identity Center) and you were suddenly not able to authenticate into your AWS environment against any account due to another member in your team or yourself updating the URL as self-service. The same thing would happen if AWS changed it. Once you understand this, it becomes clear that there is a valid reason not to mess with it once it is set.
Fixing the Problem - End-to-End Process
1. Go to Control Tower Management Account.
2. Login with the existing Identity Center Portal with Administrator privileges.
3. Go to IAM and create a new IAM User (you’ll need to login using an IAM user before deleting the Identity Center instance).
4. Login to the AWS console using your IAM username and password.
5. Go to Identity Center console: https://ap-southeast-2.console.aws.amazon.com/singlesignon/
6. Go to Settings.
7. Select Management tab.
8. Select Delete on Delete IAM Identity Center Instance.
9. Select all the checkboxes and type in the instance ID before clicking Confirm.
10. The process looks like it is instantaneous, however it takes roughly 5 minutes to complete before you can create a new Identity Instance.
11. Create the new instance and leave it as default.
12. Go to IAM Identity Center and click Edit the AWS access portal URL with the correct subdomain.
13. Configure subdomain.
14. Go to Control Tower Landing Zone Settings: https://ap-southeast-2.console.aws.amazon.com/controltower/home/settings?region=ap-southeast-2
15. Under Versions tab, select Update.
16. Leave all previous settings and select Update.
The process will take roughly 60 minutes to complete depending on how many accounts you have in the Organization. Upon completion, review the Control Tower > Landing Zone Settings > Configuration page and verify this is now updated with your new Identity Center URL.
Conclusion
All of the above seems obvious now, however with a distinct lack of AWS prescriptive guidance to assist, there was a lot of anxiety about the effects an operation of this nature might have with Control Tower management behaviour. I was able to perfectly use Identity Center before updating Control Tower. With Control Tower in drift however with configuration, there was an element of the “unknown” and that can be scary when working with Control Tower.
This process was tested and validated in an isolated Control Tower playground prior and it was successfully repeated in a Live Production Control Tower – proving this method works.
