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.
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 ACL . - 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
.
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.
La figure 1 montre comment
La méthode setInheritFrom()
permet d'hériter des comptes principaux autorisés et refusés indirects.
![Dessin des connexions entre les éléments](https://developers-dot-devsite-v2-prod.appspot.com/static/cloud-search/images/inherit-from-SDK.png?authuser=6&hl=fr)
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 surBOTH_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 surCHILD_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 surPARENT_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.
![Dessin des connexions entre les éléments](https://developers-dot-devsite-v2-prod.appspot.com/static/cloud-search/images/doc-hierarchy-SDK.png?authuser=6&hl=fr)
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.
![Dessin des connexions entre les éléments](https://developers-dot-devsite-v2-prod.appspot.com/static/cloud-search/images/doc-hierarchy-deletion-SDK.png?authuser=6&hl=fr)
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.