AWS is a major cloud provider that allows you to build infrastructure and applications based on hundreds of available services. One such service is AWS IAM Identity Center, formerly named AWS SSO. This service allows you to use an existing identity source like Google Workspace or Microsoft Entra to provide access to the AWS Management Console and API. It helps your company secure your cloud accounts by relying on a single identity for each user.
The SSOSync project, available freely on GitHub, is a solution to help you sync users and groups from Google Workspace to AWS IAM Identity Center. It’s a great addition to the AWS service because it allows you to automatically create and remove users and groups in IAM Identity Center based on the business rules you define.
In essence:
- AWS IAM Identity Center allows a Google Workspace user to access AWS via single sign-on (SSO)
- SSOSync allows you to automatically provision IAM Identity Center users and groups based on Google Workspace users and groups
This article explains how to configure AWS IAM Identity Center and Google Workspace, from establishing AWS IAM Identity Center compatibility with Google Workspace to provisioning accounts using the SSOSync project.
Set Up IAM Identity Center
Once you’re logged in to the AWS Console with your AWS credentials, find the IAM Identity Center via the search bar, then start the process by clicking Enable :
Enabling it with AWS Organizations allows you to manage access to multiple AWS accounts in your organization with a single instance of IAM Identity Center:
Set Google Workspace as an Identity Source
Under Settings > Identity source > Actions, you can specify a different identity source to act as the IDP for IAM Identity Center. By default, it’s the Identity Center directory, but you want to change that to Google Workspace. Click Change identity source from the dropdown menu:
Then, select External identity provider and click Next:
The external identity provider setup relies on the SAML protocol. It’s a classic way to allow an identity provider (like Google Workspace) to be used as the authentication layer for a specific service (here, IAM Identity Center).
Create a SAML Application on Google Workspace
Open a new window (while keeping the window with IAM Identity Center open). On your Google Workspace admin panel, go to Apps > Web and mobile apps and click Add app > Add custom SAML app:
Provide a meaningful name for your users, like AWS IAM Identity Center, a description, and optionally an icon. Then click Continue.
Click the button under “Option 1” to save an XML file locally (`GoogleIDPMetadata.xml`) with all the SAML metadata from the identity provider side:
Click Continue. Then, from the IAM Identity Center page, copy two values to the Google Workspace page:
- Copy the IAM Identity Center Assertion Consumer Service (ACS) URL to the ACS URL field
- Copy the IAM Identity Center issuer URL to the Entity ID field
Keep the Start URL field empty. At the bottom of the page, specify EMAIL for the name ID format and keep the default values for the other parameters. Then, click Continue.
You can also keep the default values for the Attributes and Group membership sections. Click Finish to end the configuration of the SAML application on Google Workspace.
Note that you may need to wait a couple of minutes for the SAML application to be up and running. If you have the message `SAML app can’t load`, then just keep waiting until your application shows properly in the list of applications.
Once it’s created, you’ll need to allow some users to access the SAML application. On Google Workspace, it’s possible to specify permissions at the group level or organizational unit level. For simplicity, allow the application for all users on the Google Workspace domain by clicking User access, then set Service status to ON for everyone and click Save:
Finalize Your IAM Identity Center Configuration
Now, go back to your IAM Identity Center configuration. Under the Identity provider metadata section, upload the file from the previous step (`GoogleIDPMetadata.xml`) using the IdP SAML metadata field:
Look for the green check mark indicating the file is correctly imported, then click Next. The warning section explains the impact of the configuration. Review the consequences and click Change identity source to apply the modification.
Manually Provision Your First User
It’s now time to create your first user and test the SSO connectivity between Google Workspace and AWS IAM Identity Center.
In your IAM Identity Center dashboard, go to Permission sets and click Create permission set. This set will define the access level granted to a particular user or group within a specific AWS account.
For this example, keep it simple and use the Predefined permission set for AdministratorAccess:
Click Next and keep the default name to finalize the permission set.
Then, go to Users and click Add user to create a user. The username must be the email of the Google Workspace user. Provide the correct email for your user and their first and last name. Do not provide a group here. Finalize the user.
Go to AWS accounts, select the AWS account you want to add the users to, and click Assign users or groups. This will provision a defined permission set to either a user or a group within the chosen AWS account.
On the next screen, select the user you just created, then click Next. After that, select the permission set you previously created. Click Next and then Submit.
Test Single Sign-On
Once you’re logged in as the specified user, go to the Start URL defined in the IAM Identity Center (something like `https://d-xxxxxx.awsapps.com/start`) or find the application in the list of Google applications:
This leads to the portal application, which shows you the AWS accounts and permission sets available. On this screen, you’ll see the permission set that you enabled earlier. If you click Management console, it will open the AWS Console using only your Google account. You’ve now successfully connected Google Workspace to your AWS account!
Provision Users and Groups
You now have a working system, but you still need to manually provision users and groups inside IAM Identity Center for each Google Workspace user you want to give access to. While this is feasible for a small number of users, it becomes impractical when dealing with a larger userbase that reaches into the hundreds. IAM Identity Center supports automatic user provisioning using SCIM, but at the time of writing, this feature is not supported by Google Workspace. The next part of the article will help you set up SSOSync to support provisioning.
Create a Google Cloud Project
Go to the Google Cloud console to create a project. This step is necessary to provide the correct credentials to SSOSync.
Click Select a project, then click New project. Give it a meaningful name, like “SSOSync,” and click Create.
Once the project is ready, click Select project in the notification section to open it. Navigate to API & Services > Enable APIs and Services and search for the Admin SDK API:
Click Enable:
You’ll now generate the required service account and keys for using the API from SSOSync. Navigate to API & Services > Credentials. Click Create credentials and then Service account:
Provide a name for the account (like “SSOSync”), then click Create and continue:
Do not grant the service account any access to the project or grant users access to this service account. Once it’s created, click the service account and navigate to the Keys tab. Click Add key > Create new key. Use the JSON key type. This will save a file (`ssosync-xxxx.json`) on your computer that contains the credentials. Keep it safe!
Before going to the next step, you need to store the service account’s unique ID. You can find it on the Details page of the service account:
You now need to add domain-wide delegation to the service account. To do so, visit the Google Workspace admin console as an administrator. Go to Security > Access and data control > API controls > Manage Domain Wide Delegation:
Click Add new. Under Client ID, provide the Unique ID of the service account you just created. Under OAuth scopes, provide the following entries:
- `https://www.googleapis.com/auth/admin.directory.group.readonly`
- https://www.googleapis.com/auth/admin.directory.group.member.readonly`
- `https://www.googleapis.com/auth/admin.directory.user.readonly`
Click Authorize.
Enable SCIM on the IAM Identity Center
Inside IAM Identity Center, navigate to Settings and click Enable under Automatic provisioning:
This will show you the SCIM endpoint. You also need to take note of the SCIM token by clicking Show token. You will need both values later.
Deploy SSOSync via the AWS Serverless Application Repository
Follow this link to initiate the deployment. SSOSync is a project designed to be hosted on your own AWS account.
To deploy it, you need to provide the following values in the Application settings section:
- Keep CrossStackConfig empty, as this tutorial uses a single AWS account setup
- Keep DeployPattern as default (App + secrets) to keep it simple
- Under GoogleAdminEmail, add the email of a Google Workspace administrator that will be used for the delegation with the service account
- Add the content of the JSON file you downloaded earlier when creating the service account to GoogleCredentials
- The value for IdentityStoreID can be found in the IAM Identity Center portal under Settings > Identity source
- Set Region to the region where IAM Identity Center is deployed
- Provide the token from the previous step in SCIMEndpointAccessToken
- Provide the endpoint from the previous step in SCIMEndpointUrl
Your screen should look something like this:
Click the box to acknowledge that some IAM resources will be created, and then click Deploy.
This is the minimal configuration, but more settings are available if you ever want to fine-tune the sync. By default, the sync will occur every fifteen minutes via a Lambda function. To follow the first sync, you can check the CloudWatch log group. On the current page, click SSOSyncFunction in the list to go to the Lambda function definition. Then, under Monitor, click View CloudWatch logs. Finally, click the latest log stream, and you’ll get some insights into what is happening every fifteen minutes:
On the log, you can see that the manually created user was deleted by the SSOSync process.
Test the Sync
To test the sync, let’s create a few groups on Google Workspace:
In this example, “AWS Developers” is the parent group, and there is one group per project (“Alpha” and “Omega”). Alice is a member of Alpha, and Brandon is a member of Omega. Because of the group hierarchy in Google Workspace, both users are indirect members of AWS Developers, which is useful when you need to apply a specific right to all AWS developers.
Here’s how this example would show on the Groups screen in IAM Identity Center:
You can see all three groups, but group heritage is not supported by SSOSync (the AWS Developers group has zero users).
On the Users screen, you can see your Google Workspace users and provide AWS access to them by assigning permission sets. Don’t forget about the principle of least privilege!
Limitations of the Solution
SSOSync is a nice companion if you want to interconnect Google Workspace to AWS, but there are some drawbacks:
- No support for advanced Google group capabilities: As you saw in the previous section, nested groups are not supported in SSOSync. This can be very limiting because it will require you to rethink your group organization to fit this model, and sometimes it will generate much more work if you need to individually manage hundreds of groups or modify the group membership on the Google side. A more complex organization is prone to errors in the implementation of the group organization. There is also no support for group membership mapping in the SAML configuration.
- Scalability concerns: SSOSync is an open source contribution that relies on the Google Admin API. It may be subject to API rate limitations if you have a large number of users and groups to sync.
- Maintainability concerns: The solution is deployed directly in your own AWS account, where you have full responsibility for the application, including monitoring, security upgrades, and the use of some advanced services like Lambda and CloudWatch that require extensive expertise in AWS Cloud.
- Security concerns: The deployment of a GCP project with domain-wide delegation and an account service with credentials is not a trivial task, and generating long-term credentials is generally not recommended (see here) for an explanation in AWS IAM security best practices).
Conclusion
This article described the steps required to sync a Google Workspace domain on AWS IAM Identity Center and allow your Google users to seamlessly access the AWS Console and API. If you want to explore alternative options, ConductorOne can help you improve and automate access management on the main cloud providers, like AWS and GCP.
