Externe Identitäten zuordnen

Unternehmen verwalten Identitäten (Nutzer und Nutzergruppen) in der Regel über einen Identitätsanbieter (IDP). Bei benutzerdefinierten Anwendungen, die ein Unternehmen intern entwickelt hat, können Kunden jedoch neue Nutzergruppen erstellen, die lokal in dieser Anwendung definiert sind. Diese anwendungsspezifischen Nutzergruppen oder sekundären Nutzer-IDs werden als externe Identitäten bezeichnet.

Warum sollte ich die Identitätszuweisung einrichten?

Damit Google die Zugriffssteuerung korrekt erzwingen kann, müssen Sie Ihre IDP-Identitäten den externen Identitäten aus den benutzerdefinierten Anwendungen zuordnen, die Sie mit Gemini Enterprise verwenden möchten.

Um die Zugriffssteuerung auf App-Ergebnisse anzuwenden, verwendet Google den IDP als „Source of Truth“, um zu bestimmen, auf welche Daten Ihre Nutzer Zugriff haben. Unternehmen verbinden ihren IdP häufig mit anderen SaaS-Lösungen, damit sich Mitarbeiter mit einem einzigen Satz von Unternehmensanmeldedaten anmelden und auf alle Unternehmensressourcen zugreifen können.

Wenn Sie externe Identitäten über Anwendungen definiert haben, die Sie mit Ihrer Anwendung verbinden möchten, z. B. benutzerdefinierte Anwendungen, ist Ihr IdP nicht die einzige „Source of Truth“ für die Zugriffssteuerung.

Angenommen, „JaneDoe“ ist in der Beispielorganisation mit der Domain „example.com“ vorhanden. Die ID im IdP ist als „JaneDoe@example.com“ definiert. Derselbe Nutzer hat in einer benutzerdefinierten Anwendung eine separate ID als „JDoe“. Der IDP kennt diese ID möglicherweise nicht. Daher erhält Gemini Enterprise keine Informationen zu den benutzerdefinierten Anwendungs-IDs über den IDP.

In Gemini Enterprise werden Identitätszuweisungen in einem Identitätszuweisungsspeicher gespeichert, den Sie erstellen und in den Sie die Zuweisungen importieren. Wenn Sie einen benutzerdefinierten Connector verwenden möchten, können Sie den Identitätszuweisungsspeicher an den Datenspeicher des benutzerdefinierten Connectors binden und dann die ACL-Metadaten Ihres Datenspeichers mit Informationen zu Ihren externen Identitäten aktualisieren.

Hinweis

Bevor Sie die Identitätszuweisung einrichten, müssen Sie Ihren Identitätsanbieter mit Ihrem Google Cloud -Projekt verbinden.

Einträge für die Identitätszuweisung vorbereiten

Bereiten Sie die Identitätszuweisungseinträge für den Import vor. Identitätszuweisungen sollten wie im folgenden Beispiel formatiert sein:

{
  "identity_mapping_entries": [
    {
      "external_identity": "u1",
      "user_id": "user1@example.com"
    },
    {
      "external_identity": "u2",
      "user_id": "user2@example.com"
    },
    {
      "external_identity": "gABC",
      "group_id": "groupABC@example.com"
    }
  ]
}

Das folgende Diagramm zeigt beispielsweise eine Nutzergruppenmitgliedschaft, wobei Ext externe Gruppen darstellt. Dieses Diagramm zeigt ein Beispiel für die Beziehung zwischen externen Gruppen und IdP-Nutzern und ‑Gruppen.

Beziehung zwischen externen Identitäten und IDP-Nutzern und ‑Gruppen.

Diese Grafik zur Mitgliedschaft in Nutzergruppen hätte die folgende Zuordnung:

{
  "identity_mapping_entries": [
    {
      "external_identity": "Ext1",
      "user_id": "IDPUser1@example.com"
    },
    {
      "external_identity": "Ext2",
      "user_id": "IDPUser1@example.com"
    },
    {
      "external_identity": "Ext2",
      "user_id": "IDPUser2@example.com"
    },
    {
      "external_identity": "Ext3",
      "user_id": "IDPUser2@example.com"
    },
    {
      "external_identity": "Ext3",
      "group_id": "IDPGroup1@example.com"
    },
    {
      "external_identity": "Ext3",
      "group_id": "IDPGroup2@example.com"
    }
  ]
}

