Configurer un fournisseur d'identité

Pour appliquer le contrôle des accès aux sources de données et sécuriser les données dans Gemini Enterprise, vous devez configurer un fournisseur d'identité. Cela implique de configurer le fournisseur d'identité et de gérer les autorisations pour vos sources de données. Google utilise votre fournisseur d'identité pour identifier l'utilisateur final qui effectue une recherche et déterminer s'il a accès aux documents renvoyés en tant que résultats.

Choisir votre type de fournisseur d'identité

Le type de fournisseur d'identité que vous choisissez dépend des sources de données connectées à votre application Gemini Enterprise. Gemini Enterprise est compatible avec les options suivantes :

Type de fournisseur d'identité Cas d'utilisation
Identité Google Google Identity est le fournisseur d'identité recommandé pour Gemini Enterprise.

Google Identity est compatible avec :
  • Toutes les sources de données Google first party qui utilisent l'ingestion de données ou la fédération de données. Vous devez utiliser Google Identity lorsque vous vous connectez à des sources de données Google Workspace.
  • Toutes les sources de données tierces qui utilisent la fédération de données, où les utilisateurs s'authentifient directement auprès du service tiers à l'aide d'OAuth.
  • Toutes les sources de données tierces qui utilisent l'ingestion de données, à l'exception des sources de données Microsoft 365, telles que SharePoint, OneDrive ou Outlook, qui nécessitent Microsoft Entra ID et la fédération d'identité Workforce.
Avant de configurer l'identité Google, déterminez l'attribut utilisateur unique utilisé par votre organisation, généralement l'adresse e-mail de l'utilisateur. Si les utilisateurs ont plusieurs adresses e-mail, vous devez ajouter un alias d'adresse e-mail.
Fournisseur d'identité tiers Lorsque vous connectez Gemini Enterprise uniquement à des sources de données tierces et que vous utilisez déjà un fournisseur d'identité tiers compatible avec OIDC ou SAML 2.0, comme Microsoft Entra ID, Okta ou AD FS, vous pouvez utiliser Google Identity ou la fédération d'identité de personnel. Google recommande d'utiliser Google Identity pour les nouvelles configurations. Les clients existants qui utilisent déjà la fédération des identités des employés peuvent choisir de continuer à l'utiliser. Pour en savoir plus, consultez Fédération des identités des employés.

Avant de configurer la fédération d'identité de personnel, déterminez les attributs utilisateur uniques utilisés par votre organisation et mappez-les à la fédération d'identité de personnel.

Contrôle des accès pour les connecteurs Google Workspace

Lorsque vous utilisez l'ancrage et la recherche de données d'entreprise avec des connecteurs Google Workspace (tels que Personnes de Google Workspace ou Groupes Google), Gemini Enterprise respecte strictement les listes de contrôle d'accès (ACL) et les autorisations du système source.

Principe de base : pas d'élévation des privilèges

Un utilisateur qui interagit avec Gemini Enterprise ne peut afficher et ancrer les réponses que sur les informations auxquelles il est déjà autorisé à accéder directement dans l'application source Google Workspace. Gemini Enterprise ne contourne jamais les contrôles d'accès au système source ni n'accorde d'autorisations supplémentaires.

  • Personnes de Google Workspace (annuaire) : la visibilité des utilisateurs dans les résultats de recherche et d'ancrage respecte les paramètres de visibilité de l'annuaire de votre organisation. Par exemple, si la visibilité d'un utilisateur dans l'annuaire Google Workspace est limitée à son propre service ou unité organisationnelle, il ne pourra trouver que les collègues de ce service à l'aide de Gemini Enterprise. Ils ne peuvent pas consulter les profils des employés des services soumis à des restrictions.

  • Groupes Google : la découverte et l'ancrage de contenu respectent les paramètres d'accès et d'appartenance aux groupes. Un utilisateur ne peut rechercher et afficher que le contenu des groupes Google dont il est membre et qu'il est autorisé à consulter. Les utilisateurs qui ne sont pas membres ne peuvent pas découvrir ni consulter les discussions des groupes privés dans Gemini Enterprise.

Où gérer les autorisations

Vous ne configurez pas les paramètres de contrôle des accès et de visibilité dans les paramètres du connecteur Gemini Enterprise de la console Google Cloud . En revanche, un administrateur Google Workspace configure les paramètres d'autorisation, d'appartenance et de visibilité dans le système source :

  • Visibilité du profil utilisateur : l'administrateur Google Workspace configure la visibilité du profil utilisateur dans la console d'administration Google. Pour en savoir plus, consultez Configurer le partage de répertoires.

  • Accès aux groupes et appartenance à un groupe : l'administrateur Google Workspace configure l'accès aux groupes et l'appartenance à un groupe dans Google Groupes ou la console d'administration Google. Pour en savoir plus, consultez Configurer et gérer des groupes.

