Signing into Entra External ID with Google Workspace

This post will walk through the steps needed to connect a Google Workspace account with a Microsoft Entra External ID tenant. The phrasing and direction can be confusing from tutorial-to-tutorial, so to put it plainly, this post is for you if:

1. You have an application that your users log into with Entra (maybe with Entra accounts or other social logins).
2. You want to invite users from a specific Google Workspace to log into your application using their Google credentials.

This post assumes you have an Entra tenant, a Google Workspace account, access to DNS configuration, admin privileges elevated enough to perform these actions, and a web application configured to sign in with Entra. My application uses MVC and .NET Core 8, so I’ll briefly mention the configuration used to get that working.

It can be frustrating to get this set up correctly and to parse documentation for the relevant bits, I know, so this post aims to be all killer, no filler. There is little room for error with most of these configuration settings. Let’s go.

Entra (Part 1)

Load up the Entra admin center at https://entra.microsoft.com and make sure you’ve selected the right tenant. Go to “Identity” and then “Overview” from the left sidebar. You’ll need to capture two pieces of data:

• Your Tenant ID, which is displayed in the top-left of the home page.
• The first bit of your Primary domain. For example, if you have “contoso.onmicrosoft.com”, you’ll want to grab “contoso”.

Google Workspace

Now head over to your admin console: https://admin.google.com/.

1. Open “Apps” on your sidebar, then “Web and mobile apps”.
2. Click “Add app” and select “Add custom SAML app”.

3. Give the app a name and description.

4. Once you’re here, download the Idp metadata and hit “continue”. We’ll need this in a moment.

5. Add in your service provider details:
   1. ACS URL: Construct this URL using the first bit of your Entra primary domain from the section above: https://(primary-domain).ciamlogin.com/login.srf. For example, https://contoso.ciamlogin.com/login.srf.
   2. Entity ID: Construct this using the tenant ID of your Entra tenant from the section above: https://login.microsoftonline.com/(tenant-ID). For example, https://login.microsoftonline.com/ 710ad28b-3829-4a85-b76c-5ba71a1a4ca0/.
   3. Start URL: you can ignore this.
   4. Name ID: Select “PERSISTENT” for format and “Basic Information > Primary Email”.
   5. Continue to the next page.

6. Once on the “Attributes” page, click to add a mapping:
   1. Select the “Basic Information > Primary email” field.
   2. Add the following as the “app attribute”: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.
   3. Click “finish”.

Your application will be created with user access turned “OFF” for everyone. The easiest thing you can do is go into the details of user access and flip the switch to be “ON for everyone”, however, you can manage access through groups and organizational units within Google Workspace as well. Now let’s return to Entra to finish this thing.

Entra (Part 2)

Back in the Entra admin center, make your way over to “External Identities” and then “All identity providers on the left sidebar. Then toggle to “Custom”:

Hit “Add new” and select “SAML/WS-Fed”. You should see something like the following:

Now:

1. Give this guy a display name.

2. Select “SAML” for your provider protocol.

3. Type in the domain name associated with your Google Workspace. This should be the same domain as your Google emails (example, not-my-email@dontpaniclabs.com).

4. Upload the metadata file that you downloaded out of Google when you created the app above. You can go back and get another one if you need to.

5. Capture the Passive authentication endpoint that was parsed out of the metadata file. You will need this for your DNS configuration. Speaking of DNS, let’s sort that out.

Your DNS Provider

The final piece of the puzzle is to add a TXT record to your DNS settings for the domain name of your federating IdP (i.e., your Google domain). In my example, I used Squarespace.

This is relatively straightforward. Find a spot for custom records in your DNS settings and add a TXT record using the following “DirectFedAuthUrl=” key and the passive authentication endpoint from the metadata file you used above. For example:

DNS being DNS, this can take time to propagate. For me, this took about 30 minutes. You can check from a terminal (macOS) with “nslookup -type=TXT yourdomain.com” to see if the new text record shows up, or you can open http://dnschecker.org/#TXT/yourdomain.com in a browser to watch the record propagate around.

Entra (Finale!)

Return to Entra for the final time and begin inviting your Google users. Click “Identity” and “All users” on the left sidebar, then “New user” and “Invite external user”:

Send an invite to a user with the email of your Google domain and they should receive an email which they can accept and proceed to signing into your application. They’ll need to consent to share information with Entra and may need to go through the MFA setup, depending on your settings, but they should be good to go afterward. If you’re doing this before the DNS settings have had enough time to propagate, you may get through the whole sign-in only to have it fail when you redirect back to your application. If this happens, you might try waiting a bit longer before you get too far into debugging.

Bonus (.NET MVC configuration)

In my solution, I’m using MVC and Azure/Microsoft Identity packages, which means the OAuth redirects are handled for me if I have the right settings in the right places. You should, for example, have Microsoft Identity values in your appsettings.json, similar to:

The only thing I needed to add to get the Google sign-on to work is the highlighted section below in Program.cs (the unhighlighted lines are included for context):

Note that the config keys (e.g., “ifx:entra:app”) are simply my naming convention and configuration structure.

Did it Work?

Gosh, I hope so. I pieced this together over an unpleasant couple of days and I sure am glad to see it working. If you’re struggling and wondering “is this even possible?” or “does this feature even work?”, or “has anybody on Earth got this to work before?”, the answer is yes. Keep at it. Let me know if this helps you so I can tell myself it was all worth it.

Tips

• If you’re struggling, it may help to download the SAML Chrome Panel extension (Chrome) and run through the login with developer tools open on the SAML panel. This will enable you to see what Entra is asking for and what Google is sending back.
• It may go without saying but don’t try to debug through this in a deployed environment. Set yourself up for local development for a faster turnaround time.
• Check out the resources below, and don’t skim. Go through them slowly, check every detail. To get my setup working, I may have strayed in a detail or two from those resources, so if my setup doesn’t work for you, you still have a couple of options to try.
• If the owner of your Azure subscription has the same domain as the Google Workspace (in other words, you used your Google account to create the Azure account), then this probably will not work due to Azure matching on your user instead of your domain.

Resources

• Add federation with SAML/WS-Fed identity providers: https://learn.microsoft.com/en-us/entra/external-id/direct-federation
• Microsoft Entra ID External IdP federation with Google Workspace: https://www.youtube.com/watch?v=-EysNjJcMno

Andrew Tarr Sr. Software Engineer

Andrew is constantly challenging himself to try new things, both professionally and personally. This attitude has served him well in his ten years of service in the Nebraska Army National Guard and at Don’t Panic Labs, where he has worked on mobile and web application development since 2014.

See Full Bio