Schémas d'architecture pour la fédération d'identité

Ce document compare quatre modèles d'architecture pour la fédération Google Cloud avec un fournisseur d'identité (IdP) externe. Il fournit également des conseils pour vous aider à choisir une architecture adaptée à votre cas d'utilisation.

Les quatre modèles d'architecture sont les suivants :

Facteurs de décision

Pour choisir un modèle d'architecture adapté à votre organisation, tenez compte de plusieurs facteurs, y compris les suivants :

Portefeuille de services

Les services Google gèrent l'authentification et l'autorisation différemment. Cela a une incidence sur la façon dont vous configurez la fédération d'identité. Deux facteurs déterminent ces différences : le modèle de service SaaS par rapport à PaaS et IaaS, et le modèle d'autorisation IAM par rapport à un modèle spécifique au service.

Modèles de service

  • Software as a Service (SaaS) : Google gère entièrement des services tels que Gmail, Google Ads ou l'application Gemini Enterprise. Ces services ne nécessitent aucun effort de développement et sont prêts à l'emploi. Étant donné que les services SaaS ciblent un large public, la plupart de vos utilisateurs peuvent avoir besoin d'y accéder.
  • Platform as a Service (PaaS) ou Infrastructure as a Service (IaaS) : la plupart des Google Cloud services sont PaaS ou IaaS. Ces services permettent aux utilisateurs techniques de développer, de déployer et d'exploiter des charges de travail personnalisées. Étant donné que ces services ciblent un public technique, seul un sous-ensemble de vos utilisateurs a besoin d'y accéder.

Modèles d'autorisation

Les services Google implémentent l'autorisation de deux manières :

  • IAM : la plupart des Google Cloud services utilisent IAM pour permettre aux administrateurs de gérer un accès précis aux ressources.
  • Autorisation spécifique au service : les services tels que Google Ads, Looker ou Google Workspace n'utilisent pas IAM. Au lieu de cela, les administrateurs gèrent l'accès à l'aide d'outils spécifiques à chaque service.

Ces facteurs entraînent les groupes de services suivants :

SaaS PaaS ou IaaS
Autorisation basée sur IAM Google Cloud Services SaaS tels que l' application Gemini Enterprise et NotebookLM Enterprise Google Cloud Services PaaS et IaaS tels que BigQuery ou Compute Engine
Autorisation spécifique au service Services Google non cloud tels que Google Ads, Google Workspace, et Google Maps Aucun

Pour choisir un modèle d'architecture adapté à votre organisation, déterminez les groupes de services qui s'appliquent à votre organisation.

Résidence des données

Pour authentifier les utilisateurs et gérer les sessions, Cloud Identity, Google Workspace et la fédération des identités des employés traitent les informations personnelles des utilisateurs. Ces informations utilisateur peuvent inclure les éléments suivants :

  • Noms d'utilisateur ou adresses e-mail
  • Attributs utilisateur tels que les prénoms et les noms
  • Noms et appartenances aux groupes

Cloud Identity, Google Workspace et la fédération des identités des employés traitent ces données conformément aux conditions applicables aux données de service et peuvent les stocker en dehors de l'emplacement de votre organisation ou de vos utilisateurs :

  • Cloud Identity et Google Workspace stockent les données de service dans les centres de données Google et peuvent les répliquer dans tous les centres de données. Les données stockées peuvent inclure des informations qui ne sont pas essentielles pour l'authentification, telles que les noms de service, les adresses ou les numéros de téléphone.
  • La fédération des identités des employés stocke les données de service dans Google Cloud les régions et peut les répliquer dans toutes les régions.

Si vous accordez à un utilisateur l'accès à une ressource, IAM stocke leur identifiant principal dans une liaison de rôle. Google Cloud traite les liaisons de rôle conformément aux conditions applicables aux données de service et peut les stocker dans toutes les Google Cloud régions.

Les modèles d'architecture décrits sur cette page nécessitent le stockage d'informations utilisateur, mais ils diffèrent dans la durée de stockage de ces informations :

De nombreux IdP vous permettent d'automatiser la suspension ou la suppression des comptes utilisateur lorsque l'état du compte utilisateur correspondant change dans l'IdP. En fonction de votre IdP et de sa configuration, l'IdP peut retarder la suppression du compte utilisateur jusqu'à l'expiration d'un certain délai de grâce, ce qui peut prolonger la durée de stockage de ces informations utilisateur. Google Cloud

Intégration de Gemini Enterprise à Microsoft 365

