Cette page a été traduite par l'API Cloud Translation.

Synchroniser différents systèmes d'identité

Dans Google Cloud Search, le contrôle des accès dépend du compte Google de l'utilisateur. Lors de l'indexation du contenu, toutes les LCA d'éléments doivent correspondre à des utilisateurs Google ou ID de groupe (adresses e-mail).

Bien souvent, un dépôt ne connaît pas directement Google Cloud. À la place, les utilisateurs peuvent être représentés par des comptes locaux ou utiliser connexion fédérée avec un fournisseur et un identifiant d'identité, que l'adresse e-mail de l'utilisateur, pour identifier chaque compte. Cet identifiant est appelé ID externe.

Créées dans la console d'administration, les sources d'identité permettent de combler l'écart entre des systèmes d'identité:

Définir un champ utilisateur personnalisé pour stocker des ID externes. Ce champ permet de résoudre les ID externes vers un compte Google Cloud.
Définissez un espace de noms pour les groupes de sécurité. gérés par un dépôt ou fournisseur d'identité.

Utilisez des sources d'identité dans les cas suivants:

Le référentiel n'a pas connaissance de l'adresse e-mail principale de l'utilisateur dans l'annuaire Google Workspace ou l'annuaire Google Cloud.
Pour le contrôle des accès, le dépôt définit des groupes qui ne correspondent pas aux groupes par e-mail dans Google Workspace.

Les sources d'identité améliorent l'efficacité de l'indexation en dissociant l'indexation à partir du mappage d'identité. Ce découplage vous permet de reporter la recherche de l'utilisateur lors de la création de LCA et de l'indexation d'éléments.

Exemple de déploiement

La figure 1 présente un exemple de déploiement dans lequel les environnements sur site et dans le cloud sont utilisés par une entreprise. Chaque dépôt utilise un type différent d'ID externe pour faire référence aux utilisateurs.

Le dépôt 1 identifie l'utilisateur à l'aide de l'adresse e-mail déclarée à l'aide de SAML : En effet, le dépôt 1 connaît l'adresse e-mail principale de l'utilisateur dans Google Workspace ou l'annuaire cloud, une source d'identité n'est pas nécessaire.

Le dépôt 2 s'intègre directement à un répertoire sur site identifie l'utilisateur par son attribut sAMAccountName. Comme le dépôt 2 utilise un attribut sAMAccountName comme ID externe, une source d'identité est nécessaires.

Créer une source d'identité

Si vous avez besoin d'une source d'identité, consultez Associer des identités d'utilisateur dans Cloud Search.

Vous devez créer une source d'identité avant de créer un connecteur de contenu, car vous aurez besoin de l'ID de la source d'identité pour créer des LCA et indexer des données. Comme indiqué précédemment précédemment, la création d'une source d'identité crée propriété utilisateur personnalisée dans l'annuaire cloud. Utilisez cette propriété pour enregistrer l'ID externe de chaque dans votre dépôt. Le nom de la propriété correspond à l'élément convention IDENTITY_SOURCE_ID_identity.

Le tableau suivant présente deux sources d'identité, l'une contenant les noms des comptes SAM (sAMAccountName) en tant qu'ID externes et un pour conserver les ID utilisateur (uid) en tant qu'ID externes.

Source d'identité	propriété utilisateur	ID externe
id1	id1_identity	sAMAccountName
id2	id2_identity	uid

Créez une source d'identité pour chaque ID externe possible utilisé pour se référer à un utilisateur de votre entreprise.

Le tableau suivant montre comment un utilisateur disposant d'un compte Google et de deux ID externes (id1_identity et id2_identity) et leurs valeurs apparaissent dans l'annuaire cloud:

utilisateur	e-mail	id1_identity	id2_identity
Anne	ann@example.com	exemple\anne	1001

Vous pouvez faire référence au même utilisateur à l'aide des trois identifiants différents, (adresse e-mail Google, sAMAccountName et uid) lors de la création de LCA pour l'indexation.