Verschachtelte Identitätsmitgliedschaften, bei denen externe Identitäten untergeordnete Identitäten haben, müssen vereinfacht werden.

Google geht davon aus, dass der Connector eine primäre ID für eine externe Identität sendet. Importieren Sie beispielsweise die Gruppen-ID anstelle des Gruppennamens, da sich der Name im Laufe der Lebensdauer der Gruppe innerhalb der benutzerdefinierten Anwendung ändern kann.

Identitätszuweisung einrichten

Gehen Sie folgendermaßen vor, um die Identitätszuweisung in Gemini Enterprise zwischen Ihrem IdP und Ihren externen Identitäten einzurichten. In den folgenden Schritten erstellen Sie einen Identitätszuweisungsspeicher und importieren die vorbereiteten Identitätszuweisungen. Wenn Sie einen benutzerdefinierten Connector verwenden möchten, erstellen Sie auch einen neuen Datenspeicher, der an den Identitätszuweisungsspeicher gebunden ist.

Identitätszuweisungsspeicher erstellen

Der erste Schritt besteht darin, einen Identitätszuweisungsspeicher einzurichten. Dies ist die übergeordnete Ressource, in der alle Identitätszuweisungen gespeichert werden.

Wenn Sie den Identitätszuweisungsspeicher erstellen, wird die IDP-Konfiguration automatisch vom IDP abgerufen, den Sie mit Ihrem Gemini Enterprise-Projekt verbunden haben.

  1. Führen Sie den folgenden Befehl mit der Methode identityMappingStores.create aus, um einen Identitätszuweisungsspeicher zu erstellen:

    curl -X POST \
    -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
    -H "Content-Type: application/json" \
    -H "X-Goog-User-Project: PROJECT_ID" \
    "https://discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/global/identityMappingStores?identityMappingStoreId=IDENTITY_MAPPING_STORE_ID" \
    -d '{
      "name": "projects/PROJECT_ID/locations/global/identityMappingStores/IDENTITY_MAPPING_STORE_ID"
    }'
    

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Projekt-ID.
    • IDENTITY_MAPPING_STORE_ID: die eindeutige ID für den Identitätszuweisungsspeicher. Beispiel: test-id-mapping-store

Identitätszuweisungen importieren

Nachdem Sie den Identitätszuweisungsspeicher erstellt haben, importieren Sie die vorbereiteten Identitätszuweisungseinträge. Sie können Identitätszuweisungen über eine Inline-Quelle (Option 1) oder aus Cloud Storage (Option 2) importieren.

Beim Importieren aus Cloud Storage gelten die folgenden Formate und Einschränkungen:

  • Zulässige Formate: Die Eingabedateien müssen im NDJSON- (.ndjson) oder JSON Lines-Format (.jsonl) vorliegen, wobei jede Zeile einen einzelnen Identitätszuordnungseintrag darstellt.
  • Einschränkungen bei der Dateigröße: Jede Datei darf maximal 2 GB groß sein.
  • Einschränkungen für die Anzahl der Identitätszuweisungen: Sie können in einem Importvorgang bis zu 500,000 externe Identitätszuweisungen importieren.
  • Einschränkungen für die Anzahl der Dateien: Sie können in der Liste inputUris bis zu 2,000 Dateien angeben. Wenn Sie Platzhalter verwenden, gilt das Limit für die Gesamtzahl der Dateien nach der Platzhaltererweiterung.

Option 1: Import über Inline-Quelle

  1. Führen Sie den folgenden Befehl mit der Methode importIdentityMappings aus, um Ihre Identitätszuweisungen über eine Inline-Quelle zu importieren:

    curl -X POST \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" -H "x-goog-user-project: PROJECT_ID" \
    "https://ENDPOINT_LOCATION-discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/identityMappingStores/IDENTITY_MAPPING_STORE_ID:importIdentityMappings" \
    -d '{"inline_source" : IDENTITY_MAPPINGS_JSON}'
    

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Die Projekt-ID.
    • ENDPOINT_LOCATION: die Multiregion für Ihre API-Anfrage. Geben Sie einen der folgenden Werte an:
    • us für die Multiregion „USA“
    • eu für die Multiregion „EU“
    • global für den Standort „Global“
    Weitere Informationen zum Festlegen multiregionaler Standorte für Ihren Datenspeicher.
  2. LOCATION: die Multiregion Ihres Datenspeichers: global, us oder eu
  3. IDENTITY_MAPPING_STORE_ID: die eindeutige ID des Identitätszuweisungsspeichers.
  4. IDENTITY_MAPPINGS_JSON: die vorbereiteten Identitätszuweisungen im JSON-Format.
  5. Wenn Sie einen benutzerdefinierten Connector erstellen und externe Identitäten verwenden möchten, rufen Sie Benutzerdefinierte Datenspeicher an den Identitätszuweisungsspeicher binden auf. Fahren Sie andernfalls mit ACL-Metadaten aktualisieren fort.

