Pour vous assurer que seuls les utilisateurs ayant accès à un élément peuvent le voir dans les résultats de recherche, indexez les éléments avec leurs listes de contrôle d'accès (LCA) à partir du dépôt d'entreprise. Vous devez modéliser les LCA du dépôt et les inclure lors de l'indexation des éléments. Le SDK Content Connector fournit des méthodes 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 :
- Créez un
Principalà l'aide de méthodes statiques dans la ACL. - Utilisez la
Acl.Builderclasse pour créer la LCA à l'aide du compte principal.
Ce document aborde les concepts permettant de modéliser et de créer des LCA, tels que l'héritage et les conteneurs.
Créer un compte principal à l'aide d'un ID externe
Google Cloud Search exige que les utilisateurs et les groupes soient associés à des adresses 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 un ID externe (un ID qui accorde à 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 la
getUserPrincipal
méthode ou la
getGroupPrincipal
méthode pour créer des comptes principaux contenant des ID externes. La classe
ACL
inclut plusieurs autres méthodes statiques pour créer des objets Principal.
Après avoir remappé l'identité d'un élément, vous devez réindexer les éléments pour que la nouvelle identité prenne effet. Pour en savoir plus, consultez Remapper des identités.
Héritage des LCA
L'héritage des LCA fait référence à l'autorisation d'un élément et d'un utilisateur spécifiques en fonction des LCA combinées de l'élément et de sa chaîne d'héritage. Les règles d'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 directs,
spécifiés à l'aide des
setReaders
et
setDeniedReaders
méthodes. Un compte principal autorisé direct est un utilisateur identifié dans une LCA avec un accès direct à un élément. Un compte principal refusé direct est un utilisateur identifié dans une LCA comme n'ayant pas accès à un élément.
Un élément peut également hériter de comptes principaux autorisés indirects et de comptes principaux refusés indirects
à l'aide de la
setInheritFrom
méthode. Un compte principal autorisé indirect a un accès indirect à un élément via l'héritage de la LCA. Un compte principal refusé indirect se voit refuser l'accès par héritage.
La figure 1 montre comment utiliser la
setInheritFrom
méthode pour hériter des comptes principaux.
setInheritFrom
méthode.La figure 1 représente les contrôles d'accès suivants :
- 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 de ces contrôles, les règles d'accès sont les suivantes :
- L'utilisateur 1 est un compte principal autorisé indirect de l'élément B sans être spécifié explicitement. L'accès est hérité 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
setInheritFrom
méthode, vous devez définir le type d'héritage à l'aide de la
setInheritanceType
méthode. Le type d'héritage détermine comment une LCA enfant est combinée à une LCA parent.
Acl.InheritanceType
implémente trois types :
BOTH_PERMIT: n'accorde l'accès que lorsque les LCA enfant et parent l'autorisent.CHILD_OVERRIDE: la LCA enfant est prioritaire sur la LCA parent en cas de conflit. Un utilisateur peut accéder à l'enfant même si le parent le refuse, ou se voir refuser l'accès à l'enfant même si le parent l'autorise.PARENT_OVERRIDE: la LCA parent est prioritaire sur la LCA enfant en cas de conflit.
Cloud Search évalue les chaînes d'héritage des LCA de la feuille à la racine. L'évaluation commence par l'enfant et ses parents, et peut progresser jusqu'au parent racine.
Par exemple, si l'enfant utilise CHILD_OVERRIDE et que l'utilisateur a accès, Cloud Search n'a pas besoin d'évaluer le parent. Toutefois, si l'enfant utilise PARENT_OVERRIDE ou BOTH_PERMIT, Cloud Search continue d'évaluer la chaîne.
Conteneurs et suppression d'éléments
Lors de l'indexation d'un élément, vous pouvez le marquer comme conteneur à l'aide de la
setContainer
méthode de la
IndexingItemBuilder
classe. Cette relation établit la hiérarchie physique et garantit une suppression appropriée. Lorsque vous supprimez un conteneur, les éléments qu'il contient sont également supprimés.
Les relations de conteneur sont indépendantes des règles d'héritage des LCA. Par exemple, un dossier peut contenir un fichier à des fins de suppression, mais le fichier peut hériter de sa 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 son arborescence de conteneurs.
La figure 2 représente les contrôles d'accès suivants :
- 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 de ces contrôles, les règles d'accès sont les suivantes :
- L'accès indirect provient de la
setInheritFromméthode. L'utilisateur 1 peut accéder à l'élément C, car il hérite de l'élément A. - L'accès indirect ne provient pas du conteneur. L'utilisateur 2 ne peut pas accéder à l'élément C.
setInheritFrom
méthode en cours d'utilisation.La séparation de l'héritage des LCA du conteneur vous permet de modéliser de nombreuses structures.
Lorsque vous supprimez un élément :
- tout élément contenant l'élément supprimé est exclu de l'index de recherche (sa suppression est alors programmée) ;
- tout élément ayant désigné l'élément supprimé dans
setInheritFromest exclu de l'index de recherche.
Si une ressource utilise setInheritFrom pour un élément supprimé, mais qu'aucun conteneur n'est défini ou que sa hiérarchie ne contient aucun élément supprimé, l'élément reste dans la source de données.
Il vous incombe de le supprimer.
La figure 3 montre un exemple de suppression pour une hiérarchie d'éléments.
La figure 3 représente les contrôles d'accès suivants :
- 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 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.
L'opération de suppression est répercutée en cascade au niveau des références de conteneur. Lorsque vous supprimez l'élément A :
- plus aucun descendant de la référence
setInheritFromn'est accessible ; - les utilisateurs ne peuvent plus accéder à l'élément A ;
- l'élément D est implicitement supprimé et devient inaccessible ;
- l'élément E n'est pas supprimé, mais il devient inaccessible et exclu de l'index de recherche.