This document shows how to add Google services and Identity-Aware Proxy (IAP) web-secured web applications to the Azure Active Directory (Azure AD) My Apps portal and how to enable automatic sign-on for these applications.
The document assumes that you have federated your Cloud Identity or Google Workspace account with Azure AD by configuring Azure AD for single sign-on.
Before you begin
Make sure you've completed the steps to federate your Cloud Identity or Google Workspace account with Azure AD.
Initiating single sign-on from a portal
To support authenticating with an external identity provider (IdP) like Azure AD, Cloud Identity and Google Workspace rely on service provider–initiated sign-on. With this type of sign-on, authentication starts at the service provider, which then redirects you to the IdP—for example:
- You access a Google service such as the Google Cloud console or Looker Studio by opening a URL or bookmark. Google and its services take the role as the service provider in this scenario.
- The Google Sign-in screen appears, prompting you to enter the email address of your Google identity.
- You're redirected to Azure AD, which serves as the IdP.
- You sign in to Azure AD.
- Azure AD redirects you back to the Google service that you originally attempted to access.
A benefit of service provider–initiated sign-on is that users can directly access Google services by opening a link or using a bookmark. If your organization uses Azure AD, then you can use the Azure AD My Apps portal for this purpose. Not being forced to open applications through a portal is convenient for power users who bookmark specific sites or might memorize certain URLs. For other users, it can still be valuable to surface the links to relevant applications in a portal.
However, adding a link such as https://lookerstudio.google.com to the Azure AD My Apps portal reveals a shortcoming of the service provider–initiated sign-on process. Although a user that clicks the link in the portal has a valid Azure AD session, they might still see the Google Sign-in screen and are prompted to enter their email address. This seemingly redundant sign-in prompt is a result of Google Sign-In not being made aware of the existing Azure AD session.
You can avoid the additional Google Sign-in prompt by using special URLs when configuring the Azure AD My Apps portal. These URLs embed a hint about which Cloud Identity or Google Workspace account users are expected to use. The extra information enables authentication to be performed silently, resulting in an improved user experience.
Adding links to the Azure AD My Apps portal
The following table lists common Google services, the corresponding name in Azure AD, and the link that you can use to implement SSO as outlined in the previous section.
For each Google service that you want to add to the Azure AD My Apps portal, create a new enterprise application:
- In the Azure portal, go to Azure Active Directory > Enterprise applications.
- Click New application.
Click Create your own application and enter the following:
- What's the name of your app: Enter the name of the Google service as indicated in the preceding table.
- What are you looking to do with your application: Select Integrate any other application you don't find in the gallery (Non-gallery).
Change the logo to the file linked in the table.
In the menu on the left, select Single sign-on.
Enter the URL listed in the table—for example,
DOMAINwith the primary domain name of your Cloud Identity or Google Workspace account such as
Notice that you don't have to configure SAML-based SSO in the application. All single sign-on operations continue to be handled by the application that you previously created for single sign-on.
To assign the application to users, do the following:
- In the menu on the left, select Properties.
- Set User assignment required to Yes.
- Click Save.
- In the menu on the left, click Manage > Users and groups.
- Click Add user.
- Select Users.
- Select the users or groups that you want to provision. If you select a group, all members of the group are provisioned.
- Click Select.
- Click Assign.
It might take several minutes for a link to show up in the My Apps portal.
Assigning users and groups to individual applications in Azure AD controls the visibility of the link, but it doesn't control access to a service. A service that isn't visible on a user's My Apps portal might still be accessible if the user opens the right URL. To control which users and groups are allowed to access a service, you must also turn the service on or off in the Google Admin Console.
You can simplify the process of controlling visibility and access by using groups:
- For each Google service, create a security group in Azure AD—for
Looker Studio usersand
Google Drive users.
- Assign the groups to the appropriate Azure AD enterprise application as
outlined in the previous section. For example, assign
Looker Studio usersto the Looker Studio application and
Google Drive usersto the Google Drive application.
- Configure the groups to be provisioned to your Cloud Identity or Google Workspace account.
- In the
turn on the respective service for each group.
For example, turn on Looker Studio for the
Looker Studio usersgroup and Google Drive for the
Google Drive usersgroup. Turn the service off for everybody else.
By adding and removing members to these groups, you now control both access and visibility in a single step.
IAP-protected web applications
If you're using Identity-Aware Proxy (IAP) to protect your web applications, you can add links to these applications to the Azure AD My Apps portal and enable a single sign-on experience for them.
Adding links to the Azure AD My Apps portal
The process for adding a link to the Azure AD My Apps portal is the same as for Google services, but you must use the URL of your IAP-protected web application.
As you can with Google services, you can prevent users from seeing a Google sign-in screen after following a link to a IAP-protected web application in the portal, but the process is different. Instead of using a special URL, you configure IAP to always use a specific Cloud Identity or Google Workspace account for authentication:
In the Google Cloud console, activate Cloud Shell.
Initialize an environment variable:
primary-domainwith the primary domain of your Cloud Identity or Google Workspace account—for example,
Create a temporary settings file that instructs IAP to always use the primary domain of your Cloud Identity or Google Workspace account for authentication:
cat << EOF > iap-settings.yaml accessSettings: oauthSettings: loginHint: "$PRIMARY_DOMAIN" EOF
Apply the setting to all IAP web resources in the project:
gcloud iap settings set iap-settings.yaml --resource-type=iap_web
Remove the temporary settings file:
Assigning users and groups to individual applications in Azure AD controls the visibility of the link to your IAP-protected web application, but does not control access to the application. To control access, you also have to customize the IAM policy of the IAP-protected web application.
As with Google services, you can simplify the process of controlling visibility and access by using groups:
- For each application, create a security group in Azure AD—for example,
Payroll application users.
- Assign the group to the respective Azure AD enterprise application.
- Configure the group to be provisioned to your Cloud Identity or Google Workspace account.
- Update the IAM policy
of the IAP-protected web application to grant the
IAP-Secured Web App User role to the
Payroll application usersgroup while disallowing access for other users
By adding and removing members to the
Payroll application users group, you
control both access and visibility in a single step.
- Learn more about federating Google Cloud with Azure AD.
- Read about best practices for planning accounts and organizations and best practices for federating Google Cloud with an external IdP.
- Read more about Identity-Aware Proxy.