Option 2: Aus Cloud Storage importieren

  1. Führen Sie den folgenden Befehl mit der Methode importIdentityMappings aus, um Ihre Identitätszuweisungen aus Cloud Storage zu importieren:

    curl -X POST \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" -H "x-goog-user-project: PROJECT_ID" \
    "https://ENDPOINT_LOCATION-discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/identityMappingStores/IDENTITY_MAPPING_STORE_ID:importIdentityMappings" \
    -d '{
      "gcsSource": {
        "inputUris": ["gs://BUCKET_NAME/FILE_PATH"]
      },
      "errorConfig": {
        "gcsPrefix": "gs://BUCKET_NAME/ERROR_DIR"
      },
      "reconciliationMode": "FULL"
    }'
    

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Die Projekt-ID.
    • ENDPOINT_LOCATION: die Multiregion für Ihre API-Anfrage. Geben Sie einen der folgenden Werte an:
    • us für die Multiregion „USA“
    • eu für die Multiregion „EU“
    • global für den Standort „Global“
    Weitere Informationen zum Festlegen multiregionaler Standorte für Ihren Datenspeicher.
  2. LOCATION: Der multiregionale Standort Ihres Datenspeichers: global, us oder eu.
  3. IDENTITY_MAPPING_STORE_ID: die eindeutige ID des Identitätszuweisungsspeichers.
  4. BUCKET_NAME: Der Name Ihres Cloud Storage-Buckets.
  5. FILE_PATH: der Pfad zu Ihrer Identitätszuweisungsdatei in Cloud Storage.
  6. ERROR_DIR: das Verzeichnis in Cloud Storage, in dem Fehlerlogs gespeichert werden.
  7. Wenn Sie einen benutzerdefinierten Connector erstellen und externe Identitäten verwenden möchten, rufen Sie Benutzerdefinierte Datenspeicher an den Identitätszuweisungsspeicher binden auf. Fahren Sie andernfalls mit ACL-Metadaten aktualisieren fort.

Benutzerdefinierte Datenspeicher an den Identitätszuweisungsspeicher binden

Dieses Verfahren ist nur erforderlich, wenn Sie einen benutzerdefinierten Connector erstellen. Wenn Sie keinen benutzerdefinierten Connector erstellen, überspringen Sie diesen Schritt.

Bei benutzerdefinierten Connectors muss der Identitätszuweisungsspeicher an den Datenspeicher gebunden werden, bevor eine externe Identität mit den zugehörigen Dokumenten verknüpft werden kann. Dieses Feld kann nur beim Erstellen des Datenspeichers festgelegt werden.

  1. Wenn Sie einen Datenspeicher an den Identitätszuordnungsspeicher binden möchten, geben Sie beim Erstellen des Datenspeichers mit der Methode Datastores.create identity_mapping_store an.

    curl -X POST \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json"  \
    -H "X-Goog-User-Project: PROJECT_ID" \
    "https://discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/global/collections/default_collection/dataStores?dataStoreId=DATA_STORE_ID \
    -d '{
        ...
        "identity_mapping_store": "IDENTITY_MAPPING_STORE_NAME"
    }'
    

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Die Projekt-ID.
    • DATA_STORE_ID: Die ID des Datenspeichers, der erstellt werden soll. Diese ID darf nur Kleinbuchstaben, Ziffern, Unterstriche und Bindestriche enthalten.
    • IDENTITY_MAPPING_STORE_NAME: Der vollständige Ressourcenname des Identitätszuweisungsspeichers. Beispiel: projects/exampleproject/locations/global/identityMappingStores/test-id-mapping-store Nachdem Sie einen Datenspeicher erstellt haben, kann dieser Name nicht mehr aktualisiert werden.

ACL-Metadaten hinzufügen

