After working through the Azure Active Directory (AD) and Amazon Web Services (AWS) integration I thought it’d be fun to do the same thing with Google Apps. Google provides a generic tutorial for single sign-on that is severely lacking in details. Microsoft again provides a reasonable tutorial for integrating Azure AD and Google Apps for single sign-on. Neither gives much detail about what goes on behind the scenes or provides the geeky details us technology folk love. Where there is a lack of detail there is a blogging opportunity for Journey Of The Geek.
In my previous post I covered the benefits of introducing Azure AD as an Identity-as-a-Service (IDaaS) component to Software-as-a-Service (SaaS) integrations. Read the post for full details but the short of it is the integration gives you value-added features such as multifactor authentication with Azure Multifactor Authentication (MFA), adaptive authentication with Azure AD Identity Protection, contextual authorization with Azure AD Conditional Access, and cloud access security broker (CASB) functionality through Cloud App Security. Supplementing Google Apps with these additional capabilities improves visibility, security, and user experience. Wins across the board, right?
I’m going to break the integration into a series of posts with the first focusing on single sign-on (SSO). I’ll follow up with a post exploring the provisioning capabilities Azure AD introduces as well as playing around with Google’s API. In a future post I’ll demonstrate what Cloud App Security can bring to the picture.
Let’s move ahead with the post, shall we?
The first thing I did was to add the Google Apps application to Azure AD through the Azure AD blade in the Azure Portal. Once the application was added successfully I navigated to the Single sign-on section of the configuration. Navigate to the SAML Signing Certification section and click the link to download the certificate. This is the certificate Azure AD will be using to sign the SAML assertions it generates for the SAML trust. Save this file because we’ll need it for the next step.
I next signed up for trial subscription of Google’s G Suite Business. This plan comes with a identity store, email, cloud storage, the Google productivity suite, and a variety of other tools and features. Sign up is straightforward so I won’t be covering it. After logging into the Google Admin Console as my newly minted administrator the main menu is displayed. From here I select the Security option.
Once the Security page loads, I select the Set up single sign-on (SSO) menu to expand the option. Google will be playing the role of the service provider, so I’ll be configuring the second section. Check the box to choose to Setup SSO with third party identity provider. Next up you’ll need to identify what your specific SAML2 endpoint is for your tenant. The Microsoft article still references the endpoint used with the old login experience that was recently replaced. You’ll instead want to use the endpoint https://login.microsoftonline.com/<tenantID>/saml2. You’ll populate that endpoint for both the Sign-In and Sign-Out URLs. I opted to choose the domain specific issuer option which sets the identifier Google identifies itself as in the SAML authentication request to include the domain name associated with the Google Apps account. You would typically use this if you had multiple subscriptions of Google Apps using the same identity provider. The final step is upload the certificate you downloaded from Azure AD. At this point Google configured to redirect users accessing Google Apps (exempting the Admin Console) to Azure AD to authenticate.
Now that Google is configured, we need to finish the configuration on Azure AD’s end. If you follow the Microsoft tutorial at this point you’re going to run into some issues. In the previous step I opted to use a domain specific issuer, so I’ll need to set the identifier to google.com/a/geekintheweeds.com. For the user identifier I’ll leave the default as the user’s user principal name since it will match the user’s identifier in Google. I also remove the additional attributes Azure AD sends by default since Google will discard them anyway. Once the settings are configured hit the Save button.
Now that both the IdP and SP have been created, it’s time to create a user in Google App to represent my user that will be coming from Azure AD. I refer to this as a “stub user” as it is a record that represents my user who lives authoritatively in Azure Active Directory. For that I switch back to the Google Admin console, click the User’s button, and click the button to create a new user.
Earlier I created a new user in Azure AD named Michael Walsh that has a login ID of email@example.com. Since I’ll be passing the user’s user principal name (UPN) from Azure AD, I’ll need to set the user’s Google login name to match the user’s UPN.
I then hit the Create button and my new user is created. You’ll need that Google assigns the user a temporary password. Like many SaaS solutions Google maintains a credential associated with the user even when the user is configured to use SSO via SAML. Our SP and IdP are configured and the stub user is created in Google, so we’re good to test it out.
I open up Edge and navigate to the Google Apps login page, type in my username, and click the Next button.
I’m then redirect to the Microsoft login page where I authenticate using my Azure AD credentials and hit the sign in button.
After successfully authenticating to Azure AD, I’m redirected back to Google and logged in to my newly created account.
So what happened in the background to make the magic happen? Let’s take a look at a diagram and break down the Fiddler conversation.
The diagram above outlines the simple steps used to achieve the user experience. First the user navigates to the Google login page (remember SP-initiated SSO), enters his or her username, and is sent back an authentication request seen below extracted from Fiddler with instructs to deliver it back to the Azure AD endpoint for our tenant.
The user then authenticates to Azure AD and receives back a SAML response with instructions to deliver it back to Google. The user’s browser posts the SAML assertion to the Google endpoint and the user is successfully authenticated to Google.
Simple right? In comparison to the AWS integration from an SSO-perspective, this was much more straightforward. Unlike the AWS integration, it is required to have a stub user for the user in Google Apps prior to using SSO. This means there is some provisioning work to perform… or does it? Azure AD’s integration again offers some degree of “provisioning”. In my next post I’ll explore those capabilities and perform some simple actions inside Google’s API.
See you next post!