Per garantire che solo gli utenti con accesso a un elemento possano visualizzarlo all'interno di un nei risultati di ricerca, è consigliabile indicizzare gli elementi tramite i relativi elenchi di controllo di accesso (ACL) dal repository aziendale. Devi modellare gli ACL del tuo repository e a includere questi ACL durante l'indicizzazione degli elementi nel repository. Il connettore dei contenuti SDK offre un ricco set di metodi ACL sufficientemente potenti da modellare gli ACL di nella maggior parte dei repository.
Crea un ACL
La creazione di un ACL è un processo in due fasi:
- Crea un
Principalutilizzando metodi statici ACL . - Utilizza la
Acl.Builderper creare l'ACL utilizzando l'entità.
La parte restante di questo documento tratta alcuni concetti che devi conoscere per creare e creare ACL, come l'ereditarietà e il contenimento.
Crea un'entità utilizzando un ID esterno
Google Cloud Search richiede che utenti e gruppi risolvano gli indirizzi email di Google
. Durante l'indicizzazione degli elementi del repository, i connettori di contenuti potrebbero non avere questi
. Tuttavia, l'SDK Content Connector ti consente di utilizzare qualsiasi
ID esterno (ID che concede a un utente o a un gruppo l'accesso agli elementi del repository)
di un indirizzo email, per indicizzare un elemento. Utilizza la
getUserPrincipal()
o il metodo
getGroupPrincpal()
per creare entità contenenti ID esterni. Esistono diversi altri
metodi statici
ACL
classe utilizzata per creare
Principal oggetti.
Eredità ACL
L'ereditarietà ACL si riferisce all'autorizzazione, per un elemento specifico e dell'utente, in base al risultato di una combinazione di ACL dell'elemento e ACL della catena di ereditarietà. Le regole utilizzate per prendere una decisione di autorizzazione dipendono dal repository e dalle proprietà dell'elemento.
Imposta ereditarietà
Ogni elemento può avere entità consentite direttamente e entità negate direttamente,
specificato utilizzando
setReaders():
e
setDeniedReaders() metodi. Un accesso diretto
L'entità è un utente identificato in un ACL che fornisce l'accesso diretto
un elemento specifico. Un'entità diretta negata è un utente identificato in un ACL come non
avere accesso a un elemento specifico.
Un elemento può anche ereditare entità indirette consentite e
entità negate indirette utilizzando
setInheritFrom():
. Un'entità indiretta consentita è un utente che, tramite l'ereditarietà ACL,
ha accesso indiretto a un elemento specifico. Un'entità negata indiretta è un utente
a cui, tramite l'ereditarietà ACL, viene negato l'accesso a un elemento specifico.
La figura 1 mostra come
Il metodo setInheritFrom() viene utilizzato per ereditare le entità negate indirettamente consentite e indirette.
setInheritFrom().Questi controlli dell'accesso sono rappresentati nella Figura 1:
- L'Utente 1 è un'entità consentita diretta dell'elemento A.
- L'utente 2 è un'entità consentita diretta dell'elemento B.
- L'elemento B eredita l'ACL dell'elemento A.
In base ai controlli dell'accesso, le regole di accesso sono:
- Non è necessario specificare esplicitamente l'Utente 1 come entità dell'elemento B per essere un'entità indiretta consentita dell'elemento B; l'accesso viene ereditato perché l'Utente 1 è elencato come entità direttamente consentita dell'elemento A e dell'elemento B eredita l'ACL dall'elemento A.
- L'utente 2 non è un'entità indiretta consentita per l'elemento A.
Imposta tipo di ereditarietà
Se imposti l'ereditarietà utilizzando
setInheritFrom()
devi impostare il tipo di ereditarietà utilizzando il metodo
setInheritanceType()
. Il tipo di ereditarietà determina il modo in cui
L'ACL si combina con l'ACL principale. La Acl.InheritanceType
implementa tre tipi di ereditarietà:
BOTH_PERMIT- Imposta il tipo di ereditarietà suBOTH_PERMITper concedere l'accesso a un utente all'elemento solo quando sia l'ACL dell'elemento secondario sia l'ACL dell'elemento ereditato dall'elemento padre consentire all'utente di accedere all'elemento.CHILD_OVERRIDE- Imposta il tipo di ereditarietà suCHILD_OVERRIDEper forzare l'elemento secondario all'ACL di un elemento per avere la precedenza sull'ACL dell'elemento padre ereditato quando in conflitto. Quindi, se l'ACL dell'elemento principale nega l'accesso all'utente in quanto lettore negato, l'utente ha ancora accesso se ha accesso al bambino. elemento come lettore. Al contrario, anche se l'ACL dell'elemento padre concede l'accesso a L'utente, quest'ultimo non potrà accedere se è un lettore negato del figlio.PARENT_OVERRIDE- Imposta il tipo di ereditarietà suPARENT_OVERRIDEper forzare l'applicazione ACL dell'elemento principale per avere la precedenza sull'ACL dell'elemento secondario quando in conflitto. Quindi, se l'ACL dell'elemento secondario nega l'accesso all'utente come lettore, l'utente può ancora accedere se può accedere all'elemento principale come Reader. Al contrario, anche se l'ACL dell'elemento secondario concede l'accesso all'utente, il l'utente non ha accesso se è un lettore negato dell'elemento principale.
Durante la valutazione di una catena di ereditarietà ACL, l'ordine di valutazione può cambiare l'esito della decisione di autorizzazione. Cloud Search fornisce leaf-to-root l'ordine di valutazione delle catene di ereditarietà ACL. Nello specifico, la decisione relativa all'ACL per una catena inizia con la valutazione di un bambino con i suoi genitori e può progredire fino al padre root.
Ad esempio, se il publisher secondario ha il tipo di ereditarietà CHILD_OVERRIDE e l'utente
ha accesso all'account secondario, Drive non lo deve valutare.
Tuttavia, se tuo figlio ha PARENT_OVERRIDE o BOTH_PERMIT, Drive continua
sulla valutazione dell'ereditarietà più avanti nella catena.
Contenimento ed eliminazione di elementi
Durante l'indicizzazione di un elemento, puoi etichettarlo come contenitore utilizzando il metodo
setContainer() del metodo
IndexingItemBuilder
. La relazione container/containee stabilisce la relazione fisica
gerarchia di elementi e garantisce che questi vengano eliminati correttamente.
Quando elimini un contenitore, vengono eliminati anche i relativi elementi.
Le relazioni di contenimento sono completamente indipendenti dalle regole di ereditarietà ACL. Ad esempio, un file in un file system può essere contenuto in una cartella per il ma eredita l'ACL da una cartella diversa. L'eliminazione di un cartella non elimina gli elementi che ereditano l'ACL, a meno che non vengano nella gerarchia di contenimento della cartella.
Questi controlli dell'accesso sono rappresentati nella Figura 2:
- L'Utente 1 è un'entità consentita diretta dell'elemento A.
- L'utente 2 è un'entità consentita diretta dell'elemento B.
- L'utente 3 è un'entità consentita diretta dell'elemento C.
- L'elemento C eredita l'ACL dell'elemento A.
- L'elemento B chiama l'elemento A come contenitore.
- L'elemento C assegna all'elemento B il nome contenitore.
In base ai controlli dell'accesso, le regole di accesso sono:
- L'accesso indiretto proviene da
setInheritFrom(). Di conseguenza, l'utente 1 può accedere all'elemento C, perché l'elemento C eredita l'ACL elemento A. - L'accesso indiretto non proviene dall'elemento C contenuto dall'elemento B. Di conseguenza, l'utente 2 non può accedere all'elemento C.
setInheritFrom() in uso.La separazione dell'ereditarietà ACL dalla gerarchia di contenimento consente di definire diverse strutture esistenti.
Quando un elemento viene eliminato correttamente:
- Qualsiasi elemento che conteneva un elemento eliminato diventa non disponibile per la ricerca pianificata per l'eliminazione dall'origine dati di Google.
- Qualsiasi elemento che abbia specificato l'elemento eliminato utilizzando
Metodo
setInheritFrom()diventa non disponibile per la ricerca.
Se in una risorsa è stato eliminato un elemento utilizzando
setInheritFrom()
ma non ha un container impostato utilizzando
setContainer() o la sua gerarchia di contenimento non contiene elementi eliminati, ma l'elemento e i relativi dati
rimangono nell'origine dati di Google. Sei responsabile dell'eliminazione dell'elemento.
La figura 3 mostra un esempio di come funziona l'eliminazione di una gerarchia di elementi.
Questi controlli dell'accesso sono rappresentati nella Figura 3:
- L'Utente 1 è un'entità consentita diretta dell'elemento A.
- L'utente 2 è un'entità consentita diretta dell'elemento D.
- L'elemento D e l'elemento E ereditano entrambi l'ACL dell'elemento A.
- L'elemento D assegna all'elemento A come contenitore il nome.
- Gli elementi A ed E sono di livello principale in quanto non dispongono di un container.
Elimina a cascata i riferimenti al container. Quando viene eliminato l'elemento A:
- Tutti i discendenti di
setInheritFrom()perdere l'accesso per tutti gli utenti. - Nessun utente può accedere all'elemento A.
- L'elemento D è stato eliminato implicitamente. Nessun utente può accedere all'elemento D.
- L'elemento E non viene eliminato, poiché l'eliminazione interessa solo il container riferimenti.
- L'elemento E diventa irraggiungibile e nessun utente può cercarlo.