Fügen Sie ACL-Metadaten in das Objekt AclInfo für Ihre Dokumente ein.

Wenn ein Nutzer eine Suchanfrage sendet und Dokumente abgerufen werden, deren ACL-Metadaten externe Identitäten enthalten, werden diese externen Identitäten ausgewertet. Wenn die Identität des Nutzers (groupID oder userID) einer externen Identität (externalEntityId) zugeordnet ist, die mit einem Dokument verknüpft ist, erhält der Nutzer Zugriff auf dieses Dokument.

Angenommen, Sie haben einen benutzerdefinierten Connector für Jira erstellt. Ein bestimmter Jira-Vorgang ist für bestimmte IDP-Nutzer, bestimmte IDP-Gruppen und eine Administratorrolle zugänglich. Damit diese Personen in den Suchergebnissen auf das Problem zugreifen können, können Sie einen Identitätszuweisungsspeicher erstellen und IdP-Nutzer und -Gruppen Jira-spezifischen externen Identitäten zuordnen. Binden Sie den Identitätszuweisungsspeicher an Ihren Jira-Datenspeicher. Erstellen Sie dann Dokumente in Ihren Jira-Datenspeichern, wobei aclInfo mit den IDP-Nutzern, IDP-Gruppen und externen Identitäten konfiguriert ist, die Zugriff auf diese Dokumente haben sollen.

Wenn Sie Ihre ACL-Metadaten mit Informationen zu Ihren externen Identitäten aktualisieren möchten, verwenden Sie das folgende Format, um die externen Identitäten und die zugehörigen Nutzer- und Gruppen-IDs anzugeben.

{
  "aclInfo": {
    "readers": [
      {
        "principals": [
          {
            "groupId": "group_1"
          },
          {
            "userId": "user_1"
          },
          {
            "externalEntityId": "external_id1"
          }

        ]
      }
    ]
  }
}

Weitere Informationen zum Aktualisieren von ACL-Metadaten finden Sie unter Datenquelle mit Zugriffssteuerung konfigurieren.

Identitätszuweisungen verwalten

Sie können Identitätszuweisungen in einem Identitätsspeicher auflisten oder einen Identitätsspeicher löschen, indem Sie sie über eine Inline-Quelle oder mithilfe einer Filterbedingung definieren.

Für die Identitätszuweisung sind folgende Verwaltungsaufgaben verfügbar:

Identitätszuweisungen auflisten

  1. Führen Sie den folgenden Befehl mit der Methode listIdentityMappings aus, um Identitätszuweisungen aufzulisten:

    curl -X GET \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H  "Content-Type: application/json" \
    -H "x-goog-user-project: PROJECT_ID" \
    "https://discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/global/identityMappingStores/IDENTITY_MAPPING_STORE_ID:listIdentityMappings?page_size=PAGE_SIZE&page_token=PAGE_TOKEN"
    

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Projekt-ID.
    • PAGE_SIZE: Die maximale Anzahl von Identitätszuweisungsspeichern, die zurückgegeben werden sollen. Wenn sie nicht angegeben ist, wird sie standardmäßig auf 100 gesetzt. Der maximal zulässige Wert beträgt 1.000. Werte über 1.000 werden implizit auf 1.000 umgewandelt.
    • PAGE_TOKEN: Ein Seitentoken, das von einem vorherigen ListIdentityMappingStores-Aufruf empfangen wurde. Geben Sie diese an, um die nachfolgende Seite abzurufen.

Mit Inline-Quelle löschen

Sie können bestimmte Einträge aus einem Identitätszuweisungsspeicher dauerhaft löschen, indem Sie eine JSON-Datei mit den zu löschenden Identitäten angeben.

  1. Führen Sie den folgenden Befehl mit der Methode purgeIdentityMappings aus, um Identitätszuweisungen mithilfe einer Inline-Quelle dauerhaft zu löschen:

    curl -X POST \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    -H "x-goog-user-project: PROJECT_ID" \
    "https://discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/global/identityMappingStores/IDENTITY_MAPPING_STORE_ID:purgeIdentityMappings" \
    -d '{"inline_source" : IDENTITY_MAPPINGS_JSON}'
    

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Projekt-ID.
    • IDENTITY_MAPPING_STORE_ID: die eindeutige ID des Identitätszuweisungsspeichers.
    • IDENTITY_MAPPING_STORE_NAME: Der Name des Identitätszuweisungsspeichers.
    • IDENTITY_MAPPINGS_JSON: die Identitätszuweisungen, die dauerhaft gelöscht werden sollen.

