Mapper les LCA

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Pour vous assurer que seuls les utilisateurs ayant accès à un élément peuvent voir cet élément dans un résultat de recherche, vous devez indexer les éléments de leur liste de contrôle d'accès (LCA) à partir du dépôt de l'entreprise. Vous devez modéliser les LCA de votre dépôt et les inclure dans l'indexation des éléments du dépôt. Le SDK Content Connector fournit un ensemble complet de méthodes LCA suffisamment performantes pour modéliser les LCA de la plupart des dépôts.

Créer une LCA

Vous pouvez créer une LCA en deux étapes:

  1. Créez un Principal à l'aide de méthodes statiques dans la classe ACL.
  2. Utilisez la classe Acl.Builder pour créer la LCA à l'aide du compte principal.

Le reste de ce document aborde des concepts que vous devez connaître pour créer et créer des LCA, telles que l'héritage et la confinement.

Créer un compte principal à l'aide d'un ID externe

Google Cloud Search exige que les utilisateurs et les groupes utilisent l'adresse e-mail Google. Lors de l'indexation des éléments du dépôt, les connecteurs de contenu peuvent ne pas disposer de ces adresses e-mail. Avec le SDK Content Connector, vous pouvez utiliser un ID externe (ID donnant accès à des éléments du dépôt à un utilisateur ou un groupe), plutôt qu'une adresse e-mail, pour indexer un élément. Utilisez la méthode getUserPrincipal() ou getGroupPrincpal() pour créer des comptes principaux contenant des ID externes. Plusieurs classes statiques sont utilisées dans la classe ACL pour créer des objets Principal.

Héritage des LCA

L'héritage des LCA désigne l'autorisation pour un élément et un utilisateur spécifiques, en fonction des résultats des combinaisons de LCA de l'élément et des LCA de sa chaîne d'héritage. Les règles utilisées pour prendre une décision d'autorisation dépendent du dépôt et des propriétés de l'élément.

Définir les paramètres d'héritage

Chaque élément peut avoir des comptes principaux autorisés et des comptes principaux refusés directement, spécifiés à l'aide des méthodes setReaders() et setDeniedReaders(). Un compte principal direct autorisé est un compte utilisateur identifié dans une liste de contrôle d'accès qui lui donne un accès direct à un élément spécifique. Un compte principal refusé direct désigne un utilisateur identifié dans une LCA comme n'ayant pas accès à un élément spécifique.

Un élément peut également hériter des comptes principaux autorisés indirectement et des comptes principaux refusés indirectement à l'aide de la méthode setInheritFrom(). Un compte principal autorisé indirect est un utilisateur disposant, via l'héritage LCA, d'un accès indirect à un élément spécifique. Un compte principal refusé indirect est un utilisateur qui n'a pas accès à un élément spécifique via l'héritage de la LCA.

La figure 1 montre comment la méthode setInheritFrom() est utilisée pour hériter des comptes principaux indirects autorisés et refusés indirectement.

Dessin des connexions entre les éléments
Figure 1 La méthode setInheritFrom().

Ces contrôles d'accès sont représentés dans la figure 1:

  • L'utilisateur 1 est un compte principal autorisé direct de l'élément A.
  • L'utilisateur 2 est un compte principal autorisé direct de l'élément B.
  • L'élément B hérite de la LCA de l'élément A.

Les règles d'accès sont basées sur les contrôles d'accès suivants:

  • L'utilisateur 1 n'a pas besoin d'être explicitement indiqué comme compte principal de l'élément B pour être un compte principal autorisé indirect de l'élément B. L'accès est hérité, car l'utilisateur 1 est répertorié comme compte principal autorisé direct de l'élément A. En outre, l'élément B hérite de sa LCA de l'élément A.
  • L'utilisateur 2 n'est pas un compte principal autorisé indirect pour l'élément A.

Définir le type d'héritage

Si vous définissez l'héritage avec la méthode setInheritFrom(), vous devez le définir à l'aide de la méthode setInheritanceType(). Le type d'héritage détermine la façon dont une LCA d'enfant est associée à la LCA de son parent. Le Acl.InheritanceType implémente trois types d'héritage:

  • BOTH_PERMIT : définissez le type d'héritage sur BOTH_PERMIT pour permettre à l'utilisateur d'accéder à l'élément uniquement lorsque la LCA de l'élément enfant et celle de l'élément hérité de parent à l'élément sont autorisées.

  • CHILD_OVERRIDE : définissez le type d'héritage sur CHILD_OVERRIDE pour que l'élément enfant de la LCA prévaut sur celui de l'élément parent hérité en cas de conflit. Ainsi, si la LCA de l'élément parent refuse l'accès à l'utilisateur en tant que lecteur refusé, il peut toujours accéder à l'élément enfant en tant que lecteur. Inversement, même si la LCA de l'élément parent accorde l'accès à l'utilisateur, celui-ci n'y a pas accès s'il refuse l'accès à l'enfant.

  • PARENT_OVERRIDE : définissez le type d'héritage sur PARENT_OVERRIDE pour que la LCA de l'élément parent soit prioritaire sur celle de l'élément enfant en cas de conflit. Ainsi, si la LCA de l'élément enfant refuse l'accès à l'utilisateur en tant que lecteur refusé, l'utilisateur peut tout de même accéder à l'élément parent en tant que lecteur. Inversement, même si la LCA de l'élément enfant accorde l'accès à l'utilisateur, celui-ci n'a pas accès s'il refuse l'accès à l'élément parent.

