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 du dépôt d'entreprise à l'aide de leurs listes de contrôle d'accès (LCA). Vous devez modéliser les LCA de votre dépôt et les inclure lors de l'indexation des éléments de celui-ci. 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 nécessite 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, il est possible que les connecteurs de contenu ne comportent pas ces adresses e-mail. Toutefois, le SDK Content Connector vous permet d'indexer un élément à l'aide de n'importe quel ID externe (identifiant accordant à un utilisateur ou à un groupe l'accès aux éléments du dépôt), au lieu d'une adresse e-mail. 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 permettant de créer des objets Principal.

Héritage des LCA

L'héritage des LCA désigne une autorisation pour un élément et un utilisateur donnés, en fonction du résultat d'une combinaison des LCA de l'élément et 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 autorisés directs et des comptes principaux refusés directement, 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, via l'héritage de la LCA, dispose d'un accès indirect à un élément spécifique. Un compte principal refusé indirect est un utilisateur qui, par héritage de la LCA, se voit refuser l'accès à un élément spécifique.

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

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.

En fonction des contrôles d'accès, les règles d'accès sont les suivantes:

• Il n'est pas nécessaire de spécifier explicitement l'utilisateur 1 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, et 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 à 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 accorder à un utilisateur l'accès à l'élément uniquement lorsque la LCA de l'élément enfant et la LCA héritée de l'élément parent lui permettent d'accéder à cet élément.

• CHILD_OVERRIDE : définissez le type d'héritage sur CHILD_OVERRIDE pour que la LCA de l'élément enfant prévale sur celle de l'élément parent héritée 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'a pas accès s'il est un lecteur refusé de l'élément 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 la LCA 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. Cloud Search fournit l'ordre d'évaluation de la feuille à la racine pour les chaînes d'héritage des LCA. Plus précisément, la décision de la LCA pour une chaîne commence par l'évaluation d'un enfant et de ses parents, et peut progresser jusqu'au parent racine.

Par exemple, si l'enfant a le type d'héritage CHILD_OVERRIDE et que l'utilisateur y a accès, Drive n'a pas besoin d'évaluer le parent. Toutefois, si l'élément enfant est associé à la valeur PARENT_OVERRIDE ou BOTH_PERMIT, Drive poursuit l'évaluation de l'héritage plus haut dans la chaîne.

Conteneurisation et suppression d'éléments

Lorsque vous indexez un élément, vous pouvez l'étiqueter en tant que 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 supprimés correctement. Lorsqu'un conteneur est supprimé, les éléments qu'il contient sont également supprimés.

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 se trouver dans un dossier à des fins de suppression, 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 si ces éléments figurent également dans la hiérarchie de conteneurs du dossier.

Ces 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 désigne l'élément A comme son conteneur.
• L'élément C désigne l'élément B comme son conteneur.

En fonction des contrôles d'accès, les règles d'accès sont les suivantes:

• L'accès indirect provient de la méthode setInheritFrom(). Par conséquent, l'utilisateur 1 peut accéder à l'élément C, car cet élément 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.

Lorsqu'un élément est supprimé:

• Tout élément qui contenait un élément supprimé n'est plus inclus dans l'index de recherche et doit être supprimé de la source de données Google.
• Tout élément ayant spécifié l'élément supprimé à l'aide de la méthode setInheritFrom() devient impossible à rechercher.

Si une ressource comporte un élément supprimé à l'aide de la méthode setInheritFrom(), mais qu'elle n'a pas d'ensemble de conteneurs à l'aide de setContainer(), ou si sa hiérarchie de conteneurs ne contient aucun élément supprimé, cet élément et ses données sont conservés dans la source de données Google. Vous êtes responsable de la suppression de l'élément.

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

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 conteneur.

Les suppressions se répercutent 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 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 répercutée qu'au niveau des références de conteneur.
• l'élément E devient inaccessible, et aucun utilisateur ne peut rechercher l'élément E.