Mapper les LCA

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

Créer une LCA

La création d'une LCA s'effectue en deux étapes:

1. Créez un Principal à l'aide des méthodes statiques de 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 certains concepts que vous devez connaître pour modéliser et créer des LCA, tels que l'héritage et le confinement.

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

Google Cloud Search exige que les utilisateurs et les groupes soient associés à une 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. Toutefois, le SDK Content Connector vous permet d'utiliser n'importe quel ID externe (ID accordant à un utilisateur ou à un groupe l'accès aux éléments du dépôt) au lieu d'une adresse e-mail pour indexer un élément. Utilisez les méthodes getUserPrincipal() ou getGroupPrincpal() pour créer des comptes principaux contenant des ID externes. Il existe plusieurs autres méthodes statiques dans la classe ACL qui permettent de créer des objets Principal.

Héritage des LCA

L'héritage des LCA fait référence à l'autorisation, pour un élément et un utilisateur spécifiques, en fonction du résultat d'une combinaison des LCA de l'élément et de celles 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 l'héritage

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

Un élément peut également hériter de comptes principaux autorisés indirects et de comptes principaux refusés indirects à l'aide de la méthode setInheritFrom(). Un compte principal autorisé indirect est un utilisateur qui, grâce à l'héritage des LCA, dispose d'un accès indirect à un élément spécifique. Un compte principal refusé indirect est un utilisateur qui se voit refuser l'accès à un élément spécifique par le biais de l'héritage des LCA.

La figure 1 montre comment la méthode setInheritFrom() permet d'hériter des comptes principaux autorisés et refusés indirects.

Les contrôles d'accès suivants 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.

Voici les règles d'accès basées sur les contrôles d'accès:

• L'utilisateur 1 n'a pas besoin d'être spécifié explicitement en tant que 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é en tant que compte principal autorisé direct de l'élément A, et l'élément B hérite sa LCA de l'élément A.
• L'utilisateur 2 n'est pas un compte principal autorisé indirect de l'élément A.

Définir le type d'héritage

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

• BOTH_PERMIT : définissez le type d'héritage sur BOTH_PERMIT pour n'accorder à un utilisateur l'accès à l'élément que lorsque la LCA de l'élément enfant et la LCA héritée de l'élément parent lui permettent d'accéder à l'élément.

• CHILD_OVERRIDE : définissez le type d'héritage sur CHILD_OVERRIDE pour forcer la LCA de l'élément enfant à prévaloir sur celle 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é, l'utilisateur y a toujours accès s'il a accès à l'élément enfant en tant que lecteur. À l'inverse, 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 est un lecteur refusé de l'enfant.

• PARENT_OVERRIDE : définissez le type d'héritage sur PARENT_OVERRIDE pour forcer la LCA de l'élément parent à prévaloir 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 y a toujours accès s'il a accès à l'élément parent en tant que lecteur. À l'inverse, même si la LCA de l'élément enfant accorde l'accès à l'utilisateur, celui-ci n'y a pas accès s'il est un lecteur refusé de 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. Pour les chaînes d'héritage de LCA, Cloud Search fournit un ordre d'évaluation de la feuille à la racine. Plus précisément, pour une chaîne, la décision d'une LCA commence par l'évaluation d'un enfant par ses parents, puis peut aller jusqu'au parent racine.

Par exemple, si l'enfant dispose du 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 dispose de PARENT_OVERRIDE ou de BOTH_PERMIT, Drive continue d'évaluer l'héritage plus haut dans la chaîne.

Confinement et suppression d'éléments

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

Les relations de confinement sont totalement indépendantes des règles d'héritage des LCA. Par exemple, un fichier d'un système de fichiers peut être contenu dans 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 figurent également dans la hiérarchie de conteneurs du dossier.

Les contrôles d'accès suivants 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 désigne l'élément B comme son conteneur.

Voici les règles d'accès basées sur les contrôles d'accès:

• L'accès indirect est accordé par 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 découle pas du fait que l'élément C soit contenu dans l'élément B. Par conséquent, l'utilisateur 2 ne peut pas accéder à l'élément C.

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

Lorsqu'un élément a bien été supprimé:

• Tout élément contenant un élément supprimé n'est plus inclus dans l'index de recherche et est programmé pour être supprimé de la source de données de Google.
• Tout élément ayant spécifié l'élément supprimé à l'aide de la méthode setInheritFrom() est exclu de l'index de recherche.

Si une ressource contient un élément supprimé à l'aide de la méthode setInheritFrom(), mais qu'elle n'a pas de conteneur défini avec setContainer() ou que sa hiérarchie de conteneurs 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 l'élément.

La figure 3 illustre le fonctionnement de la suppression d'une hiérarchie d'éléments.

Les contrôles d'accès suivants 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 conteneur.

La suppression est répercutée en cascade sur 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 à 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 répercutée qu'au niveau des références de conteneur.
• L'élément E devient inaccessible et aucun utilisateur ne peut le rechercher.