Synchroniser différents systèmes d'identité

Dans Google Cloud Search, les accès sont contrôlés en fonction du compte Google des utilisateurs. Lors de l'indexation du contenu, toutes les LCA des éléments doivent être associées à des ID d'utilisateurs ou de groupes Google valides (adresses e-mail).

Souvent, les dépôts ne reconnaissent pas directement les comptes Google. car les utilisateurs passent par un compte local ou une connexion fédérée avec un fournisseur d'identité. Cette identification, autre que l'adresse e-mail, est appelée ID externe.

Afin de remédier à ces différences entre les systèmes d'identité, vous pouvez créer des sources d'identité dans la console d'administration. Pour ce faire :

Utilisez des sources d'identité si :

  • Le dépôt ne connaît pas l'adresse e-mail principale de l'utilisateur dans Google Workspace ou l'annuaire Google Cloud.
  • Le dépôt définit des groupes de contrôle d'accès qui ne correspondent pas aux groupes de messagerie dans Google Workspace.

Les sources d'identité améliorent l'efficacité en dissociant l'indexation du mappage d'identité. Cela vous permet de différer la recherche d'utilisateur lorsque vous créez des LCA et indexez des éléments.

Exemple de déploiement

La figure 1 montre une entreprise qui utilise des dépôts sur site et dans le cloud. Chacun utilise un type d'ID externe différent.

Exemple de déploiement où l'entreprise utilise différents types d'identité
Figure 1. Exemple de déploiement où l'entreprise utilise différents types d'identité.

Le dépôt 1 identifie les utilisateurs par adresse e-mail à l'aide de SAML. Comme il connaît l'adresse e-mail principale dans Google Workspace ou Cloud Directory, il n'a pas besoin de source d'identité.

Le dépôt 2 est intégré à un dépôt sur site et identifie les utilisateurs par sAMAccountName. Comme il utilise cet attribut en tant qu'ID externe, il nécessite une source d'identité.

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.

Créez la source d'identité avant de créer un connecteur de contenu. Vous aurez besoin de son ID pour créer des LCA et indexer les données. La création d'une source d'identité entraîne également l'ajout d'une propriété utilisateur personnalisée dans l'annuaire cloud pour stocker les ID externes. Le nom de la propriété suit la convention IDENTITY_SOURCE_ID_identity.

Ce tableau contient deux sources d'identité : une pour les noms de compte SAM et une pour les ID utilisateur (uid).

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

Créez une source d'identité pour chaque type d'ID externe utilisé dans votre entreprise.

Dans cet autre exemple, l'utilisateur dispose d'un compte Google et de deux ID externes. Le tableau montre comment leurs valeurs apparaissent dans Cloud Directory :

Utilisateur E-mail id1_identity id2_identity
Anne ann@example.com example\ann 1001

Lors de l'établissement de LCA pour l'indexation, vous pouvez utiliser l'un de ces ID pour identifier un même utilisateur.

Rédiger des LCA utilisateur

Utilisez getUserPrincipal() ou getGroupPrincipal() pour créer des comptes principaux à l'aide d'ID externes.

Cet exemple récupère les autorisations d'accès aux fichiers, y compris les utilisateurs ayant accès aux fichiers :

FilePermissionSample.java
/**
 * 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();
  // ...
}

Cet extrait crée des comptes principaux pour les propriétaires à l'aide de l'attribut externalUserName :

FilePermissionSample.java
// 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)
);

Cet extrait crée des comptes principaux pour les lecteurs :

FilePermissionSample.java
// 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 avez identifié les lecteurs et propriétaires des fichiers, créez la liste de contrôle d'accès :

FilePermissionSample.java
// 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 utilise le format identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID. Le id1_identity d'Anne est résolu en identitysources/id1_identity/users/example/ann. Il s'agit de l'ID intermédiaire de l'utilisateur.

Pour en savoir plus sur la modélisation des LCA de dépôt, consultez LCA.

Mapper les groupes

Les sources d'identité servent également d'espaces de noms pour les groupes de listes de contrôle d'accès. Utilisez cette fonctionnalité pour créer et mapper des groupes utilisés uniquement à des fins de sécurité ou des groupes locaux d'un dépôt.

Utilisez l'API Cloud Identity Groups pour créer des groupes et gérer les membres. Associez le groupe à une source d'identité en utilisant le nom de la source d'identité comme espace de noms.

Cet extrait crée un groupe :

CreateGroupCommand.java
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

Utilisez getGroupPrincipal() pour créer un compte principal de groupe avec un ID externe, puis créez la LCA :

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

Connecteurs d'identité

Les utilisateurs ne peuvent pas voir les éléments dans les résultats de recherche tant que leurs ID externes ne sont pas associés à un ID Google dans Cloud Directory. Pour ce faire, vous avez le choix entre trois méthodes :

Les connecteurs d'identité mappent les ID externes des identités d'entreprise aux identités Google internes. Si vous créez une source d'identité, vous devez également créer un connecteur d'identité.

Google Cloud Directory Sync (GCDS) est un exemple de connecteur d'identité. Il mappe les informations sur les utilisateurs et les groupes d'Active Directory vers Cloud Directory.

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

Utilisez la méthode update pour synchroniser les identités.

Remapper des identités

Après avoir remappé une identité, vous devez réindexer les éléments pour que la modification prenne effet.

  • Si vous supprimez ou modifiez un mappage utilisateur, le mappage d'origine reste en place jusqu'à la réindexation.
  • Si vous supprimez un groupe mappé et que vous en créez un autre avec le même groupKey, l'accès ne sera pas accordé tant que vous n'aurez pas réindexé.