Mit einer Filterbedingung dauerhaft löschen

Sie können bestimmte Einträge aus einem Identitätszuweisungsspeicher dauerhaft löschen, indem Sie nach Einträgen nach Aktualisierungszeit, externer Identität oder allen Einträgen filtern.

  1. Wenn Sie Identitätszuweisungen mithilfe einer Filterbedingung dauerhaft löschen möchten, führen Sie den folgenden Befehl mit der Methode purgeIdentityMappings aus:

    curl -X POST \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    -H "x-goog-user-project: PROJECT_ID" \
    "https://discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/global/identityMappingStores/IDENTITY_MAPPING_STORE_ID:purgeIdentityMappings" \
    -d '{"identity_mapping_store":"IDENTITY_MAPPING_STORE_NAME", "filter": "FILTER_CONDITION"}'
    

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Projekt-ID.
    • IDENTITY_MAPPING_STORE_ID: die eindeutige ID des Identitätszuweisungsspeichers.
    • IDENTITY_MAPPING_STORE_NAME: Der Name des Identitätszuweisungsspeichers.
    • FILTER_CONDITION: einer der folgenden Filtertypen:
      • Aktualisierungszeitpunkt. Beispiel: update_time > "2012-04-23T18:25:43.511Z" AND update_time < "2012-04-23T18:30:43.511Z">
      • Externe Identität. Beispiel: external_id = "id1"
      • Alle Identitätszuweisungen. Beispiel: *

Identitätszuweisungsspeicher verwalten

Sie können Identitätszuweisungsspeicher abrufen, löschen, auflisten und endgültig löschen.

Identitätszuweisungsspeicher abrufen

  1. Führen Sie den folgenden Befehl mit der Methode identityMappingStores.get aus, um einen Identitätszuweisungsspeicher abzurufen:

    curl -X GET \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    -H "X-Goog-User-Project: PROJECT_ID" \
    "https://discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/global/identityMappingStores/IDENTITY_MAPPING_STORE_ID"
    

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Projekt-ID.
    • IDENTITY_MAPPING_STORE_ID: die eindeutige ID des Identitätszuweisungsspeichers.
    • IDENTITY_MAPPING_STORE_NAME: Der Name des Identitätszuweisungsspeichers.

Identitätszuweisungsspeicher auflisten

  1. Führen Sie den folgenden Befehl mit der Methode identityMappingStores.list aus, um Identitätszuweisungsspeicher aufzulisten:

    curl -X GET \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H  "Content-Type: application/json" \
    -H "x-goog-user-project: PROJECT_ID" \
    "https://discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/global/identityMappingStores?page_size=PAGE_SIZE&page_token=PAGE_TOKEN"
    

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Projekt-ID.
    • PAGE_SIZE: Die maximale Anzahl von Identitätszuweisungsspeichern, die zurückgegeben werden sollen. Wenn sie nicht angegeben ist, wird sie standardmäßig auf 100 gesetzt. Der maximal zulässige Wert beträgt 1.000. Werte über 1.000 werden implizit auf 1.000 umgewandelt.
    • PAGE_TOKEN: Ein Seitentoken, das von einem vorherigen ListIdentityMappingStores-Aufruf empfangen wurde. Geben Sie diese an, um die nachfolgende Seite abzurufen.

Identitätszuweisungsspeicher löschen

Wenn Sie einen Identitätszuweisungsspeicher löschen möchten, darf er nicht an einen Datenspeicher gebunden sein und es dürfen keine Identitätszuweisungen im Identitätszuweisungsspeicher vorhanden sein.

  1. Führen Sie den folgenden Befehl mit der Methode identityMappingStores.delete aus, um einen Identitätszuweisungsspeicher zu löschen:

    curl -X DELETE \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    -H "X-Goog-User-Project: PROJECT_ID" \
    "https://discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/global/identityMappingStores/IDENTITY_MAPPING_STORE_ID"
    

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Projekt-ID.
    • IDENTITY_MAPPING_STORE_ID: die eindeutige ID des Identitätszuweisungsspeichers.
    • IDENTITY_MAPPING_STORE_NAME: Der Name des Identitätszuweisungsspeichers.