Mappa ACL

Per assicurarti che solo gli utenti con accesso a un elemento possano visualizzarlo in un risultato di ricerca, devi indicizzare gli elementi con i relativi elenchi di controllo di accesso (ACL) dal repository aziendale. Devi modellare le ACL del tuo repository e includerle durante l'indicizzazione degli elementi nel repository. L'SDK Content Connector fornisce un ampio insieme di metodi ACL sufficientemente potenti per modellare le ACL della maggior parte dei repository.

Creare un ACL

La creazione di un'ACL è un processo in due passaggi:

1. Crea un Principal utilizzando i metodi statici della classe ACL.
2. Utilizza la classe Acl.Builder per creare l'ACL utilizzando il principale.

Il resto di questo documento illustra alcuni concetti che devi conoscere per modellare e creare ACL, come l'ereditarietà e il contenimento.

Crea un principale utilizzando un ID esterno

Google Cloud Search richiede che gli utenti e i gruppi vengano risolti nell'indirizzo email di Google. Quando indicizzi gli elementi del repository, i connettori dei 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 a un gruppo l'accesso agli elementi del repository), anziché un indirizzo email, per indicizzare un elemento. Utilizza il metodo getUserPrincipal() o il metodo getGroupPrincpal() per creare principali contenenti ID esterni. Esistono diversi altri metodi statici nella classe ACL utilizzati per creare oggetti Principal.

Eredità ACL

L'eredità ACL si riferisce all'autorizzazione, per un elemento e un utente specifici, in base al risultato di una combinazione delle ACL dell'elemento e delle ACL della relativa catena di ereditarietà. Le regole utilizzate per prendere una decisione di autorizzazione dipendono dal repository e dalle proprietà dell'elemento.

Impostare l'ereditarietà

Ogni elemento può avere entità consentite dirette ed entità negate dirette, specificate utilizzando i metodi setReaders() e setDeniedReaders(). Un principale consentito diretto è un utente identificato in un ACL che ha accesso diretto a un elemento specifico. Un principale con accesso negato diretto è un utente identificato in un ACL come non in possesso dell'accesso a un elemento specifico.

Un elemento può anche ereditare entità consentite indirette e entità negate indirette utilizzando il metodo setInheritFrom(). Un principale consentito indiretto è un utente che, tramite l'ereditarietà ACL, ha accesso indiretto a un elemento specifico. Un'entità indiretta con accesso negato è un utente a cui, tramite l'eredità ACL, viene negato l'accesso a un elemento specifico.

La Figura 1 mostra come viene utilizzato il metodo setInheritFrom() per ereditare i principali consentiti e non consentiti indiretti.

Questi controlli di accesso sono rappresentati nella Figura 1:

• L'utente 1 è un principale consentito diretto dell'elemento A.
• L'utente 2 è un entità principale 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:

• L'utente 1 non deve essere specificato esplicitamente 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 e l'elemento B eredita l'ACL dall'elemento A.
• L'utente 2 non è un principale consentito indiretto 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 in che modo l'ACL di un gruppo secondario si combina con l'ACL del gruppo principale. Acl.InheritanceType implementa tre tipi di ereditarietà:

• BOTH_PERMIT: imposta il tipo di ereditarietà su BOTH_PERMIT per concedere a un utente l'accesso all'elemento solo quando sia l'ACL dell'elemento secondario sia l'ACL dell'elemento ereditato del principale consentono all'utente di accedere all'elemento.

• CHILD_OVERRIDE: imposta il tipo di ereditarietà su CHILD_OVERRIDE per forzare l'ACL dell'elemento secondario a avere la precedenza sull'ACL dell'elemento principale ereditato quando sono in conflitto. Pertanto, se l'ACL dell'elemento principale nega all'utente l'accesso come lettore negato, l'utente ha comunque accesso se ha accesso all'elemento figlio come lettore. Al contrario, anche se l'ACL dell'elemento principale concede l'accesso all'utente, quest'ultimo non ha accesso se è un lettore negato dell'elemento secondario.

