Setup AWS Organizations With Google Suite SAML SSO

A simplified AWS account management, with centralized billing and resource share, authenticated with G Suite identity provider

As a tech lead for Theodo, an international software development agency, I rely heavily on AWS for web project hosting. Most of my colleagues do as well, especially as more and more projects go down a serverless architecture trend. Initially, Theodo was built around Google as it’s main identity provider. All our digital tools use Google authentication (Trello, Workplace and so on). On the technical tools side, we mostly rely on our Github accounts. As far as AWS is concerned, Theodo was providing for all its developers IAM user credentials for web console access and programmatic access to a single AWS master account. This account centralized experiments, developer environments for a few applications and some production environments of our internal tools.

However, such setup has a few drawbacks :

• Password management nightmare: when dealing with multiple credentials manually
• Security flaws: IAM users created for former employees have a high chance of remaining active, because no-one thinks of cleaning those up
• Lack of resource isolation: Resources created by one developer are accessible — and possibly editable/deletable by mistake — to other developers
• Complex billing debugging: No tags are used on the created resources, our billing pages show tons of resources, without clear markers on whether or not these resources are still actively used, or if they were part of some experimentation and left active by mistake

In order to tackle those issues, I moved our teams from manual organisation setup remembering account IDs, managing many different passwords to a single page authenticated with Google, listing all the accounts they have access to. The following AWS services came in handy to operate such transition:

• AWS Organizations to provide resource isolation by project/developer and to ease up billing understanding
• AWS SSO with Google Suite (all accounts of Theodo are G Suite accounts) to ensure only active Theodo users can access their AWS resources

This setup will provide all your employees with a unique user portal listing all AWS accounts they have access to, authenticating with their already existing Google credentials.

AWS SSO and Organization with G Suite SAML Provider

The following instructions aim to describe the required steps to setup an AWS SSO on AWS Organization accounts. It differs from a lot of available tutorials on the web when searching for aws sso google which focus on setting up SSO for a single AWS Account using AWS IAM roles with trusted SAML provider.

The main advantage of setting up SSO for an organization is to ensure resources segregation and therefore avoid contamination of a service by a developer doing some experimentation of their own. It also removes the need for company developers to create their own account on the side with their own personal billing information, or company billing information, that your financial team needs later on to consolidate.

Implementation

AWS Organizations

AWS Organizations requires one account to be used as the master account of your company. This account billing information will be use to charge all other accounts expenses within the organization.

In order to setup AWS Organizations, you need the following accesses:

• Root access of your company’s master AWS account.

Check : When I go to https://console.aws.amazon.com/console/home, I can authenticate to my company’s master account with the Root user option.

Instructions to setup AWS Organizations

• Go to AWS Organizations console
• On the introduction page, choose Create organization.
• Make sure all features are enabled, and not just consolidated billing features, as this is required for AWS SSO setup, before confirming organization creation.

AWS SSO

AWS SSO setup requires AWS Organizations to be active on your AWS master account. Make sure to follow the steps above first before continuing.

In order to setup AWS SSO, you need the following accesses :

• Root access of your company’s master AWS account (like for AWS Organizations setup)
• Super Admin privileges access to your company’s G Suite account.

Check : When I go to https://admin.google.com, I can see an Apps section

I. AWS SSO endpoint configuration

• Go to AWS SSO console and enable AWS SSO
• Once AWS SSO is enabled, go to AWS SSO Settings page, under User portal, and choose Change. You can then provide your company’s name in order to get an easy portal URL: https://{company}.awsapps.com/start. You can only setup this subdomain once, no further changes are allowed, choose wisely.

By default, AWS SSO uses an internal store for quick and easy user management. The following steps II to V will focus on implementing a SAML SSO authentication flow for your AWS Organizations.

II. G Suite SAML App initialization and metadata recovery

• For this step, head over to https://admin.google.com, select Apps and choose SAML apps
• Add a new app by clicking the + button on the bottom right corner
• Select Set up my own custom app from the list. Do not select Amazon Web Services from the list. This SAML app pre-configuration is make for AWS single account SSO via IAM federated roles. This is not what we are setting up here.
• Download the IDP metadata to your computer as metadata.xml by clicking the DOWNLOAD link from the option 2 part of the popup.

• Click next button.

Keep this browser tab open, we will need to complete the application setup process in step IV.

III. AWS SSO external IdP configuration with G Suite metadata and AWS metadata recovery

