Mapper les LCA

Pour vous assurer que seuls les utilisateurs autorisés à accéder à un élément puissent 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 permettant de modéliser les LCA de la plupart des dépôts.

Créer une LCA

La procédure de création d'une LCA comprend 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 à partir du compte principal.

Ce document aborde les concepts permettant de modéliser et de créer des LCA, comme l'héritage et les conteneurs.

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

Dans Google Cloud Search, les utilisateurs et les groupes doivent être associés à des adresses e-mail Google. Or, lors de l'indexation des éléments du dépôt, il se peut que des connecteurs de contenu soient associés à des adresses autres que Google. Toutefois, le SDK Content Connector vous permet d'indexer un élément à l'aide d'un ID externe (autorisant l'accès d'un utilisateur ou d'un groupe aux éléments du dépôt), au lieu d'une adresse e-mail. Utilisez la méthode getUserPrincipal ou getGroupPrincipal pour créer des 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 le réindexer pour que la nouvelle identité soit prise en compte. Pour en savoir plus, consultez Remapper des identités.

Héritage des LCA

L'héritage des LCA renvoie à l'autorisation accordée pour un élément et 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 méthodes setReaders et setDeniedReaders. Un compte principal autorisé direct est un utilisateur identifié dans une LCA qui lui accorde un accès direct à un élément. À l'inverse, un compte principal refusé direct fait référence à un utilisateur identifié dans une LCA qui lui refuse cet accès.

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 a un accès indirect à un élément grâce à 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 méthode setInheritFrom pour hériter des comptes principaux.

Représentation des connexions entre les éléments
Figure 1. La méthode setInheritFrom.

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.

Voici les règles qui découlent de ces contrôles :

  • L'utilisateur 1 est un compte principal autorisé indirect de l'élément B sans avoir été défini explicitement. Il hérite en effet de l'accès depuis 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 comment une LCA enfant est combinée avec une LCA parent. Acl.InheritanceType implémente trois types :

  • BOTH_PERMIT : accordez l'accès uniquement lorsque les LCA enfant et parent l'autorisent.
  • CHILD_OVERRIDE : la LCA enfant prévaut 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 prévaut sur la LCA enfant en cas de conflit.

Cloud Search évalue les chaînes d'héritage des LCA de la feuille vers la racine. L'évaluation commence par l'enfant et ses parents, et peut se poursuivre jusqu'au parent racine.

Par exemple, si l'enfant utilise CHILD_OVERRIDE et que l'utilisateur y 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 l'évaluation en remontant la chaîne.

Conteneurs et suppression d'éléments

Lorsque vous indexez un élément, vous pouvez le marquer comme conteneur à l'aide de la méthode setContainer de la classe IndexingItemBuilder. Cette relation établit la hiérarchie physique et assure une suppression appropriée. Lorsque vous supprimez un conteneur, les éléments qu'il contient le sont également.

Les relations de conteneur sont indépendantes des règles d'héritage des LCA. Par exemple, un dossier peut contenir un fichier à supprimer, 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.

Voici les règles qui découlent de ces contrôles :

  • L'accès indirect est accordé par la méthode setInheritFrom. L'utilisateur 1 peut accéder à l'élément C, car il hérite de l'élément A.
  • L'accès indirect ne découle pas de la relation de contenu. L'utilisateur 2 ne peut pas accéder à l'élément C.
Représentation des connexions entre les éléments
Figure 2 : Méthode setInheritFrom utilisée.

La séparation entre l'héritage des LCA et l'arborescence de conteneurs 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 setInheritFrom est 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. C'est à vous de le supprimer.

La figure 3 illustre la procédure de suppression pour une arborescence d'éléments.

Représentation des connexions entre les éléments
Figure 3. Suppression d'un élément et héritage des LCA

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.

Les suppressions sont répercutées 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 setInheritFrom n'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 devient inaccessible et ne peut plus être recherché ;