Organizations who wish to federate their external identity provider (IdP) to AWS will typically take action through AWS Single Sign-On (AWS SSO) , AWS Identity and Access Management (IAM) , or use both. With AWS SSO, you configure federation and manage usage of all your AWS accounts centrally once. With AWS IAM, you configure federation to each AWS account, and manage access for every account individually. AWS SSO supports identity synchronization through the System for Cross-domain Identity Management (SCIM) v2.0 for several identity providers . For IdPs not supported currently, it is possible to provision users manually . Otherwise, it is possible to elect to federate to AWS from Google Workspace through IAM federation , which this post will below cover.

Google Workspace supplies a single sign-on service based from the Security Assertion Markup Language (SAML) 2.0. Users may use this ongoing service to gain access to to your AWS resources through the use of their existing Google credentials. For users to whom you grant access, they shall see yet another SAML app within their Google Workspace console. Whenever your users choose this SAML app, they will be redirected to www.google.com the AWS Management Console.

Solution Overview

In this solution, you shall create a SAML identity provider in IAM to determine a reliable communication channel across which user authentication information could be securely passed together with your Google IdP to be able to permit your Google Workspace users to gain access to the AWS Management Console. You, because the AWS administrator, delegate responsibility for user authentication to a reliable IdP, in this full case Google Workspace. Google Workspace leverages SAML 2.0 messages to communicate user authentication information between Google as well as your AWS account. The given information contained within the SAML 2.0 messages allows an IAM role to grant the federated user permissions to register to the AWS Management access and Console your AWS resources. The IAM policy mounted on the role they select determines which permissions the federated user has in the console.

Figure 1 illustrates the login process for IAM federation. From the federated user’s perspective, this technique happens transparently: an individual starts at the Google Workspace portal and eventually ends up at the AWS Management Console, and never have to supply another user name and password yet.

1. The portal verifies the user’s identity in your company. An individual begins by browsing to your organization’s portal and selects the choice to visit the AWS Management Console. In your company, the portal is normally a function of one’s IdP that handles the exchange of trust between your organization and AWS. In Google Workspace, you navigate to https://myaccount.google.com/ and choose the nine dots at the top right corner icon. This will demonstrate a summary of apps, one of that will log you directly into AWS. This website post shall demonstrate how exactly to configure this custom app.

   

   Figure 2: Google Account page

2. The portal verifies the user’s identity in your company.
3. The portal generates a SAML authentication response which includes assertions that identify an individual and include attributes concerning the user. The portal sends this reaction to the client browser. But not discussed here, you can even configure your IdP to add a SAML assertion attribute called SessionDuration that specifies the way the console session is valid long. It is possible to configure the IdP to pass attributes as &lt also;a href=”https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html” target=”_blank” rel=”noopener noreferrer”>session tags.
4. Your client browser is redirected to the AWS single sign-on posts and endpoint the SAML assertion.
5. The endpoint requests temporary security credentials with respect to an individual, and creates a console sign-in URL that uses those credentials.
6. AWS sends the sign-in URL to your client as a redirect back.
7. Your client browser is redirected to the AWS Management Console. If the SAML authentication response includes attributes that map to multiple IAM roles, an individual is prompted to choose the role for accessing the console first.

The list below is really a high-level view of the precise step-by-step procedures had a need to setup federated single sign-on access via Google Workspace.

The setup

Follow these top-level steps to create federated single sign-on to your AWS resources through the use of Google Apps:

1. Download the Google identity provider (IdP) information.
2. Create the IAM SAML identity provider in your AWS account.
3. Create roles for the third-party identity provider.
4. Assign the user’s role in Google Workspace.
5. Create Google Workspace as a SAML identity provider (IdP) for AWS.
6. Test the integration between Google AWS and Workspace IAM.
7. Roll out to a wider user base.

Detailed procedures for every of the steps compose the rest of this post.

Step one 1. Download the Google identity provider (IdP) information

First, let’s obtain the SAML metadata which has essential information make it possible for your AWS account to authenticate the IdP and locate the required communication endpoint locations:

1. Get on the Google Workspace Admin console
2. From the Admin console Website, select Security > Settings > Setup single sign-on (SSO) with Google as SAML Identity Provider (IdP).

   

   Figure 3: Accessing the “single sign-on for SAML applications” setting

