AWS SSO backed by Google Workspace: Troubleshooting and surprising resolution

By Miroslav Kohútik

28 June 2024

Last year, in July 2023 I started to work on Berops' SSO for our AWS company account. Armed with experience gathered during my previous work on the company Azure SSO config I thought this would be just another SSO setup, not much different from the one in Azure.

AWS approach

I started by following the official guide available in the AWS blog section. First thing I noticed was a changelog of edits, the guide seems to be regularly updated to accommodate any changes to the procedure over time. The guide also explains the individual steps very clearly and even contains highlighted screenshots of the exact actions you have to take. This was a very good sign and I had a feeling that this setup was going to be quick and easy.

Before enabling SSO, the guide instructs you to set up your IAM Identity Center. Our company account on AWS already had an IAM Identity Center configured, since we have been using AWS (although not very intensively) for some minor tasks over the years. I changed the config of the IAM Identity Center to prepare it for SSO use. I noticed that the Center was located in North Virginia, which did strike me as a bit odd, since we are located in central Europe, but as far as I was concerned, the location shouldn't really matter.

I continued with the SSO config as described in the guide, I set up an AWS organization, set Google Workspace as the Identity source, set up the AWS IAM Identity Center app in Google Workspace and enabled automatic user provisioning using ssosync. With everything configured as required, it was now time to test user provisioning and SSO.

This is where things started to go wrong. I tried logging in via the Google AWS SSO app using my Google account:

Google AWS IAM Identity Center app

And that's when I got my first error:

Looks like your session timed out or stopped working. Please restart your workflow.

Error#1: Looks like your session timed out or stopped working. Please restart your workflow

This led me down a pretty deep rabbit hole. I started by googling the error message, but it pretty much looked like no one encountered this exact error before me (or at least they didn't post about it anywhere).

Next, I went through the official AWS SAML federation troubleshooting guide, but none of the errors matched mine. I then moved on to searching for general problems other people had with configuring Google Workspace as AWS IDP. Out of pure desperation I even deleted all of my IDP configuration and started from scratch more than once, hoping I would rectify a mistake I may have made before.

Google Workspace approach

During this desperate phase, I came across an alternative configuration guide in the Google Workspace Admin Help section titled Amazon Web Services cloud application. This guide even has an auxiliary guide to configure AWS auto-provisioning, a feature that the AWS guide claims is not supported yet (though AWS did announce it in a separate post as I would find out later).

I deleted my old SSO config and started following the Google Workspace approach. Again, I felt pretty hopeful about this guide since it seemed more up-to-date thanks to the auto-provisioning part. 

The Google Workspace approach is quite distinct from the AWS one, one notable thing is that it uses a different web app. The AWS approach instructs you to set up a custom web app while the Google Workspace approach just needs you to choose an existing app from the library. After carefully following the guide, I was again ready to test the SSO setup.

I tried logging in via the new Amazon Web Services app:

Google Amazon Web Services app

And again I got an error, though a different one this time:

Your request included an invalid SAML response

Error#2: Your request included an invalid SAML response

This exact error can be found in the troubleshooting guide I mentioned earlier, but I didn't manage to fix it with its help.

I spiraled into another bout of fruitless searching for similar issues and validating my configuration. I was about to delete my config and redo it again when I realized something: even though I deleted and recreated the SSO config several times, I never recreated the IAM center itself. I wasn't sure how safe it was to remove the IAM center, in the worst case I might end up locking myself (and others) out of AWS. I knew for a fact that at the time we had no resources running in AWS, so in the end I decided to replace it and just see what happens.

After creating a new IAM Center located in Central Europe I followed the Google Workspace guide to configure SSO with auto-provisioning. I tested the SAML login and it worked on the first try. I created a new user in Workspace and the user was auto-provisioned to AWS in a matter of minutes.

To this day I'm still not 100% sure what really went wrong. I like to think that it's unlikely that I kept making mistakes in my configuration nor do I think it was caused by the distant location of the IAM center from where I tried to sign in. It may have also been the IAM Center's age - at this point, the resource was 1700+ days old. AWS itself had gone through a lot of upgrades over the years and that may have affected the untouched resource.