Per assicurarti che solo gli utenti con accesso a un elemento possano vederlo all'interno di un risultato di ricerca, devi indicizzare gli elementi con i relativi elenchi di controllo dell'accesso (ACL) del repository aziendale. Devi modellare gli ACL del repository e includerli durante l'indicizzazione degli elementi del repository. L'SDK del connettore di contenuti fornisce un ricco set di metodi ACL sufficientemente potenti per modellare gli ACL della maggior parte dei repository.
Crea un ACL
La creazione di un ACL prevede due passaggi:
- Crea un elemento
Principalutilizzando metodi statici nella classe ACL. - Utilizza la classe
Acl.Builderper creare l'ACL utilizzando l'entità.
La parte restante di questo documento illustra alcuni concetti che è necessario conoscere per modellare e creare ACL, come l'ereditarietà e il contenimento.
Crea un'entità utilizzando un ID esterno
Google Cloud Search richiede che gli utenti e i gruppi si risolvano all'indirizzo email Google. Durante l'indicizzazione degli elementi del repository, i connettori di contenuti potrebbero non avere questi indirizzi email. Tuttavia, l'SDK del connettore di contenuti ti consente di utilizzare qualsiasi ID esterno (ID che concede a un utente o un gruppo l'accesso agli elementi del repository), anziché un indirizzo email, per indicizzare un elemento. Utilizza il metodo getUserPrincipal() o getGroupPrincpal() per creare entità contenenti ID esterni. Esistono diversi altri metodi statici nella classe ACL utilizzati per creare oggetti Principal.
Ereditarietà ACL
L'ereditarietà ACL si riferisce all'autorizzazione, per un elemento specifico e un utente specifico, in base al risultato di una combinazione di ACL dell'elemento e ACL della sua catena di ereditarietà. Le regole utilizzate per prendere una decisione in merito all'autorizzazione dipendono dal repository e dalle proprietà dell'elemento.
Imposta ereditarietà
Ogni elemento può avere entità consentite dirette e entità direttamente rifiutate,
specificate utilizzando i metodi
setReaders()
e
setDeniedReaders(). Un'entità consentita diretta è un utente identificato in un ACL che concede l'accesso diretto a un elemento specifico. Un'entità diretta negata è un utente identificato in un ACL come non autorizzato ad accedere a un elemento specifico.
Un elemento può anche ereditare entità consentite indirette e entità negate indirettamente utilizzando il metodo setInheritFrom(). Un'entità consentita indiretta è un utente che, tramite l'ereditarietà ACL, ha accesso indiretto a un elemento specifico. Un'entità negata indirettamente è un utente a cui viene negato l'accesso a un elemento specifico tramite l'ereditarietà ACL.
La Figura 1 mostra come viene utilizzato il metodo setInheritFrom() per ereditare le entità consentite indirette e negate indirettamente.
setInheritFrom().Questi controlli dell'accesso sono rappresentati nella Figura 1:
- L'utente 1 è un'entità diretta consentita dell'elemento A.
- L'utente 2 è un'entità diretta consentita dell'elemento B.
- L'elemento B eredita l'ACL dell'elemento A.
In base ai controlli di accesso, le regole di accesso sono:
- L'utente 1 non deve essere specificato in modo esplicito come entità dell'elemento B per essere un'entità consentita indiretta dell'elemento B; l'accesso viene ereditato perché l'utente 1 è indicato come entità consentita diretta dell'elemento A, mentre l'elemento B eredita il suo ACL dall'elemento A.
- L'utente 2 non è un'entità consentita indiretta per l'elemento A.
Imposta il tipo di ereditarietà
Se imposti l'ereditarietà utilizzando il metodo setInheritFrom(), devi impostare il tipo di ereditarietà utilizzando il metodo setInheritanceType(). Il tipo di ereditarietà determina il modo in cui l'ACL di un elemento figlio
viene combinato con l'ACL del padre. Acl.InheritanceType implementa tre tipi di ereditarietà:
BOTH_PERMIT: imposta il tipo di ereditarietà suBOTH_PERMITper concedere a un utente l'accesso all'elemento solo quando sia l'ACL dell'elemento secondario sia l'ACL dell'elemento ereditato principale consentono all'utente di accedere all'elemento.CHILD_OVERRIDE: imposta il tipo di ereditarietà suCHILD_OVERRIDEper fare in modo che l'ACL dell'elemento secondario abbia la precedenza sull'ACL dell'elemento principale ereditato in caso di conflitto. Quindi, se l'ACL dell'elemento principale nega l'accesso all'utente come lettore negato, l'utente può comunque accedere se ha accesso all'elemento secondario come lettore. Al contrario, anche se l'ACL dell'elemento padre concede l'accesso all'utente, quest'ultimo non potrà accedere se è un lettore negato dell'elemento figlio.PARENT_OVERRIDE: imposta il tipo di ereditarietà suPARENT_OVERRIDEper fare in modo che l'ACL dell'elemento principale abbia la precedenza sull'ACL dell'elemento secondario in caso di conflitto. Pertanto, se l'ACL dell'elemento secondario nega l'accesso all'utente come lettore negato, l'utente potrà comunque accedervi se ha accesso all'elemento principale come lettore. Al contrario, anche se l'ACL dell'elemento secondario concede l'accesso all'utente, quest'ultimo non potrà accedere se è un lettore negato dell'elemento padre.
Durante la valutazione di una catena di eredità ACL, l'ordine di valutazione può cambiare il risultato della decisione di autorizzazione. Cloud Search fornisce l'ordine di valutazione leaf-to-root per le catene di ereditarietà ACL. In particolare, la decisione ACL per una catena inizia con la valutazione di un figlio con i suoi elementi padre e può progredire fino al padre principale.
Ad esempio, se l'asset secondario ha un tipo di ereditarietà CHILD_OVERRIDE e l'utente
ha accesso all'asset secondario, Drive non dovrà valutare l'elemento padre.
Tuttavia, se il figlio ha PARENT_OVERRIDE o BOTH_PERMIT, Drive continua a valutare l'ereditarietà più in alto nella catena.
Contenimento ed eliminazione di elementi
Quando indic un elemento, puoi etichettarlo come contenitore utilizzando il metodo setContainer() della classe IndexingItemBuilder. La relazione contenitore/contiene stabilisce la gerarchia
fisica degli elementi e ne garantisce l'eliminazione corretta.
Quando si elimina un contenitore, vengono eliminati anche gli elementi al suo interno.
Le relazioni di contenimento sono completamente indipendenti dalle regole di ereditarietà ACL. Ad esempio, un file di un file system può essere contenuto in una cartella per l'eliminazione, ma eredita l'ACL da una cartella diversa. Se elimini una cartella, non vengono eliminati gli elementi che ne ereditano l'ACL, a meno che anche questi non si trovino nella gerarchia di contenimento della cartella.
Questi controlli dell'accesso sono rappresentati nella Figura 2:
- L'utente 1 è un'entità diretta consentita dell'elemento A.
- L'utente 2 è un'entità diretta consentita dell'elemento B.
- L'utente 3 è un'entità diretta consentita dell'elemento C.
- L'elemento C eredita l'ACL dell'elemento A.
- L'elemento B denomina l'elemento A come contenitore.
- L'elemento C denomina l'elemento B come contenitore.
In base ai controlli di accesso, le regole di accesso sono:
- L'accesso indiretto proviene dal metodo
setInheritFrom(). Pertanto, l'utente 1 può accedere all'elemento C perché eredita l'ACL dell'elemento A. - L'accesso indiretto non proviene dall'elemento C contenuto nell'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 ti consente di modellare molte strutture esistenti diverse.
Quando un elemento viene eliminato correttamente:
- Qualsiasi elemento che conteneva un elemento eliminato diventa non disponibile per la ricerca e ne è stata pianificata l'eliminazione dall'origine dati di Google.
- Qualsiasi elemento per cui è stato specificato l'elemento eliminato utilizzando il metodo
setInheritFrom()diventerà non disponibile per la ricerca.
Se una risorsa ha un elemento eliminato che utilizza il metodo setInheritFrom(), ma non ha un set di container che utilizza setContainer() o la sua gerarchia di contenimento non contiene elementi eliminati, l'elemento e i suoi 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à diretta consentita dell'elemento A.
- L'utente 2 è un'entità diretta consentita dell'elemento D.
- L'elemento D e l'elemento E ereditano entrambi l'ACL dell'elemento A.
- L'elemento D denomina l'elemento A come contenitore.
- Gli elementi A ed E sono elementi di livello principale in quanto non hanno un elemento contenitore.
Elimina i riferimenti ai container a cascata. Quando l'elemento A viene eliminato:
- Tutti i discendenti del riferimento
setInheritFrom()perdono 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 avviene solo attraverso i riferimenti dei container.
- L'elemento E diventa non raggiungibile e nessun utente può cercarlo.