Fédération des identités des employés pour les fournisseurs d'identité tiers

Cette section explique comment configurer la fédération des identités des employés pour les fournisseurs d'identité tiers. Vous pouvez également vérifier si la configuration de la fédération des identités des employés fonctionne comme prévu.

Configurer la fédération des identités des employés

Pour savoir comment configurer la fédération des identités des employés avec votre connecteur d'identité tiers, consultez les ressources suivantes :

Fournisseur d'identité Ressources
Entra ID
Okta
OIDC ou SAML 2.0

Configurer le mappage des attributs

Le mappage d'attributs vous aide à associer vos informations d'identité tierces à Google à l'aide de la fédération des identités des employés.

Lorsque vous configurez le mappage d'attributs dans la fédération des identités des employés, tenez compte des points suivants :

  • L'attribut google.subject est utilisé pour le mappage d'attributs, l'attribution de licences et le partage de notebooks. Nous vous recommandons de mapper google.subject à l'adresse e-mail de l'utilisateur en minuscules, car l'attribution de licence est sensible à la casse.

  • Si votre organisation possède plusieurs identifiants uniques, mappez ces attributs organisationnels uniques à l'aide de l'attribut attribute.as_user_identifier_number between 1 and 50.

    Par exemple, si votre organisation utilise à la fois l'adresse e-mail et le nom principal comme identifiants utilisateur dans différentes applications, et que le nom principal est défini comme preferred_username auprès de votre fournisseur d'identité tiers, vous pouvez le mapper à Gemini Enterprise à l'aide du mappage d'attributs de la fédération des identités des employés (par exemple, attribute.as_user_identifier_1=assertion.preferred_username).

Les exemples suivants montrent les mappages d'attributs requis pour les fournisseurs d'identité courants. Vous pouvez ajouter d'autres mappages d'attributs pour prendre en charge des identifiants uniques supplémentaires, comme décrit précédemment.

  • Entra ID avec le protocole OIDC
    Cet exemple utilise l'adresse e-mail pour identifier les utilisateurs de manière unique.

    google.subject=assertion.email.lowerAscii()
google.groups=assertion.groups
google.display_name=assertion.given_name

  • Entra ID avec le protocole SAML
    Cet exemple utilise l'adresse e-mail pour identifier les utilisateurs de manière unique.

    google.subject=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'][0].lowerAscii()
google.groups=assertion.attributes['http://schemas.microsoft.com/ws/2008/06/identity/claims/groups']
google.display_name=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname'][0]

  • Okta avec le protocole OIDC
    Cet exemple utilise l'adresse e-mail pour identifier les utilisateurs de manière unique.

    google.subject=assertion.email.lowerAscii()
google.groups=assertion.groups

  • Okta avec le protocole SAML
    Cet exemple utilise l'assertion du sujet du jeton JWT pour identifier de manière unique les utilisateurs.

    google.subject=assertion.subject.lowerAscii()
google.groups=assertion.attributes['groups']

Facultatif : Vérifier la configuration de la fédération des identités des employés

Pour vérifier que les connexions ont réussi et que le mappage des attributs est correct à l'aide de la fonctionnalité de journalisation des audits de la fédération d'identité de personnel, procédez comme suit :

  1. Activez les journaux d'audit pour l'API Security Token Service de l'activité "Accès aux données".

    1. Dans la console Google Cloud , accédez à la page Journaux d'audit :

      Accéder aux journaux d'audit

      Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est IAM et administration.

    2. Sélectionnez un projet, un dossier ou une organisation Google Cloud existants.
    3. Activez les journaux d'audit des accès aux données.
      1. Consultez la documentation sur la journalisation pour obtenir la procédure détaillée permettant d'activer les journaux d'audit.
      2. Pour l'API Security Token Service, sélectionnez le type de journal d'audit Lecture administrateur. Pour en savoir plus, consultez Exemples de journaux pour la fédération des identités des employés.

  2. Activez la journalisation détaillée dans votre pool d'employés. La fonctionnalité de groupes étendus de la fédération des identités des employés pour Microsoft Entra ID ne génère pas d'informations détaillées de journalisation d'audit.

    1. Accédez à la page Pools d'identités de personnel:

      Accéder aux pools d'identités de personnel

    2. Dans le tableau, sélectionnez le pool.

    3. Cliquez sur le bouton Activer la journalisation d'audit détaillée pour l'activer.

    4. Cliquez sur Enregistrer le pool.

  3. Dans la section Fournisseurs, cliquez sur l'URL de connexion de votre fournisseur, puis connectez-vous à la console Google Cloud en tant qu'utilisateur du pool de personnel.

  4. Consultez les journaux d'audit générés lors de votre connexion.

    1. Accédez à la page Pools d'identités de personnel:

      Accéder aux pools d'identités de personnel

    2. Dans le tableau, sélectionnez le pool auquel vous vous êtes connecté.

    3. Cliquez sur Afficher à côté de Journaux.

    4. Sur la page du journal d'audit, supprimez le filtre protoPayload.resourceName de la requête.

    5. Cliquez sur Exécuter la requête.

  5. Consultez les journaux d'audit pour trouver une entrée avec la méthode google.identity.sts.SecurityTokenService.WebSignIn qui correspond au code temporel de la connexion.

  6. Vérifiez que le champ metadata.mapped_attributes du journal correspond à l'attribut que vous avez utilisé lors de la configuration de la fédération des identités des employés pour les fournisseurs d'identité tiers.

    Par exemple :

    "metadata": {
  "mapped_attributes": {
    "attributes.as_user_identifier_1": "alex@admin.altostrat.com"
    "google.subject": "alex@altostrat.com"
    "google.groups": "[123abc-456d, efg-h789-ijk]"
  }
},

