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é et un ID, plutôt que par leur adresse e-mail. Cet ID est appelé 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 électronique principale de l'utilisateur dans l'annuaire cloud ou G Suite.
  • Le dépôt définit des groupes de contrôle d'accès qui ne correspondent pas aux groupes de messagerie dans G Suite.

Les sources d'identité améliorent l'efficacité de l'indexation en dissociant l'indexation et le mappage d'identité. Grâce à cette dissociation, vous n'êtes plus contraint de rechercher l'utilisateur au moment de créer des LCA et d'indexer des éléments.

Exemple de déploiement

Dans le déploiement illustré dans la figure 1, l'entreprise utilise des dépôts sur site et dans le cloud. Chaque dépôt utilise un type d'ID externe différent pour identifier les utilisateurs.

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

Le dépôt 1 identifie l'utilisateur avec l'adresse e-mail déclarée à l'aide du protocole SAML. Comme le dépôt 1 connaît l'adresse e-mail principale de l'utilisateur dans l'annuaire cloud ou G Suite, il est inutile d'utiliser une source d'identité.

Le dépôt 2 est directement intégré à un dépôt sur site et identifie l'utilisateur par son attribut sAMAccountName. Comme le dépôt 2 utilise un attribut sAMAccountName en tant qu'ID externe, il est nécessaire d'utiliser 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.

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 les données. Rappelons que la création d'une source d'identité entraîne l'ajout d'une propriété utilisateur personnalisée dans l'annuaire cloud. Utilisez cette propriété pour enregistrer l'ID externe de chaque utilisateur de votre dépôt. Le nom de la propriété suit le format ci-dessous :

IDENTITY_SOURCE_ID_identity
.

Le tableau suivant contient deux sources d'identité : une qui traite les noms de compte SAM (sAMAccountName) comme ID externes et l'autre qui traite 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 associé à un utilisateur de votre entreprise.

Dans cet autre exemple, l'utilisateur dispose d'un compte Google et de deux ID externes (id1_identity et id2_identity). Le tableau montre comment leurs valeurs apparaissent dans les services d'annuaire Google :

Utilisateur Adresse e-mail id1_identity id2_identity
Anne anne@exemple.com exemple\anne 1001

Lors de l'établissement de LCA pour l'indexation, vous pouvez utiliser ces trois ID (adresse e-mail Google, sAMAccountName et uid) pour identifier un même utilisateur.

Rédiger des LCA utilisateur

Utilisez les méthodes getUserPrincipal() ou getGroupPrincipal() pour créer des principaux à partir d'un ID externe fourni.

L'exemple ci-dessous indique comment obtenir les données relatives aux autorisations des fichiers. Ces autorisations contiennent le nom de chaque utilisateur pouvant accéder 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();
  // ...
}

L'extrait de code suivant montre comment créer des comptes principaux qui sont propriétaires des fichiers en utilisant l'ID externe (externalUserName) enregistré dans les attributs.

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)
);

Enfin, l'extrait de code suivant indique comment créer des comptes principaux qui sont autorisés à lire les fichiers.

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);
}

Après avoir 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();

Pour créer les ID des comptes principaux, l'API REST sous-jacente utilise le format :

identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID
Reprenons les tableaux précédents. Si vous créez une LCA avec l'ID id1_identity (SAMAccountName) d'Anne, vous obtiendrez l'ID suivant :

identitysources/id1_identity/users/example/ann

Pris dans son ensemble, cet ID utilisateur est qualifié d'ID intermédiaire, car il crée un lien entre l'ID externe et les ID Google enregistrés dans l'annuaire cloud de Google.

Pour obtenir plus d'informations sur les différents modèles de listes de contrôle d'accès utilisées dans un dépôt, consultez l'article LCA.

Mapper les groupes

Les sources d'identité servent également d'espaces de noms pour les groupes utilisés dans les listes de contrôle d'accès. Cette fonctionnalité d'espace de noms permet de créer et de 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 un groupe et en gérer les membres. Pour associer le groupe à une 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 indique comment créer un groupe avec l'API Cloud Identity Groups :

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

Pour créer une LCA de groupe, commencez par créer un compte principal de groupe à partir de l'ID externe fourni, en utilisant la méthode getGroupPrincipal(). Ensuite, compilez la LCA en utilisant la classe Acl.Builder comme suit :

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é

Bien qu'il soit possible d'utiliser des ID externes, aucunement liés à Google, pour créer des listes de contrôle d'accès et indexer des éléments, les utilisateurs ne peuvent pas voir les éléments d'une recherche tant que leurs ID externes ne sont pas associés à un ID Google dans les services d'annuaire Google. Il existe trois façons de s'assurer que les services d'annuaire Google reconnaissent à la fois l'ID Google et les ID externes d'un utilisateur :

Les connecteurs d'identité sont des programmes utilisés pour mapper des ID externes entre les identités d'entreprise (utilisateurs et groupes) et les identités Google internes utilisées par Google Cloud Search. Vous ne pouvez créer de source d'identité sans créer de connecteur d'identité.

Google Cloud Directory Sync (GCDS), par exemple, est un connecteur d'identité. Ce dernier fait correspondre les informations concernant les utilisateurs et les groupes enregistrées dans Microsoft Active Directory avec celles de l'annuaire cloud, ainsi que les attributs de l'utilisateur qui peuvent être employés par d'autres systèmes pour l'identifier.