Listy ACL mapy

Aby mieć pewność, że tylko użytkownicy z dostępem do elementu mogą zobaczyć go w wynikach wyszukiwania, indeksuj elementy z listami kontroli dostępu (ACL) z repozytorium przedsiębiorstwa. Musisz modelować listy ACL repozytorium i uwzględniać je podczas indeksowania elementów. Pakiet SDK łącznika treści udostępnia metody modelowania list ACL większości repozytoriów.

Tworzenie listy ACL

Tworzenie listy ACL to proces dwuetapowy:

Utwórz obiekt Principal za pomocą metod statycznych w klasie ACL.
Użyj klasy Acl.Builder, aby utworzyć listę ACL za pomocą podmiotu.

W tym dokumencie opisujemy koncepcje modelowania i tworzenia list ACL, takie jak dziedziczenie i zawieranie.

Tworzenie podmiotu za pomocą identyfikatora zewnętrznego

Google Cloud Search wymaga, aby użytkownicy i grupy byli powiązani z adresami e-mail Google. Podczas indeksowania elementów repozytorium łączniki treści mogą nie mieć tych adresów e-mail. Pakiet SDK łącznika treści umożliwia jednak używanie zewnętrznego identyfikatora (identyfikatora przyznającego użytkownikowi lub grupie dostęp do elementów repozytorium) zamiast adresu e-mail do indeksowania elementu. Aby utworzyć podmioty zawierające identyfikatory zewnętrzne, użyj metody getUserPrincipal lub getGroupPrincipal. Klasa ACL zawiera kilka innych metod statycznych do tworzenia obiektów Principal.

Po ponownym przypisaniu tożsamości elementu musisz ponownie zindeksować elementy, aby zastosować nową tożsamość. Więcej informacji znajdziesz w sekcji Ponowne mapowanie tożsamości.

Dziedziczenie listy ACL

Dziedziczenie list kontroli dostępu odnosi się do autoryzacji konkretnego elementu i użytkownika na podstawie połączonych list kontroli dostępu elementu i jego łańcucha dziedziczenia. Reguły decyzji o autoryzacji zależą od repozytorium i właściwości elementu.

Ustawianie dziedziczenia

Każdy element może mieć bezpośrednio dozwolone podmioty zabezpieczeń i bezpośrednio odrzucone podmioty zabezpieczeń, które są określane za pomocą metod setReaders i setDeniedReaders. Bezpośredni dozwolony podmiot to użytkownik zidentyfikowany w liście ACL z bezpośrednim dostępem do elementu. Bezpośrednio odrzucony podmiot to użytkownik zidentyfikowany na liście ACL jako osoba, która nie ma dostępu do elementu.

Element może też dziedziczyć pośrednio dozwolone podmioty zabezpieczeń i pośrednio odrzucone podmioty zabezpieczeń za pomocą metody setInheritFrom. Pośrednio dozwolony podmiot zabezpieczeń ma pośredni dostęp do elementu dzięki dziedziczeniu listy ACL. Pośrednio odrzucony podmiot zabezpieczeń nie ma dostępu z powodu dziedziczenia.

Rysunek 1 pokazuje, jak używać metody setInheritFrom do dziedziczenia podmiotów.

Rysowanie połączeń między elementami — **Rysunek 1.** Metoda `setInheritFrom`.

Rysunek 1 przedstawia te elementy sterujące dostępem:

Użytkownik 1 jest bezpośrednim podmiotem uprawnionym do elementu A.
Użytkownik 2 jest bezpośrednim dozwolonym podmiotem zabezpieczeń elementu B.
Element B dziedziczy listę ACL elementu A.

Na podstawie tych ustawień reguły dostępu są następujące:

Użytkownik 1 jest pośrednim dozwolonym podmiotem elementu B, mimo że nie został wyraźnie określony. Dostęp jest dziedziczony z elementu A.
Użytkownik 2 nie jest pośrednim dozwolonym podmiotem elementu A.

Ustawianie typu dziedziczenia

Jeśli dziedziczenie ustawisz za pomocą metody setInheritFrom, musisz ustawić typ dziedziczenia za pomocą metody setInheritanceType. Typ dziedziczenia określa, w jaki sposób lista ACL elementu podrzędnego jest łączona z listą ACL elementu nadrzędnego. Klasa Acl.InheritanceType implementuje 3 typy:

BOTH_PERMIT – przyznawanie dostępu tylko wtedy, gdy zezwalają na to listy ACL dziecka i rodzica.
CHILD_OVERRIDE – w przypadku konfliktu lista kontroli dostępu organizacji podrzędnej ma pierwszeństwo przed listą kontroli dostępu organizacji nadrzędnej. Użytkownik może uzyskać dostęp do dziecka nawet wtedy, gdy rodzic go odmawia, lub nie uzyskać dostępu do dziecka nawet wtedy, gdy rodzic na to zezwala.
PARENT_OVERRIDE – w przypadku konfliktu lista ACL elementu nadrzędnego ma pierwszeństwo przed listą ACL elementu podrzędnego.

Cloud Search ocenia łańcuchy dziedziczenia list kontroli dostępu od liścia do korzenia. Ocena rozpoczyna się od dziecka i jego rodziców, a następnie może być kontynuowana w przypadku rodzica głównego.

Jeśli na przykład dziecko używa CHILD_OVERRIDE, a użytkownik ma dostęp, Cloud Search nie musi oceniać rodzica. Jeśli jednak dziecko używa PARENT_OVERRIDE lub BOTH_PERMIT, Cloud Search kontynuuje ocenę w górę łańcucha.

Kwarantanna i usuwanie elementów

Podczas indeksowania elementu możesz oznaczyć go jako kontener za pomocą metody setContainer klasy IndexingItemBuilder. Ta relacja określa hierarchię fizyczną i zapewnia prawidłowe usuwanie. Usunięcie kontenera powoduje też usunięcie elementów, które zawiera.

Relacje zawierania są niezależne od reguł dziedziczenia list ACL. Na przykład folder może zawierać plik, który ma zostać usunięty, ale plik może dziedziczyć listę ACL z innego folderu. Usunięcie folderu nie powoduje usunięcia elementów, które dziedziczą jego listę ACL, chyba że te elementy znajdują się również w hierarchii zawierania.

Ilustracja 2 przedstawia te ustawienia kontroli dostępu:

Użytkownik 1 jest bezpośrednim podmiotem uprawnionym do elementu A.
Użytkownik 2 jest bezpośrednim dozwolonym podmiotem zabezpieczeń elementu B.
Użytkownik 3 jest bezpośrednim dozwolonym podmiotem elementu C.
Element C dziedziczy listę kontroli dostępu elementu A.
Element B wskazuje element A jako swój kontener.
Element C wskazuje element B jako swój kontener.

Na podstawie tych ustawień reguły dostępu są następujące:

Dostęp pośredni pochodzi z metody setInheritFrom. Użytkownik 1 ma dostęp do elementu C, ponieważ dziedziczy on uprawnienia z elementu A.
Dostęp pośredni nie wynika z zawierania. Użytkownik 2 nie ma dostępu do elementu C.

Oddzielenie dziedziczenia list ACL od zawierania umożliwia modelowanie wielu struktur.

Gdy usuniesz element:

Każdy element zawierający usunięty element staje się niedostępny do wyszukiwania i jest zaplanowany do usunięcia.
Każdy element, w którym określono usunięty element w setInheritFrom, staje się niedostępny do wyszukiwania.

Jeśli zasób używa symbolu setInheritFrom w przypadku usuniętego elementu, ale nie ma ustawionego kontenera lub jego hierarchia nie zawiera usuniętych elementów, element pozostaje w źródle danych. Odpowiadasz za jego usunięcie.

Ilustracja 3 przedstawia przykład usuwania w przypadku hierarchii produktów.

Rysunek 3 przedstawia te elementy kontroli dostępu:

Użytkownik 1 jest bezpośrednim podmiotem uprawnionym do elementu A.
Użytkownik 2 jest bezpośrednim podmiotem uprawnionym do elementu D.
Elementy D i E dziedziczą po elemencie A.
Element D wskazuje element A jako swój kontener.
Elementy A i E są elementami najwyższego poziomu.

Usunięcia są kaskadowo przenoszone na odwołania do kontenerów. Gdy usuniesz element A:

Wszystkie elementy podrzędne pliku referencyjnego setInheritFrom utracą dostęp.
Użytkownicy nie mają już dostępu do elementu A.
Element D jest niejawnie usuwany i staje się niedostępny.
Element E nie zostanie usunięty, ale stanie się niedostępny i nie będzie można go wyszukać.