Lors de l'évaluation d'une chaîne d'héritage de LCA, l'ordre d'évaluation peut modifier le résultat de la décision d'autorisation. Cloud Search fournit un ordre d'évaluation feuille à la racine pour les chaînes d'héritage des LCA. Plus précisément, la décision de LCA pour une chaîne commence par l'évaluation d'un enfant avec ses parents et peut progresser jusqu'à son parent racine.

Par exemple, si l'enfant possède le type d'héritage CHILD_OVERRIDE et que l'utilisateur a accès à l'enfant, Drive n'a pas besoin d'évaluer le parent. Toutefois, si l'enfant possède PARENT_OVERRIDE ou BOTH_PERMIT, Drive continue à évaluer l'héritage dans la suite de la chaîne.

Confinement et suppression d'éléments

Lors de l'indexation d'un élément, vous pouvez lui attribuer un libellé en tant que conteneur à l'aide de la méthode setContainer() de la classe IndexingItemBuilder. La relation conteneur/contrainte établit la hiérarchie physique des éléments et garantit que les éléments sont correctement supprimés. Lorsqu'un conteneur est supprimé, les éléments qu'il contient sont également supprimés.

Les relations de confinement sont entièrement indépendantes des règles d'héritage des LCA. Par exemple, un fichier d'un système de fichiers peut contenir un dossier à supprimer, mais hériter de la LCA d'un autre dossier. La suppression d'un dossier ne supprime pas les éléments qui héritent de sa LCA, sauf s'ils se trouvent également dans la hiérarchie de conteneur du dossier.

Les contrôles d'accès sont représentés dans la figure 2:

  • L'utilisateur 1 est un compte principal autorisé direct de l'élément A.
  • L'utilisateur 2 est un compte principal autorisé direct de l'élément B.
  • L'utilisateur 3 est un compte principal autorisé direct de l'élément C.
  • L'élément C hérite de la LCA de l'élément A.
  • L'élément B nomme l'élément A comme son conteneur.
  • L'élément C nomme l'élément B comme son conteneur.

Les règles d'accès sont basées sur les contrôles d'accès suivants:

  • L'accès indirect provient de la méthode setInheritFrom(). Par conséquent, l'utilisateur 1 peut accéder à l'élément C, car celui-ci hérite de la LCA de l'élément A.
  • L'accès indirect ne provient pas de l'élément C contenu dans l'élément B. Par conséquent, l'utilisateur 2 ne peut pas accéder à l'élément C.
Dessin des connexions entre les éléments
Figure 2. Méthode setInheritFrom() utilisée

La séparation de l'héritage des LCA et de la hiérarchie de confinement vous permet de modéliser de nombreuses structures existantes.

Lorsqu'un élément est supprimé avec succès:

  • Tout élément qui comportait un élément supprimé n'est plus inclus dans l'index de recherche et doit être supprimé de la source de données de Google.
  • Tout élément qui a spécifié l'élément supprimé à l'aide de la méthode setInheritFrom() ne peut plus faire l'objet d'une recherche.

Si une ressource comporte un élément supprimé à l'aide de la méthode setInheritFrom(), mais qu'aucun conteneur n'est défini avec setContainer() ou que sa hiérarchie de confinement ne contient aucun élément supprimé, cet élément et ses données restent dans la source de données de Google. Vous êtes responsable de la suppression de cet élément.

La figure 3 illustre la façon dont la suppression fonctionne pour une hiérarchie d'éléments.

Dessin des connexions entre les éléments
Figure 3. Suppression d'un élément et héritage de la LCA

Ces contrôles d'accès sont représentés dans la figure 3:

  • L'utilisateur 1 est un compte principal autorisé direct de l'élément A.
  • L'utilisateur 2 est un compte principal autorisé direct de l'élément D.
  • Les éléments D et E héritent tous deux de la LCA de l'élément A.
  • L'élément D désigne l'élément A comme son conteneur.
  • Les éléments A et E sont des éléments de niveau racine, car ils n'ont pas d'élément de conteneur.

Supprime les cascades d'annonces via les références de conteneur. Lorsque l'élément A est supprimé:

  • Tous les descendants de la référence setInheritFrom() perdent l'accès pour tous les utilisateurs.
  • Aucun utilisateur ne peut accéder à l'élément A.
  • L'élément D est implicitement supprimé. Aucun utilisateur ne peut accéder à l'élément D.
  • L'élément E n'est pas supprimé, car la suppression n'est effectuée qu'en cascade via les références de conteneurs.
  • L'élément E n'est plus accessible, et aucun utilisateur ne peut rechercher l'élément E.