Google + Auth0 as External Identity Provider for AWS SSO
I was working under a very unique scenario to come up with this solution and hopefully someone, with a similar situation, can benefit from this guide.
I have to do a proof of concept to manage the developer’s access to our AWS accounts. In this scenario, there is already a working Single Sign-On (SSO) system with Multi-Factor-Authentication (MFA) against a user directory such as Active Directory. However, my team has no administrative access to manage the existing Active Directory. The business emails that are controlled through the user directory can be used with Google products (such as Google Drive).
So here is the question:
How to manage user access to the AWS accounts using a centralised authentication system without administrative privilege to the user directory?
The answer is simple: leverage social media login. Since the business email can be used to authenticate using Google, we can use Google OAuth to grant access to AWS SSO.
Before we continue, some of you may think: letting social media access to the AWS accounts is a very bad idea.
I completely agree if we do not build any security around it. Social media access provides great flexibility for authentication; this is the one feature that we want to take advantage from. I will show you ways to vet social media users so that only trusted users can access your AWS accounts.
This solution does not come without its drawback. I will explain later for you to judge if this whole thing worths the effort.
Architecture
Because the AWS accounts are managed in a hierarchal fashion, we can use AWS SSO product to centrally manage access to the other linked AWS accounts. Let’s go through the architectural diagram:
- Users go to User Portal URL provided by AWS SSO.
- AWS redirects users to an Auth0 login form (this is essentially an Auth0 application).
- The users validate their credentials using Google.
- Google verifies the access and create the user record in Auth0 Database.
- Auth0 redirects to an AWS SSO portal where the users can see the available accounts permitted to them.
- When the users choose an account to log into, AWS SSO checks the mapping between users, accounts, and permission sets in AWS SSO.
- The mapping between users, accounts, and permission sets must be created manually. This is our main security layer. If the users have no mapping, then the redirection will fail in step 5.
- When the mapping between users and accounts is created, AWS SSO creates an IAM Identity Provider in the target linked AWS account. This lets AWS SSO to log into the target account using SAML.
- When the mapping between users and permission sets is created, AWS SSO creates an IAM Role in the target linked AWS account. This is the role that a user will assume when logging into the linked AWS account.
To improve the security, we can use Auth0 Rule to whitelist email domain. Any random email authenticated through social media will be blocked at Auth0.
Remember the drawback I mentioned earlier? Here it is: in step 4 above, Auth0 creates a user record in Auth0 Database when the user is validated via social media, even if there’s a whitelist rule. So your Auth0 Database can potentially be littered with spammer emails. The solution: use AWS Lambda to clean up the Auth0 Database on a daily basis via Auth0 API. The AWS Lambda clean up part is not covered in this guide.
Now, let’s do the fun bit. How can you configure this contraption?
Be aware that you will be jumping back and forth between AWS, GCP, and Auth0 during configuration. So strap yourself!
AWS SSO Configuration
Go to the main (paying) account in AWS and enable the AWS SSO (if this is a production account, I would suggest you to understand what AWS SSO will do to your account).
Go to AWS SSO > Settings and change the Identity Source to External Identity Provider.
Show the Individual Metadata Values and note down the Sign-in URL, ACS URL, and Issuer URL; these will be required in Auth0.
Keep this section open and let’s jump to Auth0.
Auth0 New Application
Choose an Auth0 tenancy or create a new tenancy. Personally I would prefer using a new tenancy.
Create a new application with Regular Web Application as its type; you can name it anything you want.
Put the ACS URL from AWS SSO as Auth0’s Allowed Callback URLs.
Click Save.
Go to Add-on tab and enable SAML2 Web App.
Use the following JSON in the setting of SAML2 web app (don’t forget to replace the ACS URL and Issuer URL):
{
"audience": "AWS_SSO_ISSUER_URL",
"destination": "AWS_SSO_ACS_URL",
"mappings": {
"email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
"name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
},
"createUpnClaim": false,
"passthroughClaimsWithNoMapping": false,
"mapUnknownClaimsAsIs": false,
"mapIdentities": false,
"nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
"nameIdentifierProbes": [
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
]
}This above JSON can be found here.
Scroll down and click Enable.
Go to the Usage tab and download the Identity Provider Metadata XML. This file will be used by AWS SSO.
Close the Add-on page.
Back to AWS SSO.
AWS SSO Configuration (continue…)
Click Browse for Identity Provider Metadata and upload the XML file from Auth0.
Click Next: Review and type ACCEPT to confirm the change of identity source.
After returning to the AWS SSO setting page, click Cancel to get out of the SSO identity source page (there’s room for improvement here, AWS).
Google Cloud Platform OAuth Credential
Auth0 uses its own dev OAuth key to authenticate with Google. You need to use your own OAuth key to make this configuration works. Let’s create an OAuth credential key.
Create a new project in GCP. A project can only have one OAuth consent screen. This must be set to Auth0 domain.
Go to API and Services > Credentials in GCP.
Click Create Credential and select OAuth Client ID.
Click Configure Consent Screen and provide the following values:
- Application Type : Public
- Application Name : auth0_aws_sso (anything unique)
- Authorized Domains : auth0.com
Click Save.
Continue with OAuth Client ID creation and set the following values:
- Name : auth0 aws sso (anything unique)
- URIs : https://YOUR_DOMAIN (this is from Auth0 Application)
- Authorized Redirect URIs : https://YOUR_DOMAIN/login/callback
Note down the Client ID and Client Secret of the new key.
These steps can be found here.
Back to Auth0.
Completing Auth0 Settings
In Auth0, go to Connection > Social and select google-oauth2.
Provide the Client ID and Client Secret of the OAuth Client ID from GCP.
Click Save.
Go to Rules and create a new rule (there’s a template for email domain whitelist).
You can use this code as an example.
Congratulation! Auth0 setting is complete.
Now, we need to create the users and permission sets in AWS SSO. This is a manual process to provision trusted users to your AWS accounts.
AWS SSO User and Permission Set
Go back to AWS SSO.
Go to AWS SSO > AWS Accounts > Permission Sets.
Follow the instruction on the screen to create the permission set.
Go to AWS SSO > Users and click Add User.
Use the email address in the following fields:
- Username
- Email Address
Skip group assignment and add the user.
Go to AWS SSO > AWS Accounts and choose the AWS Organization tab.
Select an account and assign the user with a permission set.
Test User Login
Use the User Portal URL to get a login screen.
An Auth0 application login is shown and click Sign in with Google.
If the existing authentication already supports MFA, it will ask for MFA verification.
Users will see a portal where they can choose the account to log into, along with the allocated permission set.
Note that there is the command line or programmatic access option. This means you can use this for AWS CLI as well using the AWS STS token given to the existing session.
You can either get the token from the portal and edit the ~/.aws/credentials manually or you simply use the following command:
aws configure sso
SSO start URL [None]: **provide user portal URL**How to Troubleshoot
You can look at the logs in Auth0 web console to understand what is going on.
There are two common errors that I have seen so far:
- MFA is invalid : This is because the user has been verified by social media but no matching user can be found in AWS SSO. This is a good thing from security point of view.
- Invalid input : Auth0 Google connector is using Auth0 OAuth dev key; change the key to your own OAuth key.
Hope this guide can give more ideas on how to authenticate users to AWS accounts.
Have fun and be safe.