Gemini Enterprise vous permet de vous connecter aux services Microsoft 365 à l'aide de deux types de connecteurs :

  • Connecteurs basés sur l'ingestion de données : ces connecteurs explorent Microsoft 365 pour créer un index de recherche dans Google Cloud. Lorsqu'un utilisateur envoie une requête, Gemini Enterprise utilise cet index pour rechercher du contenu et effectue des vérifications d'accès localement en évaluant les listes de contrôle d'accès (LCA) obtenues à partir de Microsoft 365.
  • Connecteurs fédérés : ces connecteurs interrogent Microsoft 365 pour chaque requête. Ils utilisent l'autorisation déléguée pour permettre à Microsoft 365 d'effectuer directement les vérifications d'accès.

Les connecteurs basés sur l'ingestion de données introduisent des exigences spécifiques pour la fédération des utilisateurs :

  • Connaissance de l'appartenance à un groupe : les LCA Microsoft 365 peuvent inclure des entrées pour les groupes ainsi que pour les utilisateurs. Pour déterminer si un utilisateur peut accéder à du contenu, les connecteurs doivent prendre en compte tous les groupes auxquels l'utilisateur appartient. Si le connecteur ne connaît qu'un sous-ensemble des groupes de l'utilisateur, il peut autoriser ou refuser l'accès de manière incorrecte.
  • Conversion d'identifiants : pour évaluer les LCA, le connecteur doit effectuer une conversion entre les identifiants d'utilisateur et de groupe utilisés par Microsoft 365 et les identifiants utilisés par Google Cloud.

Lorsque vous utilisez la fédération des identités des employés, Gemini Enterprise peut convertir de manière fiable les identifiants et évaluer les LCA si vous configurez les mappages d'attributs pour qu'ils soient compatibles avec Gemini Enterprise.

Lorsque vous utilisez la fédération Cloud Identity ou Google Workspace, Microsoft Entra ID contrôle les mappages d'attributs pour le provisionnement des utilisateurs et des groupes plutôt que Google Cloud. Entra détermine les règles de conversion pour les identifiants d'utilisateur et de groupe, ce qui peut impliquer des transformations complexes. Pour évaluer une LCA, le connecteur Gemini Enterprise doit appliquer les mêmes règles de conversion, mais il n'a aucune visibilité sur la configuration Entra. Par conséquent, lorsque vous utilisez la fédération Cloud Identity ou Google Workspace, Gemini Enterprise ne peut pas convertir de manière fiable les identifiants d'utilisateur et de groupe, ni évaluer de manière fiable les LCA.

Pour déterminer le modèle d'architecture adapté à votre organisation, tenez compte de votre utilisation de Gemini Enterprise et si vous prévoyez d'utiliser des connecteurs basés sur l'ingestion de données.

Modèles d'architecture

L'organigramme suivant montre comment ces facteurs déterminent le modèle qui répond aux exigences de votre organisation :

Organigramme montrant comment sélectionner le modèle de fédération d'identité.

  1. Une part importante de votre organisation utilise-t-elle Google Workspace ?

  2. Utilisez-vous des services au-delà de Google Cloud tels que Google Ads ou Google Maps ?

    • Si la réponse est Oui, passez à la décision 3.
    • Si la réponse est Non, passez à la décision 4.

  3. Prévoyez-vous d'utiliser Gemini Enterprise et de l'intégrer à Microsoft 365 ?

  4. Prévoyez-vous d'utiliser Gemini Enterprise ?

  5. Avez-vous des exigences en matière de résidence des données qui vous obligent à minimiser le stockage d'informations utilisateur ?

Fédération Cloud Identity ou Google Workspace

Sélectionnez ce modèle lorsque votre organisation répond à l'un des critères suivants :

  • Une part importante de votre organisation utilise déjà Google Workspace.
  • Vous utilisez des services Google au-delà de Google Cloud , tels que Google Ads ou Google Maps, mais vous ne prévoyez pas d'intégrer Gemini Enterprise à Microsoft 365 à l'aide de connecteurs basés sur l'ingestion de données.
  • Vous n'utilisez que des services, vous ne prévoyez pas d'utiliser Gemini Enterprise et vous n'avez pas d'exigences strictes en matière de résidence des données pour minimiser le stockage des données utilisateur. Google Cloud

Dans ce modèle, vous n'utilisez pas la fédération des identités des employés. Au lieu de cela, vous fédérez votre compte Cloud Identity ou votre compte Google Workspace avec votre IdP, et vous utilisez le provisionnement anticipé des utilisateurs et le provisionnement des groupes.

Architecture de la fédération Cloud Identity et Google Workspace.

