Architecture patterns for identity federation

This document compares four architectural patterns to federate Google Cloud with an external identity provider (IdP). It also provides guidance to help you choose a suitable architecture for your use case.

The four architectural patterns are as follows:

Decision factors

To choose an architecture pattern that's suitable for your organization, consider multiple factors, including the following:

  • Service portfolio: Your portfolio of Google services, and whether it includes Google Workspace and services beyond Google Cloud, such as Google Ads, Google Maps, or Chrome Enterprise.
  • Data residency: Your data residency and sovereignty requirements.
  • Gemini Enterprise integration with Microsoft 365: Your use of Gemini Enterprise or Gemini Notebook Enterprise and whether you plan to integrate Gemini Enterprise with Microsoft 365 services.

Service portfolio

Google services manage authentication and authorization differently. This affects how you configure identity federation. Two factors determine these differences: the service model SaaS versus PaaS and IaaS and the authorization model IAM versus service-specific.

Service models

  • Software as a Service (SaaS): Google fully manages services like Gmail, Google Ads, or the Gemini Enterprise app. These services require no development effort and are ready to use. Because SaaS services target a large audience, most of your users might require access to them.
  • Platform as a Service (PaaS) or Infrastructure as a Service (IaaS): Most Google Cloud services are PaaS or IaaS. These services let technical users develop, deploy, and operate custom workloads. Because these services target a technical audience, only a subset of your users require access.

Authorization models

Google services implement authorization in one of two ways:

  • IAM: Most Google Cloud services use IAM to let administrators manage fine-grained access to resources.
  • Service-specific authorization: Services such as Google Ads, Looker, or Google Workspace don't use IAM. Instead, administrators manage access using tools specific to each service.

These factors result in the following service groups:

SaaS PaaS or IaaS
IAM-based authorization Google Cloud SaaS services such as the Gemini Enterprise app and Gemini Notebook Enterprise Google Cloud PaaS and IaaS services such as BigQuery or Compute Engine
Service-specific authorization Non-cloud Google services such as Google Ads, Google Workspace, and Google Maps None

To choose an architecture pattern that's suitable for your organization, consider which service groups apply to your organization.

Data residency

To authenticate users and manage sessions, Cloud Identity, Google Workspace, and Workforce Identity Federation process personal user information. This user information can include the following:

  • User names or email addresses
  • User attributes such as first names and last names
  • Group names and memberships

Cloud Identity, Google Workspace, and Workforce Identity Federation process this data under the terms for service data and might store it outside your organization's or users' locations:

  • Cloud Identity and Google Workspace store service data in Google data centers and might replicate it across all data centers. The stored data might include information that isn't essential for authentication, such as department names, addresses, or phone numbers.
  • Workforce Identity Federation stores service data in Google Cloud regions and might replicate it across all regions.

If you grant a user access to a resource, IAM stores their principal identifier in a role binding. Google Cloud processes role bindings under the terms for service data and might store them across all Google Cloud regions.

The architecture patterns described on this page require storage of user information, but they differ in how long they store that user information:

Many IdPs let you automate suspending or deleting user accounts when the corresponding user account status changes in the IdP. Depending on your IdP and its configuration, the IdP might delay user account deletion until a certain grace period elapses, which can extend how long Google Cloud stores that user information.

Gemini Enterprise integration with Microsoft 365

Gemini Enterprise lets you connect to Microsoft 365 services using two types of connectors:

  • Data ingestion-based connectors: These connectors crawl Microsoft 365 to build a search index in Google Cloud. When a user submits a prompt, Gemini Enterprise uses this index to search