3. Choose Download Metadata under IdP metadata.

   

   Figure 4: The “SSO with Google as SAML IdP” page

Step two 2. Create the IAM SAML identity provider in your account

Now, create an IAM IdP for Google Workspace to be able to establish the trust relationship between Google Workspace as well as your AWS account. The IAM IdP you create can be an entity inside your AWS account that describes the external IdP service whose users you’ll configure to assume IAM roles.

1. Register to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
2. In the navigation pane, choose Identity providers and choose &lt then;strong>Add provider.
3. For Configure provider, choose SAML.
4. Type a name for the identity provider (such as for example GoogleWorkspace).
5. For Metadata document, select Choose file specify the SAML metadata document that you downloaded in &lt then;a href=”https://aws.amazon.com/blogs/security/how-to-set-up-federated-single-sign-on-to-aws-using-google-workspace/#step-1c”>Step 1-c.
6. Verify the given information that you have provided. If you are done, choose Add provider.

   

   Figure 5: Adding an Identity provider

7. Document the Amazon Resource Name (ARN) by viewing the identity provider you created in step f. The ARN should looks such as this:arn:aws:iam::123456789012:saml-provider/GoogleWorkspace

Step three 3. Create roles for the third-party Identity Provider

For users accessing the AWS Management Console, the IAM role that an individual assumes allows usage of resources inside your AWS account. The role is where you define everything you allow a federated user to accomplish after they register.

1. To generate an IAM role, go directly to the AWS IAM console. Select Roles > Create role.
2. Pick the SAML 2.0 federation role type.
3. For SAML Provider, choose the provider that you created in Step 2.
4. Choose Allow programmatic and AWS Management Console access to make a role that may be assumed and from the AWS Management Console programmatically.
5. Review your SAML 2.0 trust information and choose Next: Permissions.

   

   Figure 6: Reviewing your SAML 2.0 trust information

GoogleSAMLPowerUserRole:

6. Because of this walkthrough, you are likely to create two roles that may be assumed by SAML 2.0 federation. For GoogleSAMLPowerUserRole, you shall attach the PowerUserAccess AWS managed policy. This policy provides full usage of AWS resources and services, but will not allow management of groups and users. Choose Filter policies, select &lt then;strong>AWS managed – job function from the dropdown. This can show a summary of AWS managed policies designed around specific job functions.

   

   Figure 7: Selecting the AWS managed job function

7. To add the policy, select PowerUserAccess. Choose &lt then;strong>Next: Tags, &lt then;strong>Next: Review.

   

   Figure 8: Attaching the PowerUserAccess policy to your role

8. Finally, choose Create role to finalize creation of one’s role.

   

   Figure 9: Creating your role

GoogleSAMLViewOnlyRole

Repeat steps a to g for the GoogleSAMLViewOnlyRole, attaching the ViewOnlyAccess AWS managed policy.

9. Document the ARN of both roles. The ARN ought to be much likearn:aws:iam::123456789012:role/GoogleSAMLPowerUserRole andarn:aws:iam::123456789012:role/GoogleSAMLViewOnlyAccessRole.

Step 4. Assign the user’s role in Google Workspace

Here you’ll specify the roles or role that user can assume in AWS.

1. Get on the Google Admin console.
2. From the Admin console Home page, head to Directory > Users and choose Manage custom attributes from the More dropdown, and choose Add Custom Attribute.
3. Configure the custom attribute the following:
   

   Category:	AWS
   Description:	Amazon Web Services Role Mapping

   For Custom fields, enter the next values:

   Name:	AssumeRoleWithSaml
   Info type:	Text
   Visibility:	Noticeable to admin&lt and user;/td>
   InNo. of values:	Multi-value

4. Choose Add. The brand new category should come in the Manage user attributes page.

   

   Figure12: Adding the custom attribute

