↓ Skip to main content
CloudKeep
  1. Notes/

Three Gotchas Connecting Google Workspace to AWS IAM Identity Center

·4 mins
AWS Iam-Identity-Center Sso Google-Workspace Saml
Table of Contents

AWS Identity Center (the artist formerly known as AWS SSO) with Google Workspace as the external IdP is the modern, supported way to give Google-authenticated users access to AWS accounts. The official setup walkthrough is clean if everything goes right. In a recent migration we ran into three things that don’t — and aren’t mentioned.

This note lists them with symptom, root cause, and fix for each.

Gotcha 1: SCIM provisioning only works on the catalog SAML app
#

Symptom. You set up the SAML side using a “Custom SAML app” in Google Workspace because it has fewer required fields than the catalog app (no mandatory Role / RoleSessionName attribute mappings). Later, when you want SCIM to auto-provision users from Google into IAM Identity Center, you discover the Custom SAML app has no auto-provisioning section in its config UI.

Root cause. Auto-provisioning in Google Workspace is a feature of catalog apps, not Custom SAML apps. There’s no way to enable SCIM on a Custom SAML app — you’d have to delete it and start over with the catalog Amazon Web Services (SAML) app.

Fix. Use the catalog Amazon Web Services (SAML) app from the start, even though its required attribute mappings are annoying. Save yourself the migration. If you’re already on Custom SAML and want SCIM, the path is: set up the catalog app from scratch in parallel (with new SP metadata uploaded to AWS IIC), test, then disable Custom SAML.

Gotcha 2: Google’s “Test SAML Login” button does not validate IIC integration
#

Symptom. You finish wiring up SAML, click “Test SAML Login” in the Google Workspace admin UI for the AWS SAML app, and get: It’s not you, it’s us. We couldn’t complete your request right now. Please try again later. Or AWS returns 400 to the SAML POST. Meanwhile, the real aws sso login flow works.

Root cause. “Test SAML Login” performs IdP-initiated SAML: Google generates a signed assertion and POSTs it to the configured ACS URL without an AuthnRequest context from AWS. AWS IAM Identity Center’s ACS endpoint is built around SP-initiated SAML (AWS issues an AuthnRequest, IdP responds). Without the SP-initiated context, AWS IIC has nowhere to bind the assertion and rejects it.

The same applies to Google’s app launcher (the waffle menu icon for the AWS app) — it also uses IdP-initiated SAML and so also fails with AWS IIC, even though it feels like a “real” login.

Fix. Don’t use Test SAML Login or the waffle menu icon as your validation step. They don’t exercise the production flow. Real validation: run aws sso login --profile <your-profile> from the CLI, or navigate directly to the IIC access portal URL (see Gotcha 3 for which URL works).

Gotcha 3: AWS publishes two ACS URLs but Google supports only one
#

Symptom. You configure Google’s SAML app with one of AWS’s published ACS URLs. CLI login works but the new-architecture portal URL (https://ssoins-<id>.portal.<region>.app.aws) fails with a 400. Or vice versa: the portal works but CLI fails.

Root cause. AWS’s SP metadata XML declares two Assertion Consumer Service URLs:

  • https://us-east-1.signin.aws.amazon.com/platform/saml/acs/<id> (older format, index="0", isDefault="true")
  • https://us-east-1.sso.signin.aws/platform/saml/acs/<id> (newer format, index="1")

Different AWS surfaces emit AuthnRequests with different AssertionConsumerServiceURL values:

  • aws sso login → uses the older ACS URL
  • https://ssoins-<id>.portal.<region>.app.aws → uses the newer ACS URL
  • https://d-<id>.awsapps.com/start → uses the older ACS URL

Google’s SAML app config has exactly one ACS URL field. So whichever you pick, the corresponding subset of AWS surfaces works and the other subset breaks. When the mismatch hits, Google’s SAML response contains a clean error message that the SAML-tracer extension can decode:

StatusCode: urn:oasis:names:tc:SAML:2.0:status:Requester
              urn:oasis:names:tc:SAML:2.0:status:RequestDenied
StatusMessage: Invalid request, ACS Url in request <X>
               doesn't match configured ACS Url <Y>.

The AWS docs flag this limitation only in the multi-Region context, but it bites single-Region setups too.

Fix. Pick the older signin.aws.amazon.com/platform/saml/acs/... ACS URL in Google’s config. Use the https://d-<your-identity-store-id>.awsapps.com/start URL as your browser portal (it also uses the older flow). Tell users to bookmark that, not the app.aws URL. The new-architecture portal stays broken until Google supports multiple ACS URLs.

Symmetry rule. Whatever you pick for ACS URL, also pick the matching format for the Start URL in the same Google SAML app config. Mixing them (e.g. old ACS + new Start URL) breaks the app launcher’s IdP-initiated flow path even when CLI works.

What actually validates the integration
#

After all of the above, the validation steps that actually exercise the production path:

  1. aws sso login --profile <profile> from the CLI — completes browser flow, returns to terminal with new tokens.
  2. aws sts get-caller-identity --profile <profile> — returns an AWSReservedSSO_* assumed-role ARN with your IIC username as the session name.
  3. Browser-navigate directly to https://d-<identity-store-id>.awsapps.com/start — see the AWS access portal with your assigned accounts and permission sets.

Skip: Test SAML Login button, app launcher waffle menu icon, the https://ssoins-<id>.portal.<region>.app.aws URL. They’re all known-broken with AWS IIC + Google Workspace at the time of writing.