• Open a new browser tab on AWS SSO console.
• Go to the Settings page, under Identity source, and click Change on the Identity source line.
• Choose External identity provider within the list of available identity providers.
• Under Service provider metadata, click the Show individual metadata values button. Take a note of AWS SSO Sing-in URL, ACS URL and issuer URL. There are unfortunately no metadata upload feature available in Google admin for SAML application setup.

• Upload the metadata.xml file you downloaded earlier from Google admin page in the IdP SAML metadata field.
• Choose Next: Review.
• Once you have read the disclaimer and are ready to proceed, type CONFIRM.
• Choose Finish.

IV. G Suite SAML App configuration with AWS metadata

• Return to Google Admin tab of your browser
• In the Service Provider details window, add Amazon Web Services as an application name and description.
• Fill in AWS SSO ACS URL value from AWS in the ACS URL field.
• Fill in AWS SSO issuer URL value from AWS in the Entity ID field.
• Fill in AWS SSO Sing-in URL in the Start URL field.
• Leave the Signed Response unchecked.
• Leave the default Name ID as the primary email. This will be our unique identifier on AWS side.
• Click Next.
• Do not modify any Mapping in the Attribute Mapping section.
• Click Finish.

V. AWS SSO users provisioning

AWS SSO uses SCIM (System for Cross-domain Identity Management) to do automatic provisioning of users based on IdP information. Unfortunately, no SCIM option is exposed for G Suite IdP. This automatic provisioning method is mainly used for Azure Active Directory federated AWS SSO configuration.

Therefore, when setting up AWS SSO with G Suite accounts, you need to manually add user in AWS SSO interface. The management of user permission is also made from AWS SSO interface.

• On your existing AWS SSO console browser tab, go to the Settings page, under Identity source, and check that Provisioning line shows Manual.

• Go to the Users page, and click Add user
• Fill in user G Suite email address in both Username and Email address fields. Username field must contain the user email address as we provisioned the G Suite SAML App to use the email as Name ID SAML field. In order to test this AWS SSO setup, I suggest your start by creating your own user.

• You can fill in remaining required field as per your likings.
• Click Next: Groups.
• Click Finish.

VI. AWS SSO accounts and users management

• Go to AWS accounts page, on Permission sets tab, click Create permission set

• For the purpose of this setup, we will create a predefined Permission set with Administrator privileges. Choose Use an existing job function policy and select AdministratorAccess. The permission set system in place for AWS SSO is very similar to AWS IAM Policy management. The permission set created in AWS SSO are not available as IAM policies and vice-versa.

• Click Create.
• Go to AWS accounts page, on AWS organization tab
• Select one or more accounts within the list of AWS accounts within you organization that you would like the newly created user to have AdministratorAccess to.
• Click Assign user.
• Select your newly created user in the user list and click Next: Permission sets.
• Select your newly created Administrator permission set in the list and click Finish.

You can now go to the URL you configured in the first step (https://{company}.awsapps.com/start) , authenticate via google with G Suite account and be redirected to AWS SSO user portal. In this portal, listed under AWS Account, you can see each AWS Account of your AWS Organization for which your user has at least one permission set. And for each AWS Account listed, you can see a list of available permission set you can use both within the web management console and the command line.

I recommend using groups rather than individual users for AWS account used for various project. Individual user permission set attribution to AWS account shall only be used for AWS personal account with the organization (we use such account in Theodo for experimentation and training purposes).

Adding an account and user from start to finish

• Go to AWS Organizations console, select Add account and click Create account
• Fill in AWS account name and email fields. Those are not related to AWS SSO, so feel free to fill in whatever value describing better this specific account usage. No one should ever need to use the root user to connect to this account. Click Create.
• Go to AWS SSO console, select AWS Accounts, find and select your newly created account and click Assign user.
• Select the user this account was created for and use the Administrator permission set, select Finish.

And just like that, you have a new fully functional AWS Account just for your employee in less than a minute, without credentials exchange. They simply needs to go to your previously setup user portal URL and see their newly created accounts.

Going further

• Using AWS RAM to share resources from master AWS account to other accounts. You can for example share a Zone 53 hosted zone, in order to provide a domain name usable by every account of your AWS Organization: https://docs.aws.amazon.com/ram/latest/userguide/what-is.html
• Setting up the AWS CLI to use AWS SSO: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html

Resources used to compile this article

• AWS Organizations setup: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tutorials_basic.html
• G Suite SAML App setup: https://support.google.com/a/answer/6087519?hl=en
• AWS SSO external IdP setup: https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html