AWS SSO inbound SAML with Google’s G Suite
Update 07/07/2020: AWS have since written a step-by-step blog post about this process here: https://aws.amazon.com/blogs/security/how-to-use-g-suite-as-external-identity-provider-aws-sso/
Introduction
At Re:Invent 2019, Amazon Web Services (AWS) released a long-awaited feature for their Single Sign-On (SSO) service.
Since it’s launch, you could use AWS SSO to centrally manage access to AWS via a built-in directory of users, or via Microsoft Active Directory (AD) either running within AWS or in your own environment outside of AWS.
Now, AWS SSO supports what’s referred to as inbound Single Sign-On. This allows AWS SSO to depend on an Identity Provider (IdP) via SAML or OAuth 2.0 integration. The first integration AWS demonstrated using this method was with Microsoft’s Azure Active Directory (AAD), a kind-of AD-as-a-Service.
In this article I’m going to demonstrate how you can integrate AWS SSO with your G Suite account, so you simplify access management when your users are mastered in Google.
Google as an Identity Provider
G Suite has a somewhat minimalist approach to Identity Management. It is quite basic when compared to other products designed primarily for Identity Management like Okta or OneLogin.
However, G Suite generally has enough functionality for small businesses, as it has had for mine. G Suite is also very commonly used as an IdP for SaaS products (e.g. Trello, Medium..), since Google login is relatively easy for developers to implement, and users to login with.
G Suite Setup
To configure your G Suite instance as the IdP for a SAML integration, most of the information you need can be found here: https://support.google.com/a/answer/6087519
I will detail the AWS SSO-specific parts. On the G Suite side the setup is relatively simple.
First, go to Apps in the Admin Console (https://admin.google.com) and create a new SAML App. Select “Setup My Own Custom App” at the bottom of the “Enable SSO for SAML Application” dialog box.
Next manually copy the SSO URLs and download the certificate provided by Google. Option 2, the metadata file approach, is much simpler. However, during my testing, providing the file caused an “Internal Error” in the AWS SSO Console.
Next you will be asked to name the application and provide a picture. You can do what you like here :)
Finally, you will be asked to enter three URLs (Entity, ACS and start URLs) which you can get from the AWS SSO Console, detailed in the next section. You also need to map any attributes that are required by the Service Provider.
In the case of AWS SSO, all you need is the Name ID formatted as an email. The email provided by G Suite must then match the email of a User that has been created in AWS SSO. More on User Provisioning below.
AWS SSO Setup
In the AWS SSO Console, copy the URLs provided previously during the G Suite setup into the settings for “Configure external identity provider”. If you already have an instance of AWS SSO you can find this by clicking “Change” next to the Identity Source listed in the Settings page of the AWS SSO Console.
Select “External Identity Provider” and click both of the options for using URLs instead of files. Copy down the AWS URLs provided as you will need them in the G Suite Setup.
Copy the G Suite URLs you were provided into the ACS, Entity ID and Start URL fields in the AWS SSO Console.
Once you have entered the values into AWS, you can continue. The Console will ask you to confirm your settings and that’s it! The AWS side is configured.
Automated User Provisioning
One of the big draw-cards of the new external IdP feature was the addition of automated user provisioning via the Service for Cross-domain Identity Management (SCIM).
Currently, G Suite does not appear to provide SCIM support for custom applications. There is a catalog of pre-defined apps where Google supports SCIM, so hopefully it is added for custom applications in the future.
In the meantime, you will need to create the Users in AWS SSO with a matching email address and manage their access to AWS resources from there.
Conclusion
Whilst not a complete Identity and Access Management solution just yet, this demonstrates that AWS SSO can easily be integrated with G Suite for the purposes of authentication.
Support for both IdP-initiated and Service Provider-initiated sign-on appear to be available.
If you arent logged into G suite already, navigating to your AWS SSO start page will now redirect you to sign in with Google (SP-initiated).
Additionally, G Suite adds a tile in your apps launcher that will take you straight to the AWS SSO start page (IdP-initiated).
Previously, when using IAM Role-based federation, only the IdP-initiated flow was supported.
Have things changed since I wrote this? Have you found a way to do SCIM or has the metadata file started working? Let me know in the comments!
