Mapper les LCA

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

Remarque :Le SDK Content Connector est compatible avec les LCA à domaine unique, les LCA interdomaines. Vous ne pouvez pas accorder l'accès aux utilisateurs et aux groupes en dehors de votre organisation. Toutes les LCA faisant référence à des utilisateurs ou à des groupes organisation n'ont aucun effet.

Créer une LCA

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

1. Créez un Principal à l'aide de méthodes statiques ACL .
2. Utilisez le 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, comme l'héritage et le confinement.

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

Google Cloud Search exige des utilisateurs et des groupes qu'ils renvoient une adresse e-mail Google adresse e-mail. 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'utiliser ID externe (ID autorisant un utilisateur ou un groupe à accéder aux éléments du dépôt), à la place d'une adresse e-mail pour indexer un élément. Utilisez le getUserPrincipal() ou la getGroupPrincpal() pour créer des comptes principaux contenant des ID externes. Il existe plusieurs autres à l'aide de méthodes statiques ACL utilisée pour créer Principal.

Remarque :Les utilisateurs ne voient pas les éléments dans les résultats de recherche tant que leur ID externe n'est pas indiqué est synchronisé avec son compte Google. La synchronisation de ces utilisateurs ou groupes externes Les ID d'une adresse e-mail Google peuvent être attribués à l'aide d'une identité le connecteur d'alimentation. Pour en savoir plus sur les connecteurs d'identité, consultez Créez un connecteur d'identité.

Avertissement :Après avoir remappé l'identité d'un élément à une autre identité, vous devez réindexer les éléments pour que la nouvelle identité s'applique. Pour en savoir plus, consultez au remappage des identités.

Héritage des LCA

L'héritage des LCA désigne une autorisation portant sur un élément spécifique et en fonction du résultat obtenu en combinant les LCA de l'élément et les 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 l'héritage

Chaque élément peut avoir des comptes principaux autorisés directs et des comptes principaux refusés directement. spécifiée à l'aide de la propriété setReaders() et setDeniedReaders(). Direct autorisé principal est un utilisateur identifié dans une LCA qui lui donne un accès direct un article spécifique. Un compte principal refusé direct est un utilisateur identifié dans une LCA comme n'étant pas avoir accès à un élément spécifique.

Un élément peut également hériter de comptes principaux autorisés indirects et comptes principaux refusés indirects à l'aide de setInheritFrom() . Un compte principal autorisé indirect est un utilisateur qui, via 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, par héritage de la LCA, se voit refuser l'accès à un élément spécifique.

Remarque :Si vous définissez l'héritage à l'aide de la propriété setInheritFrom() , vous devez définir le type d'héritage à l'aide de la méthode setInheritanceType() . Pour en savoir plus sur les types d'héritage, consultez Définissez le type d'héritage.

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

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.

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 compte principal autorisé indirect de l'élément B ; l'accès est hérité car l'utilisateur 1 est listé comme compte principal autorisé direct pour les éléments A et B hérite 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 est combinée à celle de son parent. Acl.InheritanceType met en œuvre trois types d'héritage:

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

• CHILD_OVERRIDE : définissez le type d'héritage sur CHILD_OVERRIDE pour forcer l'enfant. la LCA de l'élément soit prioritaire sur la LCA de l'élément parent hérité, lorsqu'il conflit. Ainsi, si la LCA de l'élément parent refuse l'accès à l'utilisateur comme lecteur refusé, l'utilisateur y a toujours accès s'il a accès à l'enfant en tant que lecteur. À l'inverse, même si la LCA de l'élément parent autorise l'accès l'utilisateur, celui-ci n'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 le à la LCA de l'élément parent afin qu'elle soit prioritaire sur la LCA de l'élément enfant lorsque conflit. Ainsi, si la LCA de l'élément enfant refuse l'accès à l'utilisateur lecteur, l'utilisateur y a toujours accès s'il a accès à l'élément parent en tant que en lecture seule. À l'inverse, même si la LCA de l'élément enfant accorde l'accès à l'utilisateur, L'utilisateur n'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 changer le résultat de la décision concernant l'autorisation. Cloud Search fournit une fonction ordre d'évaluation pour les chaînes d'héritage des LCA. Plus précisément, la décision ACL d'une chaîne commence par l'évaluation de l'enfant et de ses parents. jusqu'au parent racine.

Par exemple, si le type d'héritage de l'enfant est 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 sur 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 lui attribuer un libellé en tant que conteneur à l'aide de la méthode Méthode setContainer() du IndexingItemBuilder . La relation conteneur/contenu établit le la hiérarchie des éléments et s'assure que ceux-ci 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 être contenu dans un dossier pour mais héritent de la LCA d'un autre dossier. Supprimer un ne supprime pas les éléments qui héritent de sa LCA, sauf si ces éléments sont également dans la hiérarchie de confinement 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 est accordé par 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.

Figure 2. La méthode setInheritFrom() utilisée.

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 est est programmée pour être supprimée de la source de données Google.
• Tout élément ayant spécifié l'élément supprimé à l'aide de la méthode Méthode setInheritFrom() devient impossible à rechercher.

Si une ressource comporte un élément supprimé à l'aide de la méthode setInheritFrom() , mais elle ne comporte pas de conteneur défini à l'aide de setContainer() ou son arborescence de conteneurs ne contient aucun élément supprimé, cet élément et ses données reste 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 pour une hiérarchie d'éléments.

Figure 3. Suppression d'un élément et héritage des 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 de 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 du setInheritFrom() de référence 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'à travers le conteneur ; de référence.
• l'élément E devient inaccessible, et aucun utilisateur ne peut rechercher l'élément E.