Per garantire che solo gli utenti con accesso a un elemento possano visualizzarlo nei risultati di ricerca, indicizza gli elementi con i relativi elenchi di controllo di accesso (ACL) dal repository aziendale. Devi modellare le ACL del repository e includerle durante l'indicizzazione degli elementi. L'SDK Content Connector fornisce metodi per modellare gli ACL della maggior parte dei repository.
Crea un ACL
La creazione di un ACL è una procedura in due passaggi:
- Crea un
Principalutilizzando metodi statici nella classe ACL. - Utilizza la classe
Acl.Builderper creare l'ACL utilizzando l'entità.
Questo documento tratta i concetti 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 in indirizzi email Google. Durante l'indicizzazione degli elementi del repository, i connettori dei contenuti potrebbero non disporre di questi indirizzi email. Tuttavia, l'SDK Content Connector ti consente di utilizzare un
ID esterno (un 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
getGroupPrincipal
per creare principal contenenti ID esterni. La classe
ACL
include diversi altri metodi statici per creare oggetti Principal.
Dopo aver rimappato l'identità di un elemento, devi reindicizzare gli elementi affinché la nuova identità venga applicata. Per ulteriori informazioni, consulta la sezione Rimappatura delle identità.
Ereditarietà ACL
L'ereditarietà delle ACL si riferisce all'autorizzazione per un elemento e un utente specifici in base alle ACL combinate dell'elemento e della relativa catena di ereditarietà. Le regole per una decisione di autorizzazione dipendono dal repository e dalle proprietà dell'elemento.
Imposta ereditarietà
Ogni elemento può avere entità consentite dirette ed entità negate dirette,
specificati utilizzando i metodi
setReaders
e
setDeniedReaders. Un'entità consentita diretta è un utente identificato in un elenco di controllo dell'accesso con accesso diretto a un elemento. Un principal con accesso negato diretto è un utente identificato in un ACL come
utente che non ha accesso a un elemento.
Un elemento può anche ereditare entità consentite indirette ed entità negate indirette utilizzando il metodo setInheritFrom. Un'entità indiretta consentita ha accesso indiretto a un elemento tramite l'ereditarietà
dell'ACL. A un'entità negata indiretta viene negato l'accesso tramite ereditarietà.
La Figura 1 mostra come utilizzare il metodo
setInheritFrom
per ereditare i principal.
setInheritFrom.La Figura 1 mostra questi controlli dell'accesso:
- 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 a questi controlli, le regole di accesso sono:
- L'utente 1 è un principal indiretto consentito dell'elemento B senza essere specificato in modo esplicito; l'accesso viene ereditato dall'elemento A.
- L'utente 2 non è un principal indiretto consentito dell'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 la modalità di combinazione di un ACL figlio con un ACL padre. Acl.InheritanceType
implementa tre tipi:
BOTH_PERMIT: concede l'accesso solo quando gli ACL del bambino e del genitore lo consentono.CHILD_OVERRIDE: l'ACL secondaria ha la precedenza su quella principale in caso di conflitto. Un utente può accedere al bambino anche se il genitore lo nega oppure vedersi negato l'accesso al bambino anche se il genitore lo consente.PARENT_OVERRIDE- In caso di conflitto, l'ACL principale ha la precedenza sull'ACL secondaria.
Cloud Search valuta le catene di ereditarietà ACL dalla foglia alla radice. La valutazione inizia con il bambino e i suoi genitori e può proseguire fino al genitore principale.
Ad esempio, se il bambino utilizza CHILD_OVERRIDE e l'utente ha accesso,
Cloud Search non deve valutare il genitore. Tuttavia, se il
figlio utilizza PARENT_OVERRIDE o BOTH_PERMIT, Cloud Search
continua la valutazione nella catena.
Contenimento ed eliminazione degli elementi
Quando indicizzi un elemento, puoi etichettarlo come contenitore utilizzando il metodo
setContainer
della classe
IndexingItemBuilder. Questa relazione stabilisce la gerarchia fisica e garantisce l'eliminazione corretta. Quando elimini un contenitore, vengono eliminati anche gli elementi contenuti.
Le relazioni di contenimento sono indipendenti dalle regole di ereditarietà ACL. Ad esempio, una cartella può contenere un file a scopo di eliminazione, ma il file può ereditare il suo ACL da una cartella diversa. L'eliminazione di una cartella non elimina gli elementi che ereditano il relativo ACL, a meno che non si trovino anche nella gerarchia di contenimento.
La Figura 2 mostra questi controlli dell'accesso:
- 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 a questi controlli, le regole di accesso sono:
- L'accesso indiretto deriva dal metodo
setInheritFrom. L'utente 1 può accedere all'elemento C perché lo eredita dall'elemento A. - L'accesso indiretto non deriva dal contenimento. L'utente 2 non può accedere all'elemento C.
setInheritFrom
in uso.La separazione dell'ereditarietà delle ACL dal contenimento consente di modellare molte strutture.
Quando elimini un elemento:
- Qualsiasi elemento contenente l'elemento eliminato non è più ricercabile e viene pianificato per l'eliminazione.
- Qualsiasi elemento che specifica l'elemento eliminato in
setInheritFromdiventa non ricercabile.
Se una risorsa utilizza setInheritFrom per un elemento eliminato, ma non è impostato alcun contenitore o la sua gerarchia non contiene elementi eliminati, l'elemento rimane nell'origine dati.
È tua responsabilità eliminarlo.
La figura 3 mostra un esempio di eliminazione per una gerarchia di elementi.
La Figura 3 mostra questi controlli dell'accesso:
- 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 dall'elemento A.
- L'elemento D indica l'elemento A come contenitore.
- Gli elementi A ed E sono elementi di primo livello.
Le eliminazioni vengono propagate tramite i riferimenti ai container. Quando elimini l'elemento A:
- Tutti i discendenti del riferimento
setInheritFromperdono l'accesso. - Gli utenti non possono più accedere all'elemento A.
- L'elemento D viene eliminato implicitamente e diventa inaccessibile.
- L'elemento E non viene eliminato, ma diventa irraggiungibile e non è possibile cercarlo.