Dans ce modèle, vous devez provisionner les utilisateurs et les groupes avant que les utilisateurs puissent se connecter. Sinon, leur tentative de connexion échoue :

  • Provisionnement des utilisateurs : permet d'assurer l'intégration et la désintégration des utilisateurs en temps voulu.
  • Provisionnement des groupes : vous permet d'utiliser des groupes pour gérer l'accès aux services et aux ressources Google . Google Cloud

Si seul un sous-ensemble des utilisateurs de votre organisation a besoin de Google Workspace, ajoutez un abonnement Google Workspace et un abonnement Cloud Identity à votre compte, et n'attribuez des licences Google Workspace qu'aux utilisateurs qui en ont besoin.

Avantages

Limites

  • Le provisionnement anticipé des comptes utilisateur ajoute une surcharge et peut ralentir le processus d'intégration.

  • Vous ne pouvez pas contrôler ni limiter les emplacements que Cloud Identity ou Google Workspace utilisent pour stocker les données utilisateur et les données de groupe. Étant donné que Google traite et stocke les données utilisateur et les données de groupe conformément aux conditions applicables aux données de service, les contrôles de région de données ne couvrent pas ces données, et Google peut les répliquer dans les emplacements des centres de données Google.

  • Gemini Enterprise offre une compatibilité limitée pour la connexion aux sources de données Microsoft lorsque vous utilisez la fédération Cloud Identity ou Google Workspace.

Fédération des identités des employés, sans synchronisation

Sélectionnez ce modèle lorsque votre organisation répond aux critères suivants :

  • Vous n'utilisez que des services. Google Cloud
  • Vous utilisez Gemini Enterprise, mais vous prévoyez de respecter les limites de groupe qui sont imposées par votre IdP.
  • Vous avez des exigences en matière de résidence des données qui nécessitent de minimiser le stockage des informations personnelles des utilisateurs.

Architecture de la fédération d'identité de personnel, sans synchronisation.

Dans ce modèle, vous utilisez la fédération des identités des employés pour fédérer votre Google Cloud organisation avec votre IdP externe.

Ce modèle ne nécessite pas de provisionnement des utilisateurs ni de provisionnement des groupes. Chaque fois qu'un utilisateur se connecte, l'IdP transmet les informations requises sur l' utilisateur, y compris les appartenances aux groupes et les attributs personnalisés, à Google Cloud, et Google Cloud ne conserve ces informations que pendant la durée de la session utilisateur.

Avantages

  • Vous n'avez pas besoin de stocker ni de gérer les comptes utilisateur ou les groupes dans Google Cloud.
  • Le modèle vous permet d'utiliser des connecteurs basés sur l'ingestion de données pour intégrer Gemini Enterprise à Microsoft 365.

Limites

  • La fédération des identités des employés est une fonctionnalité IAM qui ne permet aux utilisateurs d'accéder qu'aux services qui utilisent IAM. Les utilisateurs qui s'authentifient à l'aide de la fédération des identités des employés ne peuvent pas accéder aux services Google tels que Google Ads, Looker ou Google Marketing Platform.
  • Les utilisateurs qui s'authentifient à l'aide de la fédération des identités des employés ne peuvent pas accéder à certaines Google Cloud fonctionnalités. Pour en savoir plus, consultez la section Fédération des identités : produits et limites.
  • De nombreux IdP limitent le nombre d'appartenances à des groupes qu'ils peuvent transmettre à la fédération des identités des employés dans une assertion SAML ou un jeton d'ID. Pour respecter ces limites, vous devrez peut-être renforcer la gouvernance des groupes et limiter les types de groupes à inclure dans les assertions ou les jetons.
  • Lorsque vous partagez des ressources telles qu'un notebook NotebookLM Enterprise, vous ne pouvez pas rechercher un groupe par son nom. Au lieu de cela, les utilisateurs doivent saisir manuellement leurs identifiants.

Si vous utilisez Microsoft Entra ID, vous pouvez utiliser une variante de ce modèle en configurant des attributs supplémentaires. Lorsque vous configurez des attributs supplémentaires, la fédération des identités des employés exécute un rappel vers l'API Microsoft Graph lors de l'authentification de l'utilisateur pour récupérer les appartenances aux groupes. Cette configuration vous permet de surmonter les limites d'appartenance à un groupe d'Entra pour les assertions SAML et les jetons d'ID, et d'utiliser jusqu'à 999 appartenances à des groupes par utilisateur.

Fédération des identités des employés avec SCIM

Sélectionnez ce modèle lorsque votre organisation répond aux critères suivants :

  • Vous n'utilisez que des services. Google Cloud Autrement dit, vous n'utilisez pas de services Google externes tels que Google Ads ou Google Maps.
  • Vous prévoyez d'utiliser Gemini Enterprise ou NotebookLM Enterprise, et vous devez prendre en charge jusqu'à 2 000 appartenances à des groupes par utilisateur, ou la possibilité de rechercher des groupes par leur nom lorsque vous partagez des ressources.