Limites

Lorsque vous connectez vos sources de données à l'aide d'un connecteur pour créer des datastores, les limites suivantes s'appliquent :

  • 3 000 lecteurs sont autorisés par document. Chaque compte principal est considéré comme un lecteur. Un compte principal peut être un groupe ou un utilisateur individuel.

  • Vous pouvez sélectionner un type de fournisseur d'identité par emplacement compatible dans Gemini Enterprise.

  • Si les paramètres du fournisseur d'identité sont modifiés en changeant le type de fournisseur d'identité ou le pool d'employés, les datastores existants ne sont pas automatiquement mis à jour avec les nouveaux paramètres. Vous devez supprimer et recréer ces datastores pour appliquer les nouveaux paramètres d'identité.

  • Pour définir une source de données comme étant à accès contrôlé, vous devez sélectionner ce paramètre lors de la création du datastore. Vous ne pouvez pas activer ni désactiver ce paramètre pour un datastore existant.

  • Pour prévisualiser les résultats de l'UI pour les applications de recherche qui utilisent le contrôle d'accès tiers, vous devez vous connecter à la console fédérée ou utiliser l'application Web. Consultez Prévisualiser votre application.

Se connecter à votre fournisseur d'identité

La section suivante explique comment vous connecter à votre fournisseur d'identité à l'aide de la consoleGoogle Cloud .

Avant de commencer

Avant de connecter le fournisseur d'identité, procédez comme suit :

Associer un fournisseur d'identité

Pour spécifier un fournisseur d'identité pour Gemini Enterprise et activer le contrôle des accès aux sources de données :

  1. Dans la console Google Cloud , accédez à la page Gemini Enterprise.

    Gemini Enterprise

  2. Cliquez sur Paramètres > Authentification.

  3. Cliquez sur Ajouter un fournisseur d'identité pour l'établissement que vous souhaitez modifier.

  4. Cliquez sur Ajouter un fournisseur d'identité, puis sélectionnez le type de fournisseur d'identité.
     Si vous sélectionnez Identité tierce, vous devez également sélectionner le pool de personnel qui s'applique à vos sources de données.

  5. Cliquez sur Enregistrer les modifications.

Accorder des autorisations aux utilisateurs

Les utilisateurs ont besoin du rôle Utilisateur Gemini Enterprise (roles/discoveryengine.agentspaceUser) pour accéder aux applications, les gérer et les partager.

Type de fournisseur d'identité Description
Identité Google
Fournisseur d'identité tiers

Impact des modifications apportées aux paramètres du fournisseur d'identité sur les connecteurs d'ingestion

Lorsque vous modifiez les paramètres d'identité, tels que le fournisseur d'identité ou le pool de fédération des identités des employés, les datastores existants qui utilisent l'ingestion de données ne sont pas automatiquement mis à jour. Pour appliquer les nouveaux paramètres d'identité, vous devez supprimer et recréer les datastores concernés.

Le tableau suivant récapitule les modifications des paramètres d'identité qui nécessitent de recréer le datastore :

Type de modification Nécessite de recréer le datastore
Passer de Google Identity à un fournisseur d'identité tiers Oui
Passer à un tout nouveau pool de fédération d'identité de personnel Oui
Modifier le mappage d'attributs dans le fournisseur d'identité actuel Non
Passer à un autre fournisseur dans le même pool de fédération d'identité des employés. Par exemple, en utilisant Entra au lieu d'Okta. Non

Modifications de l'identité des utilisateurs