Écrire des LCA utilisateur

Utilisez le getUserPrincpal() ou la getGroupPrincipal() permettant de créer des comptes principaux à l'aide d'un ID externe fourni.

L'exemple suivant montre comment récupérer les autorisations de fichiers. Ces les autorisations incluent le nom de chaque utilisateur ayant accès au fichier.

FilePermissionSample.java

Afficher sur GitHub

/**
 * Sample for mapping permissions from a source repository to Cloud Search
 * ACLs. In this example, POSIX file permissions are used a the source
 * permissions.
 *
 * @return Acl
 * @throws IOException if unable to read file permissions
 */
static Acl mapPosixFilePermissionToCloudSearchAcl(Path pathToFile) throws IOException {
  // Id of the identity source for external user/group IDs. Shown here,
  // but may be omitted in the SDK as it is automatically applied
  // based on the `api.identitySourceId` configuration parameter.
  String identitySourceId = "abcdef12345";

  // Retrieve the file system permissions for the item being indexed.
  PosixFileAttributeView attributeView = Files.getFileAttributeView(
      pathToFile,
      PosixFileAttributeView.class,
      LinkOption.NOFOLLOW_LINKS);

  if (attributeView == null) {
    // Can't read, return empty ACl
    return new Acl.Builder().build();
  }

  PosixFileAttributes attrs = attributeView.readAttributes();
  // ...
}

L'extrait de code suivant montre comment créer des comptes principaux propriétaires à l'aide de l'ID externe (externalUserName) stocké dans les attributs.

FilePermissionSample.java

Afficher sur GitHub

// Owner, for search quality.
// Note that for principals the name is not the primary
// email address in Cloud Directory, but the local ID defined
// by the OS. Users and groups must be referred to by their
// external ID and mapped via an identity source.
List<Principal> owners = Collections.singletonList(
    Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId)
);

Enfin, l'extrait de code suivant montre comment créer des comptes principaux sont les lecteurs du fichier.

FilePermissionSample.java

Afficher sur GitHub

// List of users to grant access to
List<Principal> readers = new ArrayList<>();

// Add owner, group, others to readers list if permissions
// exist. For this example, other is mapped to everyone
// in the organization.
Set<PosixFilePermission> permissions = attrs.permissions();
if (permissions.contains(PosixFilePermission.OWNER_READ)) {
  readers.add(Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId));
}
if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}
if (permissions.contains(PosixFilePermission.OTHERS_READ)) {
  Principal everyone = Acl.getCustomerPrincipal();
  readers.add(everyone);
}

Une fois que vous disposez de la liste des lecteurs et des propriétaires, vous pouvez créer la LCA:

FilePermissionSample.java

Afficher sur GitHub

// Build the Cloud Search ACL. Note that inheritance of permissions
// from parents is omitted. See `setInheritFrom()` and `setInheritanceType()`
// methods on the builder if required by your implementation.
Acl acl = new Acl.Builder()
    .setReaders(readers)
    .setOwners(owners)
    .build();

L'API REST sous-jacente utilise le modèle identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID pour l'ID lors de la création des comptes principaux. Si nous reprenons les tableaux précédents, si vous créez une LCA avec le id1_identity d'Anne (SAMAccountName), l'ID correspond à:

identitysources/id1_identity/users/example/ann

Cet identifiant complet est appelé ID intermédiaire de l'utilisateur. car il permet de faire le lien entre l'ID externe et les ID Google stockés avec l'annuaire cloud.

Pour plus d'informations sur la modélisation des LCA utilisées pour un dépôt, consultez LCA.

Mapper les groupes

Les sources d'identité servent également d'espace de noms pour les groupes utilisés dans les LCA. Vous pouvez Utilisez cette fonctionnalité d'espace de noms pour créer et mapper des groupes utilisés pour la sécurité à des fins uniquement ou sont locales dans un dépôt.

Utiliser l'API Cloud Identity Groups pour créer un groupe et gérer les adhésions. Pour associer le groupe à un source d'identité, utilisez le nom de la ressource de la source d'identité comme espace de noms du groupe.