5. Navigate to Users, and discover the user you intend to allow to federate into AWS. Choose the user’s name to open their account page, choose &lt then;strong>User Information.
6. Select on the custom attribute you created, named AWS. Add two rows, all of which will are the values you recorded earlier, utilizing the format below for every AssumeRoleWithSaml row.Row 1:
   arn:aws:iam::123456789012:role/GoogleSAMLPowerUserRole,arn:aws:iam:: 123456789012:saml-provider/GoogleWorkspaceRow 2:
   arn:aws:iam::123456789012:role/GoogleSAMLViewOnlyAccessRole,arn:aws:iam:: 123456789012:saml-provider/GoogleWorkspace

   The format of the AssumeRoleWithSaml is constructed utilizing the RoleARN(from Step 3-h) + “,”+ Identity provider ARN (from Step 2-g), this value will be passed as SAML attribute value for attribute with name https://aws.amazon.com/SAML/Attributes/Role. The ultimate result will look much like below:

   

   Figure 13: Adding the roles that an individual can assume

Step 5. Create Google Workspace as a SAML identity provider (IdP) for AWS

Now you’ll create the SAML app in your Google Workspace account. This consists of adding the SAML attributes that the AWS Management Console expects to be able to allow a SAML-based authentication to occur.

Log into the Google Admin console.

1. From the Admin console Website, head to Apps > Web and mobile apps.
2. Choose Add custom SAML app from the Add App dropdown.
3. Enter AWS Single-Account Access for App name and upload an optional App icon to recognize your SAML application, and choose Continue.

   

   Figure 14: Naming the custom SAML app and setting the icon

4. Complete the next values:
   

   ACS URL:	https://signin.aws.amazon.com/saml
   Entity ID:	urn:amazon:webservices
   Name ID format:	EMAIL
   Name ID:	Basic Information > Primary email

   Note: Most of your email shall become your role’s AWS session name

5. Choose CONTINUE.

   

   Figure 15: Adding the custom SAML app

6. AWS requires the IdP to issue a SAML assertion with some mandatory attributes (known as claims). The AWS documentation explains how exactly to configure the SAML assertion. In a nutshell, you need to generate an assertion with the next:
   • An attribute of name https://aws.amazon.com/SAML/Attributes/Role. This element contains one or more AttributeValue elements that list the IAM identity role and provider to that your user is mapped by your IdP. The IAM role and IAM identity provider are specified as a comma-delimited couple of ARNs in exactly the same format as the RoleArn and PrincipalArn parameters which are passed to AssumeRoleWithSAML.
   • An attribute of name https://aws.amazon.com/SAML/Attributes/RoleSessionName (again, this can be a definition of type just, no actual URL) with a string value. This is actually the federated user’s role session name in AWS.
   • A name identifier (NameId) that’s used to identify the main topic of a SAML assertion.
     

     Google Directory attributes	App attributes
     AWS > AssumeRoleWithSaml	https://aws.amazon.com/SAML/Attributes/Role
     Basic Information > Primary email	https://aws.amazon.com/SAML/Attributes/RoleSessionName

     

     Figure 16: Mapping between Google Directory attributes and SAML attributes

7. Choose FINISH and save the mapping.

Step 6. Test the integration between Google AWS and Workspace IAM

1. Log into the Google Admin portal.
2. From the Admin console Home page, go to Apps > Web and mobile apps.
3. Select the application form you created in Step 5-i.
4. At the very top left, select TEST SAML LOGIN, then choose ALLOW ACCESS within the popup box.

   

   Figure 18: Testing the SAML login

5. Select ON for everyone in the ongoing service status section, and choose SAVE. This can allow every user in Google Workspace to start to see the new SAML custom app.

   

   Figure 19: Saving the custom app settings

6. Navigate to &lt now;strong>Web and mobile apps and choose TEST SAML LOGIN again. Amazon Web Services should open in another tab and display two roles for users to select from:

   

   FIgure 20: Testing SAML login again

   

   Figure 21: Selecting the IAM role you intend to assume for console access

7. Choose the desired role and choose Sign in.
8. You ought to be redirected to &lt now;strong>AWS Management Console website.
9. Google workspace users should now have the ability to access the AWS application from their workspace:

   

   Figure 22: Viewing the AWS custom app

Conclusion

By following steps in this website post, you’ve configured your Google Workspace directory and AWS accounts to permit SAML-based federated sign-on for selected Google Workspace users. By using this over IAM users helps centralize identity management, rendering it simpler to adopt a multi-account strategy.

When you have feedback concerning this post, submit comments in the Comments section below. When you have questions concerning this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.