Listy ACL mapy

Aby mieć pewność, że tylko użytkownicy z dostępem do elementu będą mogli zobaczyć ten element w wynikach wyszukiwania, zindeksuj elementy za pomocą ich list kontroli dostępu (ACL) z repozytorium firmy. Musisz modelować listy kontroli dostępu repozytorium i uwzględniać je podczas indeksowania elementów w repozytorium. Pakiet SDK Content Connector udostępnia bogaty zestaw metod ACL umożliwiających modelowanie list kontroli dostępu w większości repozytoriów.

Tworzenie listy ACL

Tworzenie listy ACL jest procesem dwuetapowym:

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

W pozostałej części tego dokumentu opisano niektóre pojęcia, które musisz znać podczas tworzenia i modelowania list kontroli dostępu, takich jak dziedziczenie i izolacja.

Utwórz podmiot zabezpieczeń przy użyciu identyfikatora zewnętrznego

Google Cloud Search wymaga, aby użytkownicy i grupy używali adresu e-mail Google. Podczas indeksowania elementów repozytorium oprogramowanie sprzęgające treści może nie mieć tych adresów e-mail. Jednak pakiet Content Connector SDK umożliwia indeksowanie elementu za pomocą dowolnego identyfikatora zewnętrznego (identyfikatora przyznającego użytkownikowi lub grupie dostęp do elementów repozytorium) zamiast adresu e-mail. Użyj metody getUserPrincipal() lub getGroupPrincpal(), aby utworzyć podmioty zabezpieczeń zawierające identyfikatory zewnętrzne. W klasie ACL istnieje kilka innych metod statycznych służących do tworzenia obiektów Principal.

Dziedziczenie ACL

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

Ustaw dziedziczenie

Każdy element może mieć podmioty zabezpieczeń dozwolonych bezpośrednio i podmioty zabezpieczeń bezpośrednich określonych za pomocą metod setReaders() i setDeniedReaders(). Bezpośredni dozwolony podmiot zabezpieczeń to użytkownik wskazany na liście kontroli dostępu (ACL), który daje mu bezpośredni dostęp do określonego elementu. Podmiot zabezpieczeń odmowy bezpośredniej to użytkownik zidentyfikowany na liście kontroli dostępu jako użytkownik, który nie ma dostępu do określonego elementu.

Element może też dziedziczyć podmioty zabezpieczeń dozwolonych pośrednio i podmioty zabezpieczeń z odmową pośrednią za pomocą metody setInheritFrom(). Podmiot zabezpieczeń dozwolony pośrednio to użytkownik, który dzięki dziedziczeniu listy kontroli dostępu (ACL) ma pośredni dostęp do określonego elementu. Podmiot zabezpieczeń pośredni, czyli użytkownik, który przez dziedziczenie ACL, otrzymuje odmowę dostępu do określonego elementu,

Rysunek 1 pokazuje sposób użycia metody setInheritFrom() do dziedziczenia pośrednio dozwolonych i pośrednio niedozwolonych podmiotów zabezpieczeń.

Kontrolę dostępu przedstawiono na rys. 1:

• Użytkownik 1 jest bezpośrednio dozwolonym podmiotem zabezpieczeń elementu A.
• Użytkownik 2 jest bezpośrednio dozwolonym podmiotem zabezpieczeń produktu B.
• Element B dziedziczy listę kontroli dostępu (ACL) elementu A.

W zależności od kontroli dostępu reguły dostępu są:

• Użytkownika 1 nie trzeba wyraźnie określać jako podmiotu zabezpieczeń elementu B, aby być pośrednim dozwolonym podmiotem zabezpieczeń elementu B. Dostęp jest dziedziczony, ponieważ użytkownik 1 jest wymieniony jako bezpośrednio dozwolony podmiot zabezpieczeń elementu A, a element B dziedziczy swoją listę kontroli dostępu z elementu A.
• Użytkownik 2 nie jest pośrednim dozwolonym podmiotem zabezpieczeń elementu A.

Ustaw typ dziedziczenia

Jeśli ustawisz dziedziczenie za pomocą metody setInheritFrom(), musisz ustawić typ dziedziczenia za pomocą metody setInheritanceType(). Typ dziedziczenia określa, w jaki sposób lista kontroli dostępu (ACL) elementu podrzędnego łączy się z listą ACL elementu nadrzędnego. W obiekcie Acl.InheritanceType zaimplementowano 3 typy dziedziczenia:

• BOTH_PERMIT – ustaw typ dziedziczenia na BOTH_PERMIT, aby przyznać użytkownikowi dostęp do elementu tylko wtedy, gdy zarówno lista kontroli dostępu elementu podrzędnego, jak i odziedziczone listy kontroli dostępu elementu nadrzędnego zezwalają użytkownikowi na dostęp do danego elementu.

• CHILD_OVERRIDE – ustaw typ dziedziczenia na CHILD_OVERRIDE, aby wymusić, by lista kontroli dostępu elementu podrzędnego miała pierwszeństwo przed listą ACL odziedziczonego elementu nadrzędnego, gdy są one w konflikcie. Jeśli więc lista kontroli dostępu elementu nadrzędnego odmawia dostępu użytkownikowi jako odczytującego element, użytkownik nadal ma do niego dostęp, o ile ma dostęp do elementu podrzędnego jako czytelnik. I na odwrót, nawet jeśli lista kontroli dostępu (ACL) elementu nadrzędnego zapewnia dostęp użytkownikowi, nie ma on do niego dostępu, jeśli nie może odczytywać danych podrzędnych.

