Mappa ACL

Per garantire 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 dell'accesso (ACL) dal repository aziendale. Devi modellare le ACL del repository e includerle durante l'indicizzazione degli elementi nel repository. L'SDK Content Connector fornisce un ricco insieme di metodi ACL sufficientemente potenti da modellare gli ACL della maggior parte dei repository.

Creare un ACL

La creazione di un ACL è una procedura in due passaggi:

  1. Crea un Principal utilizzando metodi statici nella classe ACL.
  2. Utilizza la classe Acl.Builder per creare l'ACL utilizzando l'entità.

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

Crea un principal utilizzando un ID esterno

Google Cloud Search richiede che utenti e gruppi vengano risolti nell'indirizzo email Google. Durante l'indicizzazione degli elementi del repository, i connettori dei contenuti potrebbero non disporre di questi indirizzi email. Tuttavia, Content Connector SDK 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 principal 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 degli ACL dell'elemento e degli 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, specificati utilizzando i metodi setReaders() e setDeniedReaders(). Un principal consentito diretto è un utente identificato in un ACL che gli concede l'accesso diretto a un elemento specifico. Un principal con accesso negato diretto è un utente identificato in un ACL come utente che non ha accesso a un elemento specifico.

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

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

Disegno dei collegamenti tra gli elementi
Figura 1. Il metodo setInheritFrom().

Questi controlli di accesso sono rappresentati nella Figura 1:

  • L'utente 1 è un principal consentito diretto dell'elemento A.
  • L'utente 2 è un principal consentito diretto 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 il relativo ACL dall'elemento A.
  • L'utente 2 non è un principal indiretto autorizzato 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 la ACL di un elemento secondario viene combinata con quella del relativo elemento 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 dell'elemento principale consentono all'utente di accedere all'elemento.

  • CHILD_OVERRIDE - Imposta il tipo di ereditarietà su CHILD_OVERRIDE per forzare l'elenco di controllo degli accessi dell'elemento secondario a prevalere sull'elenco di controllo degli accessi dell'elemento principale ereditato quando sono in conflitto. Pertanto, se l'ACL dell'elemento principale nega l'accesso all'utente come lettore negato, l'utente ha comunque accesso se ha accesso all'elemento secondario come lettore. Al contrario, anche se l'elenco di controllo degli accessi 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 la precedenza della ACL dell'elemento principale rispetto a quella dell'elemento secondario quando sono in conflitto. Pertanto, se l'elenco controllo accessi dell'elemento secondario nega l'accesso all'utente come lettore negato, l'utente ha comunque accesso se ha accesso all'elemento principale come lettore. Al contrario, anche se la ACL dell'elemento secondario concede l'accesso all'utente, l'utente non ha accesso se è un lettore negato dell'elemento principale.

Quando si valuta una catena di ereditarietà ACL, l'ordine di valutazione può modificare il risultato della decisione di autorizzazione. Cloud Search fornisce l'ordine di valutazione dalla foglia alla radice per le catene di ereditarietà degli ACL. Nello specifico, la decisione ACL per una catena inizia con la valutazione di un figlio con i suoi genitori e può progredire fino al genitore principale.

Ad esempio, se il bambino ha il tipo di ereditarietà CHILD_OVERRIDE e l'utente ha accesso al bambino, Drive non deve valutare il genitore. Tuttavia, se il bambino ha PARENT_OVERRIDE o BOTH_PERMIT, Drive continua a valutare l'ereditarietà più in alto nella catena.

Contenimento ed eliminazione degli 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.

Le relazioni 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 la ACL da una cartella diversa. L'eliminazione di una cartella non comporta l'eliminazione degli elementi che ereditano la relativa ACL, a meno che questi elementi non si trovino anche nella gerarchia di contenimento della cartella.

Questi controlli di accesso sono rappresentati nella Figura 2:

  • L'utente 1 è un principal consentito diretto dell'elemento A.
  • L'utente 2 è un principal consentito diretto dell'elemento B.
  • L'utente 3 è un principal 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 deriva dal metodo setInheritFrom(). Pertanto, l'utente 1 può accedere all'elemento C perché 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.
Disegno dei collegamenti tra gli elementi
Figura 2. Il metodo setInheritFrom() in uso.

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

Quando un elemento viene eliminato correttamente:

  • Qualsiasi elemento che conteneva un elemento eliminato non è più ricercabile e la sua eliminazione è pianificata dall'origine dati di Google.
  • Qualsiasi elemento che ha specificato l'elemento eliminato utilizzando il metodo setInheritFrom() non è più ricercabile.

Se una risorsa ha 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, 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 per una gerarchia di elementi.

Disegno dei collegamenti tra gli elementi
Figura 3. Eliminazione di un elemento e ereditarietà ACL.

Questi controlli di accesso sono rappresentati nella Figura 3:

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

L'eliminazione a cascata avviene tramite i riferimenti ai container. 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 viene eseguita a cascata solo tramite i riferimenti ai contenitori.
  • L'elemento E diventa irraggiungibile e nessun utente è in grado di cercarlo.