Listy ACL mapy

Aby mieć pewność, że tylko użytkownicy z dostępem do elementu mogą zobaczyć go w wynikach wyszukiwania, indeksuj elementy z ich 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 kontroli dostępu to proces dwuetapowy:

Utwórz obiekt Principal za pomocą metod statycznych w klasie ACL.
Użyj klasy Acl.Builder, aby utworzyć listę kontroli dostępu (ACL) za pomocą podmiotu zabezpieczeń.

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 indeksowanie elementu za pomocą zewnętrznego identyfikatora (identyfikatora przyznającego użytkownikowi lub grupie dostęp do elementów repozytorium) zamiast adresu e-mail. Użyj metody getUserPrincipal lub getGroupPrincipal, aby utworzyć podmioty zawierające identyfikatory zewnętrzne. Klasa ACL zawiera kilka innych metod statycznych do tworzenia obiektów Principal.

Po ponownym przypisaniu tożsamości elementu musisz ponownie zindeksować elementy, aby nowa tożsamość została zastosowana. Więcej informacji znajdziesz w sekcji Ponowne mapowanie tożsamości.

Dziedziczenie listy kontroli dostępu

Dziedziczenie listy 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ń, określone za pomocą metod setReaders i setDeniedReaders. Bezpośredni dozwolony podmiot zabezpieczeń to użytkownik zidentyfikowany na 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średnie dozwolone podmioty zabezpieczeń i pośrednie 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 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, ale 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. Interfejs Acl.InheritanceType ma 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 odrzuci, lub nie uzyskać dostępu do dziecka nawet wtedy, gdy rodzic na to zezwoli.
PARENT_OVERRIDE – w przypadku konfliktu lista ACL nadrzędnego węzła ma pierwszeństwo przed listą ACL węzła 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 listy 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 jego zawartości.

Rysunek 2 przedstawia te ustawienia dostępu:

Użytkownik 1 jest bezpośrednim podmiotem uprawnionym do elementu A.
Użytkownik 2 jest bezpośrednim dozwolonym podmiotem elementu B.
Użytkownik 3 jest bezpośrednim dozwolonym podmiotem elementu C.
Element C dziedziczy listę ACL elementu A.
Element B wskazuje element A jako swój kontener.
Element C wskazuje element B jako 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 polu setInheritFrom, staje się niedostępny do wyszukiwania.

Jeśli zasób używa 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 usunięcia hierarchii elementów.

Rysunek 3 przedstawia te ustawienia dostępu:

Użytkownik 1 jest bezpośrednim podmiotem uprawnionym do elementu A.
Użytkownik 2 jest bezpośrednim dozwolonym podmiotem 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 produkt A:

Wszystkie pliki referencyjne pochodne setInheritFrom utracą dostęp.
Użytkownicy nie mają już dostępu do elementu A.
Element D zostanie usunięty w sposób dorozumiany i stanie się niedostępny.
Element E nie zostanie usunięty, ale stanie się niedostępny i nie będzie można go wyszukać.