Synchroniser différents systèmes d'identité

Le contrôle des accès dans Google Cloud Search est basé sur le compte Google de l'utilisateur. Lors de l'indexation du contenu, toutes les LCA associées aux éléments doivent correspondre à des ID d'utilisateur ou de groupe Google valides (adresses e-mail).

Dans de nombreux cas, le dépôt n'a pas de connaissance directe des comptes Google. À la place, les utilisateurs peuvent être représentés par des comptes locaux ou utiliser une connexion fédérée avec un fournisseur d'identité et un ID, autres que l'adresse e-mail de l'utilisateur, pour identifier chaque compte. Cet ID est appelé ID externe.

Créés à l'aide de la console d'administration, les sources d'identité permettent de combler cet écart entre les systèmes d'identité de plusieurs façons:

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

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

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

Exemple de déploiement

La figure 1 illustre un exemple de déploiement dans lequel une entreprise utilise à la fois des dépôts sur site et dans le cloud. Chaque dépôt utilise un type d'ID externe différent pour faire référence aux utilisateurs.

Exemple de déploiement
Figure 1 : Exemple de déploiement en entreprise avec différents types d'identité

Le dépôt 1 identifie l'utilisateur à l'aide de l'adresse e-mail déclarée à l'aide du protocole SAML. Étant donné que le dépôt 1 connaît l'adresse e-mail principale de l'utilisateur dans Google Workspace ou l'annuaire cloud, aucune source d'identité n'est nécessaire.

Le dépôt 2 s'intègre directement à un annuaire sur site et identifie l'utilisateur grâce à son attribut sAMAccountName. Étant donné que le dépôt 2 utilise un attribut sAMAccountName en tant qu'ID externe, une source d'identité est nécessaire.

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, 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. Utilisez cette propriété pour enregistrer l'ID externe de chaque utilisateur de votre dépôt. Le nom de la propriété est basé sur la convention IDENTITY_SOURCE_ID_identity.

Le tableau suivant présente deux sources d'identité, l'une pour stocker les noms de compte SAM (sAMAccountName) en tant qu'ID externes et l'autre pour stocker 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 pouvant être utilisé pour faire référence à 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), ainsi que leurs valeurs, apparaissent dans l'annuaire cloud:

utilisateur adresse email 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 différents ID (adresse e-mail Google, sAMAccountName et uid) lors de la création de LCA pour l'indexation.

Écrire des LCA utilisateur

Utilisez les méthodes getUserPrincpal() ou getGroupPrincipal() pour 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 autorisations incluent le nom de chaque utilisateur ayant accès au fichier.

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 à l'aide de l'ID externe (externalUserName) stocké 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 montre comment créer des comptes principaux qui peuvent lire le fichier.

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 disposez de la liste des lecteurs et des propriétaires, vous pouvez créer la LCA:

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 sous-jacente utilise le modèle identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID comme ID lors de la création des comptes principaux. Si vous créez une LCA avec le id1_identity d'Anne (SAMAccountName), l'ID se résout comme suit:

identitysources/id1_identity/users/example/ann

Cet ID complet est appelé ID intermédiaire de l'utilisateur, car il fournit un pont entre l'ID externe et les ID Google stockés dans l'annuaire cloud.

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

Mapper les groupes

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

Utilisez l'API Cloud Identity Groups pour créer un groupe et en gérer les adhésions. 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 montre comment créer un groupe à l'aide de 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, utilisez la méthode getGroupPrincipal() afin de créer un compte principal de groupe à l'aide d'un ID externe fourni. Compilez ensuite la LCA à l'aide de 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 que vous puissiez utiliser des ID externes autres que Google pour créer des LCA 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 l'annuaire cloud. Il existe trois façons de s'assurer que l'annuaire cloud connaît l'ID Google et les ID externes d'un utilisateur:

Les connecteurs d'identité sont des programmes permettant de mapper les ID externes des identités d'entreprise (utilisateurs et groupes) avec les identités Google internes utilisées par Google Cloud Search. Pour 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é fait correspondre les informations sur les utilisateurs et les groupes d'Active Directory de Microsoft avec l'annuaire Cloud, ainsi que les attributs utilisateur qui peuvent représenter leur 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 à une autre identité, vous devez réindexer les éléments pour que la nouvelle identité soit prise en compte. Par exemple,

  • Si vous essayez de supprimer le mappage d'un utilisateur ou de le remapper à un autre utilisateur, le mappage d'origine est conservé jusqu'à ce que vous le réindexiez.
  • Si vous supprimez un groupe mappé présent dans une LCA d'élément, puis que vous créez un groupe avec le même groupKey, le nouveau groupe ne donne pas accès à l'élément tant que celui-ci n'est pas réindexé.