Azure AD My Apps portal integration

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:

  1. You access a Google service such as the Cloud Console or Data Studio by opening a URL or bookmark. Google and its services take the role as the service provider in this scenario.
  2. The Google Sign-in screen appears, prompting you to enter the email address of your Google identity.
  3. You're redirected to Azure AD, which serves as the IdP.
  4. You sign in to Azure AD.
  5. 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://datastudio.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.

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.

Google service App name in Azure AD URL Logo
Docs Google Docs http://docs.google.com/a/DOMAIN Google Docs logo
Sheets Google Docs https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://sheets.google.com Google Docs logo
Slides Google Docs https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://slides.google.com Google Docs logo
Drive Google Docs http://drive.google.com/a/DOMAIN Google Docs logo
Mail Google Mail (offline) http://mail.google.com/a/DOMAIN Google Mail logo
Groups Google http://groups.google.com/a/DOMAIN Google Groups logo
Keep Google https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://keep.google.com Google Keep logo
Data Studio Google https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://datastudio.google.com Data Studio logo

For each Google service that you want to add to the Azure AD My Apps portal, create a new enterprise application:

  1. In the Azure portal, go to Azure Active Directory > Enterprise applications.
  2. Click New application.
  3. Search for the app name in Azure AD as indicated in the preceding table.
  4. Customize the name of the application as necessary and click Create.
  5. Select Properties.
  6. Change the logo to the file linked in the table.
  7. Click Save.
  8. In the menu on the left, select Single sign-on.
  9. Select Linked.
  10. Enter the URL listed in the table—for example, http://docs.google.com/a/DOMAIN.

    Replace DOMAIN with the primary domain name of your Cloud Identity or Google Workspace account such as example.com.

  11. Click Save.

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.

If you want only a subset of your users to see the link in the Azure AD My Apps portal, configure user assignment as follows:

  1. In the menu on the left, select Properties.
  2. Set User assignment required to Yes.
  3. Click Save.
  4. In the menu on the left, click Manage > Users and groups.
  5. Click Add user.
  6. Select Users.
  7. Select the users or groups that you want to provision. If you select a group, all members of the group are provisioned.
  8. Click Select.
  9. Click Assign.

It might take several minutes for a link to show up in the My Apps portal.

Controlling access

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:

  1. For each Google service, create a security group in Azure AD—for example, Google DataStudio users and Google Drive users.
  2. Assign the groups to the appropriate Azure AD enterprise application as outlined in the previous section. For example, assign Google Data Studio users to the Google Data Studio application and Google Drive users to the Google Drive application.
  3. Configure the groups to be provisioned to your Cloud Identity or Google Workspace account.
  4. In the Admin Console, turn on the respective service for each group. For example, turn on Google Data Studio for the Google DataStudio users group and Google Drive for the Google Drive users group. 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.

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:

  1. In the Cloud Console, activate Cloud Shell.

    Activate Cloud Shell

  2. Initialize an environment variable:

    PRIMARY_DOMAIN=primary-domain

    Replace primary-domain with the primary domain of your Cloud Identity or Google Workspace account—for example, example.com.

  3. 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
    
  4. Apply the setting to all IAP web resources in the project:

    gcloud iap settings set iap-settings.yaml --resource-type=iap_web
  5. Remove the temporary settings file:

    rm iap-settings.yaml

Controlling access

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:

  1. For each application, create a security group in Azure AD—for example, Payroll application users.
  2. Assign the group to the respective Azure AD enterprise application.
  3. Configure the group to be provisioned to your Cloud Identity or Google Workspace account.
  4. Update the IAM policy of the IAP-protected web application to grant the IAP-Secured Web App User role to the Payroll application users group 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.

What's next