Per assicurarti che solo gli utenti con accesso a un elemento possano visualizzarlo all'interno di un risultato di ricerca, devi indicizzare gli elementi con i relativi elenchi di controllo dell'accesso (ACL) dal repository aziendale. Devi modellare gli ACL del repository e includerli durante l'indicizzazione degli elementi nel repository. L'SDK Content Connector offre un ricco set di metodi ACL sufficientemente potenti da modellare gli ACL della maggior parte dei repository.
Crea un ACL
La creazione di un ACL è un processo in due fasi:
- Crea una
Principalutilizzando metodi statici nella classe ACL. - Utilizza la classe
Acl.Builderper creare l'ACL utilizzando l'entità.
La parte restante di questo documento tratta alcuni concetti che devi conoscere per modellare e creare ACL, come l'ereditarietà e il contenimento.
Crea un'entità utilizzando un ID esterno
Google Cloud Search richiede che utenti e gruppi inviino una richiesta all'indirizzo email
Google. Durante l'indicizzazione degli elementi del repository, i connettori di contenuti potrebbero non avere questi indirizzi email. Tuttavia, l'SDK Content Connector 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. Nella classe ACL esistono diversi altri metodi statici utilizzati per creare Principal oggetti.
Eredità ACL
L'ereditarietà ACL si riferisce all'autorizzazione, per un elemento e un utente specifico, in base al risultato di una combinazione di ACL dell'elemento e ACL della relativa 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 dirette e entità negate dirette,
specificate utilizzando i metodi
setReaders()
e
setDeniedReaders(). Un'entità consentita diretta è un utente identificato in un ACL che gli permette di accedere direttamente a un elemento specifico. Un'entità negata direttamente è un utente identificato in un ACL come non autorizzato ad accedere a un elemento specifico.
Un elemento può anche ereditare entità indirette consentite e indirette negate utilizzando il metodo 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 viene utilizzato il metodo setInheritFrom() per ereditare le entità consentite indirette e negate 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à consentita indiretta dell'elemento B. L'accesso viene ereditato perché l'utente 1 è elencato come entità consentita diretta dell'elemento A, mentre l'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 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 publisher secondario si combina con l'ACL di livello superiore. La 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 dell'elemento principale consentono all'utente di accedere all'elemento.CHILD_OVERRIDE: imposta il tipo di ereditarietà suCHILD_OVERRIDEper forzare l'ACL dell'elemento secondario a avere la precedenza sull'ACL dell'elemento principale ereditato quando è in conflitto. Quindi, se l'ACL dell'elemento principale nega l'accesso all'utente come lettore negato, l'utente può comunque accedere se può accedere all'elemento secondario come lettore. Al contrario, anche se l'ACL dell'elemento principale concede l'accesso all'utente, quest'ultimo non potrà accedere se è un lettore negato del dominio secondario.PARENT_OVERRIDE: imposta il tipo di ereditarietà suPARENT_OVERRIDEper forzare l'ACL dell'elemento principale a 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 negato, l'utente può comunque accedere 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 avrà accesso se è un lettore negato dell'elemento principale.
Durante la valutazione di una catena di ereditarietà ACL, l'ordine di valutazione può cambiare il risultato della decisione di autorizzazione. Cloud Search fornisce l'ordine di valutazione da foglia a radice per le catene di ereditarietà ACL. Nello specifico, la decisione relativa all'ACL per una catena inizia con la valutazione di un asset secondario con i relativi genitori e può progredire fino al padre principale.
Ad esempio, se la risorsa secondaria ha un tipo di ereditarietà CHILD_OVERRIDE e l'utente ha accesso a quella secondaria, Drive non deve valutare l'unità principale.
Tuttavia, se l'account secondario ha PARENT_OVERRIDE o BOTH_PERMIT, Drive continua a valutare l'ereditarietà più in alto nella catena.
Contenimento ed eliminazione di elementi
Durante l'indicizzazione di un elemento, puoi etichettarlo come container utilizzando il metodo setContainer() della classe IndexingItemBuilder. La relazione container/containee stabilisce la gerarchia fisica degli elementi e assicura 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 essere eliminato, ma ereditare l'ACL da una cartella diversa. L'eliminazione di una cartella non elimina gli elementi che ne ereditano l'ACL, a meno che non siano anche presenti 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 dal metodo
setInheritFrom(). Di conseguenza, l'utente 1 può accedere all'elemento C, perché l'elemento C eredita l'ACL dell'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 modellare molte strutture esistenti.
Quando un elemento viene eliminato correttamente:
- Qualsiasi elemento che conteneva un elemento eliminato non è più disponibile per la ricerca e ne viene pianificata l'eliminazione dall'origine dati di Google.
- Qualsiasi elemento per cui è stato specificato l'elemento eliminato utilizzando il metodo
setInheritFrom()non è più disponibile per la ricerca.
Se una risorsa ha un elemento eliminato utilizzando 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 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 a livello di directory principale in quanto non hanno un elemento container.
Elimina a cascata i riferimenti al container. Quando viene eliminato l'elemento A:
- 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 container.
- L'elemento E diventa irraggiungibile e nessun utente può cercarlo.