L'extrait de code suivant montre comment créer un groupe à l'aide du API Cloud Identity Groups:

CreateGroupCommand.java

Afficher sur GitHub

String namespace = "identitysources/" + idSource;
Group group = new Group()
    .setGroupKey(new EntityKey().setNamespace(namespace).setId(groupId))
    .setDescription("Demo group")
    .setDisplayName(groupName)
    .setLabels(Collections.singletonMap("system/groups/external", ""))
    .setParent(namespace);
try {
  CloudIdentity service = Utils.buildCloudIdentityService();
  Operation createOperation = service.groups().create(group).execute();

  if (createOperation.getDone()) {
    // Note: The response contains the data for a Group object, but as
    // individual fields. To convert to a Group instance, either populate
    // the fields individually or serialize & deserialize to/from JSON.
    //
    // Example:
    // String json = service.getJsonFactory().toString(response);
    // Group createdGroup =  service.getObjectParser()
    //     .parseAndClose(new StringReader(json), Group.class);
    System.out.printf("Group: %s\n",
        createOperation.getResponse().toString());
  } else {
    // Handle case where operation not yet complete, poll for
    // completion. API is currently synchronous and all operations return
    // as completed.
    // ...
  }
} catch (Exception e) {
  System.err.printf("Unable to create group: %s", e.getMessage());
  e.printStackTrace(System.err);
}

Créer une LCA de groupe

Pour créer une LCA de groupe, utilisez la méthode getGroupPrincipal() permettant de créer un compte principal de groupe à l'aide d'un ID externe fourni. Ensuite, créez le LCA à l'aide de la méthode Acl.Builder comme suit:

FilePermissionSample.java

Afficher sur GitHub

if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}

Connecteurs d'identité

Vous pouvez utiliser des ID externes non-Google pour créer des LCA et indexer des éléments, les utilisateurs ne peuvent voir les éléments d'une recherche que si leur ID externe est associé à un identifiant Google dans l'annuaire cloud. Il existe trois façons de vous assurer L'annuaire cloud connaît à la fois l'ID Google et les ID externes d'un utilisateur:

mettre à jour manuellement chaque profil utilisateur dans la console d'administration ; Ce processus n'est recommandé que pour les tests et le prototypage utilisant quelques profils utilisateur.
Mapper des ID externes avec des ID Google à l'aide de l'API Directory Cette procédure est recommandée si vous ne pouvez pas utiliser le SDK Identity Connector.
Créer un connecteur d'identité à l'aide du SDK Identity Connector : Ce SDK simplifie l'utilisation de l'API Directory pour mapper les ID.

Les connecteurs d'identité sont des programmes permettant de mapper les ID externes (utilisateurs et groupes) à des identités Google internes utilisées par Google Cloud Search. Si vous devez créer une source d'identité, vous devez créer un connecteur d'identité.

Google Cloud Directory Sync (GCDS) est un exemple de connecteur d'identité. Ce connecteur d'identité mappe les utilisateurs de regrouper les informations d'Active Directory de Microsoft vers Cloud Directory, avec les attributs utilisateur qui peuvent représenter son identité dans d'autres systèmes.

Synchroniser les identités à l'aide de l'API REST

Utilisez la méthode update pour synchroniser les identités à l'aide de l'API REST.

Remappage des identités

Après avoir remappé l'identité d'un élément avec une autre identité, vous devez réindexer les éléments. pour que la nouvelle identité s’applique. Par exemple,

si vous essayez de supprimer un mappage d'un utilisateur ou de le remapper à un autre utilisateur, le le mappage d'origine est conservé jusqu'à ce que vous le réindexiez.
Si vous supprimez un groupe mappé qui figure dans une LCA d'élément, puis que vous créez une nouveau groupe avec le même groupKey, le nouveau groupe ne fournit pas l'accès au l'élément jusqu'à ce qu'il soit réindexé.