• PARENT_OVERRIDE – ustaw typ dziedziczenia na PARENT_OVERRIDE, aby wymusić, by lista kontroli dostępu elementu nadrzędnego miała pierwszeństwo przed listą kontroli dostępu elementu podrzędnego, gdy występuje konflikt. Jeśli więc lista kontroli dostępu elementu podrzędnego odmawia dostępu do elementu nadrzędnego jako odczytującego, użytkownik ten nadal ma do niego dostęp, o ile ma dostęp do elementu nadrzędnego jako czytelnik. I na odwrót, nawet jeśli lista kontroli dostępu (ACL) elementu podrzędnego przyznaje dostęp użytkownikowi, nie będzie on miał do niego dostępu, jeśli nie otrzymał odmowy dostępu do elementu nadrzędnego.

Podczas oceny łańcucha dziedziczenia ACL kolejność oceny może zmienić wynik decyzji dotyczącej autoryzacji. Cloud Search zapewnia kolejność oceny od liścia do roota w łańcuchach dziedziczenia ACL. W szczególności decyzje dotyczące listy kontroli dostępu (ACL) dotyczące łańcucha rozpoczynają się od oceny elementu podrzędnego z elementami nadrzędnymi i mogą przejść aż do poziomu głównego.

Jeśli na przykład element podrzędny ma typ dziedziczenia CHILD_OVERRIDE, a użytkownik ma dostęp do elementu podrzędnego, Dysk nie musi ocenić elementu nadrzędnego. Jeśli jednak element podrzędny ma PARENT_OVERRIDE lub BOTH_PERMIT, Dysk kontynuuje ocenianie dziedziczenia w dalszej części łańcucha.

Przechowywanie i usuwanie elementów

Podczas indeksowania elementu możesz oznaczyć go etykietą jako kontener, korzystając z metody setContainer() klasy IndexingItemBuilder. Relacja kontener/kontener określa fizyczną hierarchię elementów i dba o to, aby elementy były prawidłowo usuwane. Usunięcie kontenera powoduje też usunięcie zawartych w nim elementów.

Relacje kontenera są całkowicie niezależne od reguł dziedziczenia ACL. Na przykład plik w systemie plików może być zawarty w folderze w celu usunięcia, ale może dziedziczyć listę kontroli dostępu z innego folderu. Usunięcie folderu nie powoduje usunięcia elementów, które dziedziczą jego listę kontroli dostępu, chyba że elementy te znajdują się również w hierarchii tego folderu.

Kontrolę dostępu przedstawiono na rys. 2:

• Użytkownik 1 jest bezpośrednio dozwolonym podmiotem zabezpieczeń elementu A.
• Użytkownik 2 jest bezpośrednio dozwolonym podmiotem zabezpieczeń produktu B.
• Użytkownik 3 jest bezpośrednio dozwolonym podmiotem zabezpieczeń produktu C.
• Element C dziedziczy listę kontroli dostępu (ACL) elementu A.
• Element B określa jako kontener nazwę elementu A.
• Element C określa jako kontener element B.

W zależności od kontroli dostępu reguły dostępu są:

• Dostęp pośredni pochodzi z metody setInheritFrom(). Dlatego użytkownik 1 ma dostęp do elementu C, ponieważ element C dziedziczy listę kontroli dostępu do elementu A.
• Dostęp pośredni nie pochodzi z elementu C, który znajduje się w elemencie B. Dlatego użytkownik 2 nie ma dostępu do elementu C.

Oddzielenie dziedziczenia ACL od hierarchii obudowy pozwala modelować wiele różnych istniejących struktur.

Po usunięciu elementu:

• Każdy element zawierający usunięty element stanie się niedostępny do wyszukiwania i zostanie zaplanowany do usunięcia ze źródła danych Google.
• Nie będzie można wyszukać żadnego elementu, w przypadku którego określono usunięty element za pomocą metody setInheritFrom().

Jeśli zasób został usunięty przy użyciu metody setInheritFrom(), ale nie ma ustawionego kontenera za pomocą setContainer() lub jego hierarchia przechowywania nie zawiera usuniętych elementów, ten element wraz z jego danymi pozostanie w źródle danych Google. Za usunięcie elementu odpowiadasz.

Ilustracja 3 pokazuje, jak działa usuwanie w hierarchii elementów.

Kontrolę dostępu przedstawiono na rys. 3:

• Użytkownik 1 jest bezpośrednio dozwolonym podmiotem zabezpieczeń elementu A.
• Użytkownik 2 jest bezpośrednio dozwolonym podmiotem zabezpieczeń elementu D.
• Zarówno element D, jak i element E mają listę kontroli dostępu do elementu A.
• Element D określa jako kontener nazwę elementu A.
• Elementy A i E są elementami na poziomie głównym, ponieważ nie mają elementu kontenera.

Usuwa kaskadowo przez odwołania do kontenerów. Po usunięciu elementu A:

• Wszystkie elementy podrzędne pliku setInheritFrom() utracą dostęp do wszystkich użytkowników.
• Żaden użytkownik nie ma dostępu do elementu A.
• Element D został domyślnie usunięty. Żaden użytkownik nie ma dostępu do elementu D.
• Element E nie zostaje usunięty, ponieważ proces usuwania przebiega kaskadowo tylko przez odwołania do kontenera.
• Element E staje się nieosiągalny i żadni użytkownicy nie mogą go wyszukać.