The AWS Identity Nightmare
If your enterprise relies heavily on Amazon Web Services (AWS), you understand the nightmare of IAM (Identity and Access Management) sprawl. If you have 50 developers, and you create 50 native IAM users in the AWS Console, you now have 50 highly privileged passwords floating around outside of your central corporate directory. When a developer quits, IT disables their Google Workspace account, but forgets to delete their AWS IAM user, leaving the company vulnerable to a massive data breach.
The solution is to eliminate native IAM users entirely and implement SAML Single Sign-On (SSO) using AWS IAM Identity Center (formerly AWS SSO). In this architecture, Google Workspace acts as the definitive Identity Provider (IdP). Developers simply log into their Gmail, click a single button, and are securely passed into the AWS Console via an encrypted SAML assertion. When a developer quits and their Google account is disabled, their AWS access is instantly and mathematically revoked.
Step 1: Enabling AWS IAM Identity Center
You must configure AWS to stop requesting passwords and start listening for Google’s SAML tokens.
- Log into the AWS Management Console with root or administrative privileges.
- Navigate to IAM Identity Center.
- Click Enable.
- Navigate to Settings and click the Change link next to “Identity source”.
- Select External identity provider.
- AWS will present you with its Service Provider metadata. Download the AWS SAML metadata file. Keep this tab open.
Step 2: Configuring Google Workspace as the IdP
Now, you must instruct Google to generate the cryptographic tokens for AWS.
- Open a new browser tab and log into the Google Workspace Admin Console.
- Navigate to Apps > Web and mobile apps.
- Click Add App > Add custom SAML app.
- Name it
AWS IAM Identity Centerand click Continue. - Google will present its IdP metadata. Download the Google IdP metadata file.
Step 3: The Metadata Exchange
You must now cross-pollinate the metadata between the two tech giants.
- In the Google Admin console (Step 3 of the wizard), click Upload Metadata and select the AWS metadata file you downloaded in Step 1. This automatically populates the ACS URL and Entity ID.
- On the Name ID screen, ensure the format is set to
EMAILand the mapping is set toPrimary email. Click Finish. - Return to your open AWS Console tab.
- Upload the Google IdP metadata file you downloaded in Step 2 into AWS. Click Next and confirm the change.
Step 4: Provisioning Users via SCIM (Automated Provisioning)
SSO only works if AWS knows that the user actually exists. Instead of manually typing 50 developer names into AWS, you should configure SCIM (System for Cross-domain Identity Management).
- In the AWS IAM Identity Center settings, locate the Automatic provisioning section and click Enable.
- AWS will generate a SCIM endpoint URL and a Secret Access Token. Copy both.
- Return to the Google Workspace Admin console.
- Open your new
AWS IAM Identity Centerapp settings and click Auto-provisioning. - Paste the AWS SCIM URL and Secret Token.
- Map the Google attributes (First Name, Last Name, Email) to the AWS attributes.
- Click Turn on.
Google will now immediately connect to AWS in the background. It will automatically create all 50 developer accounts inside AWS, matching their exact Google email addresses. If a developer gets married and changes their last name, Google pushes the update to AWS instantly.
Step 5: Activating the App
The final step is to grant your developers permission to use the SSO app.
- In the Google Admin console, go to the
AWS IAM Identity Centerapp settings. - Click User access.
- Change the status to ON for everyone (or restrict it to the Engineering OU).
When an engineer opens their Google Workspace App Launcher (the “waffle” menu in the top right of Gmail), they will see a new AWS icon. Clicking it bypasses the AWS login screen entirely, securely dropping them into their assigned AWS roles.