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 Lorsque vous connectez Gemini Enterprise à des sources de données Google Workspace, vous devez utiliser Google Identity.

Avant de configurer l'identité Google, vous devez déterminer 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 ne connectez Gemini Enterprise qu'à 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, Active Directory Federation Services (AD FS), Okta et d'autres, vous devez utiliser la fédération des identités des employés. 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, vous devez déterminer les attributs utilisateur uniques utilisés par votre organisation. Ces attributs doivent être mappés avec la fédération des identités des employés.

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 NotebookLM. 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 d'autres identifiants uniques, 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'ID de nom SAML pour identifier de manière unique les utilisateurs.

    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 des identités des employés, 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 Discovery Engine (roles/discoveryengine.user) 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 d'identité du personnel, 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 data store :

Type de modification Nécessite de recréer le data store
Passer de l'identité Google à un fournisseur d'identité tiers Oui
Passer complètement à un 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 des identités des employés. Par exemple, en utilisant Entra au lieu d'Okta. Non

Étape suivante