Architecture de la fédération des identités des employés avec SCIM.

Dans ce modèle, vous utilisez la fédération des identités des employés pour fédérer votre Google Cloud organisation. Pour augmenter le nombre de groupes que vous pouvez utiliser pour Gemini Enterprise, vous configurez également SCIM pour provisionner à l'avance les informations sur l'appartenance aux groupes.

Avantages

  • Le modèle vous permet d'utiliser des connecteurs basés sur l'ingestion de données pour intégrer Gemini Enterprise à Microsoft 365.
  • Vous pouvez utiliser jusqu'à 2 000 appartenances à des groupes par utilisateur pour contrôler l'accès à Gemini Enterprise et à NotebookLM Enterprise, et permettre aux connecteurs basés sur l'ingestion de données de Gemini Enterprise d'effectuer des vérifications d'accès.
  • Lorsque vous partagez des ressources telles qu'un notebook NotebookLM Enterprise, vous pouvez rechercher des groupes par leur nom pour améliorer l'expérience utilisateur globale.

Limites

  • La compatibilité avec les groupes provisionnés par SCIM est limitée à Gemini Enterprise et NotebookLM Enterprise. Les autres services ne peuvent consommer que les appartenances aux groupes que votre IdP transmet dans l'assertion SAML ou le jeton d'ID.
  • La fédération des identités des employés est une fonctionnalité IAM qui ne permet aux utilisateurs d'accéder qu'aux services qui utilisent IAM. Les utilisateurs qui s'authentifient à l'aide de la fédération des identités des employés ne peuvent pas accéder aux services Google tels que Google Ads, Looker ou Google Marketing Platform.
  • Les utilisateurs qui s'authentifient à l'aide de la fédération des identités des employés ne peuvent pas accéder à certaines fonctionnalités. Google Cloud Pour en savoir plus, consultez la section Fédération des identités : produits et limites.

Fédération hybride Cloud Identity et des identités des employés

Sélectionnez ce modèle lorsque votre organisation répond aux critères suivants :

  • Vous utilisez des services Google au-delà de Google Cloud (tels que Google Ads ou Google Maps).
  • Vous prévoyez d'utiliser Gemini Enterprise et de l'intégrer à Microsoft 365.

Architecture de la fédération hybride Cloud Identity et Workforce Identity Federation.

Ce modèle combine deux des modèles précédents :

  • Vous utilisez la fédération des identités des employés (sans synchronisation ou avec SCIM) pour gérer l'accès à Gemini Enterprise et à NotebookLM Enterprise.
  • Vous utilisez la fédération Cloud Identity ou Google Workspace pour gérer l'accès à d'autres services, y compris Google Cloud et les services Google non cloud.

Avantages

Ce modèle vous permet de combiner les avantages des deux modèles précédents :

  • Vous pouvez connecter Gemini Enterprise à des sources de données Microsoft sans limitation de fonctionnalités.
  • Les utilisateurs peuvent s'authentifier auprès des services Google, que ces services utilisent ou non IAM.
  • Utilisez l'ensemble complet des Google Cloud fonctionnalités.

Limites

  • Vous devez gérer deux configurations de partie de confiance distinctes dans votre IdP externe : une pour Cloud Identity et une pour la fédération des identités des employés.
  • Selon que vous configurez un utilisateur pour qu'il utilise Cloud Identity ou la fédération des identités des employés, son expérience de connexion peut être différente.
  • Lorsque vous gérez des stratégies d'autorisation IAM, vous devez utiliser différents identifiants principaux en fonction de la façon dont un utilisateur s'authentifie. Par exemple, un utilisateur connu sous le nom bob@example.com dans votre IdP externe peut avoir l'identifiant principal bob@example.com ou principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID//subject/SUBJECT_ID dans IAM, selon que cet utilisateur s'authentifie à l'aide de la fédération Cloud Identity ou à l'aide de la fédération des identités des employés.
  • Vous ne pouvez pas créer de groupes contenant un mélange d'utilisateurs Cloud Identity et de comptes principaux de la fédération des identités des employés. Les groupes Cloud Identity ne peuvent contenir que des utilisateurs Cloud Identity, et les groupes d'identités des employés ne peuvent contenir que des comptes principaux de la fédération des identités des employés.
  • L'extension de l'utilisation de la fédération des identités des employés au-delà de Gemini Enterprise peut obliger les utilisateurs à passer d'une identité à l'autre ou à ne pas savoir comment s'authentifier.

Étape suivante