Gemini Enterprise associe l'historique des discussions, les notebooks et les agents créés par un utilisateur à son identifiant principal. Si vous utilisez la fédération d'identité de personnel, l'identifiant principal inclut la valeur que votre mappage d'attributs attribue à google.subject. Exemple :

principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE

Impact de la modification d'une valeur de sujet

Si la valeur mappée à google.subject change pour un utilisateur, Gemini Enterprise le considère comme un nouvel utilisateur. Par exemple, cela se produit lorsque le nom d'utilisateur principal (UPN) ou l'adresse e-mail de l'utilisateur changent dans Microsoft Entra ID et que votre mappage d'attributs utilise cet attribut. Les identifiants de comptes principaux sont sensibles à la casse. Par conséquent, toute modification de la casse est considérée comme une modification.

Après le changement, les éléments suivants s'appliqueront :

  • L'utilisateur ne peut pas accéder à l'historique des discussions, aux notebooks ni aux agents associés à l'identifiant principal précédent.
  • Gemini Enterprise ne migre pas les données de l'ancien identifiant principal vers le nouveau.
  • Les licences et les rôles IAM accordés à l'ancien identifiant principal ne s'appliquent pas au nouvel identifiant principal.

Se préparer à un changement de valeur du sujet

Pour réduire l'impact d'une modification de la valeur d'un sujet :

  • Avant de modifier l'UPN ou l'adresse e-mail d'un utilisateur dans votre fournisseur d'identité, informez-le et demandez-lui de partager les agents privés ou les notebooks qu'il souhaite conserver.
  • Attribuez une licence Gemini Enterprise au nouvel identifiant principal et accordez-lui les rôles requis. Pour en savoir plus, consultez Accorder des autorisations aux utilisateurs.
  • Transférez la propriété des agents que l'utilisateur a partagés avec d'autres personnes vers le nouvel identifiant principal. Vous ne pouvez pas transférer la propriété des agents qui ne sont pas partagés.

Résoudre les problèmes d'authentification

Si les utilisateurs reçoivent des erreurs HTTP 401 indiquant des identifiants d'authentification non valides lorsqu'ils accèdent à Gemini Enterprise, vérifiez les points suivants.

Vérifications de base

  • État du navigateur : demandez à l'utilisateur de vider le cache et les cookies du navigateur, ou de se connecter depuis une fenêtre de navigation privée.
  • Compte connecté : assurez-vous que l'utilisateur se connecte avec le compte attendu par la configuration de votre fournisseur d'identité. Si vous utilisez la fédération d'identité de personnel, l'identité de l'utilisateur doit correspondre à votre mappage d'attributs.
  • Horloge de l'appareil : assurez-vous que l'horloge de l'appareil est synchronisée, par exemple à l'aide du protocole NTP (Network Time Protocol). La dérive de l'horloge sur l'appareil peut entraîner l'échec de l'authentification.

Règles du réseau et du fournisseur d'identité

  • Proxies et pare-feu : les proxies, les pare-feu ou les passerelles Web sécurisées qui inspectent le trafic TLS peuvent supprimer ou modifier l'en-tête Authorization. Assurez-vous que ces appareils ne modifient pas les requêtes envoyées aux domaines Google.
  • Règles d'accès du fournisseur d'identité : vérifiez si les règles d'accès de votre fournisseur d'identité, telles que les règles d'accès conditionnel dans Microsoft Entra ID, bloquent la connexion en raison de la conformité de l'appareil, des plages d'adresses IP ou de l'emplacement.
  • Accès contextuel : si votre organisation utilise l'accès contextuel avec Google Cloud ou Google Workspace, vérifiez si un niveau d'accès basé sur l'adresse IP bloque les requêtes que Gemini Enterprise effectue au nom de l'utilisateur. Ces requêtes proviennent des serveurs de Google, et non du réseau de l'utilisateur. Elles ne correspondent donc pas aux plages d'adresses IP de l'entreprise. Ajoutez un niveau d'accès qui autorise l'ID client OAuth 2.0 utilisé par Gemini Enterprise, combiné au niveau d'accès basé sur l'adresse IP en tant que condition OR. Les demandes refusées s'affichent dans les journaux d'audit de votre organisation pour contextawareaccess.googleapis.com.
  • Résolution DNS : assurez-vous que vos résolveurs DNS résolvent correctement les domaines Google, y compris *.google.com et *.googleapis.com.

Collecter des informations de diagnostic

Si l'erreur persiste, capturez un fichier HAR (HTTP Archive) et les journaux de la console du navigateur pendant que vous reproduisez l'erreur, puis contactez le Cloud Customer Care. Les fichiers HAR peuvent contenir des informations sensibles, comme des cookies et des jetons.

Étape suivante