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 listes de contrôle d'accès (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 vous êtes dans l'un des cas suivants :

  • 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 et le mappage d'identité. Vous pouvez ainsi 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 du protocole SAML. Comme il connaît l'adresse e-mail principale dans Google Workspace ou l'annuaire cloud, il n'a pas besoin de source d'identité.

Le dépôt 2 est intégré à un annuaire sur site et identifie les utilisateurs par sAMAccountName. Comme il utilise cet attribut comme 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 l'article 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 des données. La création d'une source d'identité entraîne également la création 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 présente 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.

Ce tableau montre comment un utilisateur disposant d'un compte Google et de deux ID externes apparaît dans l'annuaire cloud :

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 n'importe lequel 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 de fichier, y compris les utilisateurs ayant accès :

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, vous pouvez créer 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. id1_identity d'Ann 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 LCA. Utilisez-les 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 voient les éléments dans les résultats de recherche que lorsque leurs ID externes sont associés à un ID Google dans l'annuaire cloud. Vous pouvez vous en assurer de trois manières :

Les connecteurs d'identité mappent les ID externes des identités d'entreprise sur les 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) par exemple, est un connecteur d'identité. Il mappe les informations sur les utilisateurs et les groupes d'Active Directory sur l'annuaire cloud.

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

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

Remapper les identités

Après avoir remappé une identité, vous devez réindexer les éléments pour que la modification soit prise en compte.

  • 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 avec la même groupKey, l'accès ne sera accordé qu'après la réindexation.