• PARENT_OVERRIDE: imposta il tipo di ereditarietà su PARENT_OVERRIDE per forzare l'ACL dell'elemento principale a avere la precedenza sull'ACL dell'elemento figlio quando sono in conflitto. Pertanto, se l'ACL dell'elemento secondario nega all'utente l'accesso come lettore negato, l'utente ha comunque accesso 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 ha accesso se è un lettore negato dell'elemento principale.

Quando valuti una catena di ereditarietà ACL, l'ordine di valutazione può cambiare il risultato della decisione di autorizzazione. Cloud Search fornisce l'ordine di valutazione dall'elemento finale alla radice per le catene di ereditarietà ACL. Nello specifico, la decisione ACL per una catena inizia con la valutazione di un elemento secondario con i suoi elementi principali e può procedere fino all'elemento principale principale.

Ad esempio, se il tipo di eredità del gruppo secondario è CHILD_OVERRIDE e l'utente ha accesso al gruppo secondario, Drive non deve valutare il gruppo principale. Tuttavia, se il gruppo secondario ha PARENT_OVERRIDE o BOTH_PERMIT, Drive continua a valutare l'eredità più in alto nella catena.

Contenimento ed eliminazione di elementi

Quando indicizzi un elemento, puoi etichettarlo come contenitore utilizzando il metodo setContainer() della classe IndexingItemBuilder. La relazione contenitore/contenuto stabilisce la gerarchia fisica degli elementi e garantisce che vengano eliminati correttamente. Quando un contenitore viene eliminato, vengono eliminati anche gli elementi contenuti.

I rapporti di contenimento sono completamente indipendenti dalle regole di ereditarietà delle ACL. Ad esempio, un file in un file system può essere contenuto in una cartella ai fini dell'eliminazione, ma ereditare l'ACL da un'altra cartella. L'eliminazione di una cartella non comporta l'eliminazione degli elementi che ereditano il relativo ACL, a meno che questi elementi non siano anche nella gerarchia di contenimento della cartella.

Questi controlli di accesso sono rappresentati nella Figura 2:

• L'utente 1 è un principale consentito diretto dell'elemento A.
• L'utente 2 è un entità principale consentita diretta dell'elemento B.
• L'utente 3 è un principale consentito diretto dell'elemento C.
• L'elemento C eredita l'ACL dell'elemento A.
• L'elemento B indica l'elemento A come contenitore.
• L'elemento C indica l'elemento B come contenitore.

In base ai controlli dell'accesso, le regole di accesso sono:

• L'accesso indiretto proviene dal metodo setInheritFrom(). Pertanto, l'utente 1 può accedere all'elemento C perché l'elemento C eredita l'ACL dell'elemento A.
• L'accesso indiretto non deriva dal fatto che l'elemento C è contenuto nell'elemento B. Pertanto, l'utente 2 non può accedere all'elemento C.

La separazione dell'ereditarietà delle ACL dalla gerarchia di contenimento ti consente di modellare molte strutture esistenti diverse.

Quando un elemento viene eliminato correttamente:

• Tutti gli elementi che contenevano un elemento eliminato non sono più disponibili per la ricerca e sono pianificati per l'eliminazione dall'origine dati di Google.
• Qualsiasi elemento che ha specificato l'elemento eliminato utilizzando il metodo setInheritFrom() non è più disponibile per la ricerca.

Se una risorsa contiene un elemento eliminato utilizzando il metodo setInheritFrom() , ma non ha un contenitore impostato utilizzando setContainer() o la sua gerarchia di contenimento non contiene elementi eliminati, quell'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 per una gerarchia di elementi.

Questi controlli di accesso sono rappresentati nella Figura 3:

• L'utente 1 è un principale consentito diretto dell'elemento A.
• L'utente 2 è un principale consentito diretto dell'elemento D.
• L'elemento D e l'elemento E ereditano entrambi l'ACL dell'elemento A.
• L'elemento D indica l'elemento A come contenitore.
• Gli elementi A ed E sono elementi a livello di radice perché non hanno un elemento contenitore.

Le eliminazioni vengono applicate in modo ricorsivo ai riferimenti dei contenitori. 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 viene eliminato implicitamente. Nessun utente può accedere all'elemento D.
• L'elemento E non viene eliminato, poiché l'eliminazione avviene solo tramite i riferimenti ai contenitori.
• L'elemento E diventa irraggiungibile e nessun utente è in grado di cercarlo.