Listy ACL mapy

Aby mieć pewność, że tylko użytkownicy z dostępem do danego elementu będą mogli go zobaczyć w wynikach wyszukiwania, indeksuj elementy za pomocą ich list kontroli dostępu z repozytorium Enterprise. Musisz modelować listy kontroli dostępu (ACL) swojego repozytorium i uwzględniać je podczas indeksowania elementów w repozytorium. Pakiet SDK oprogramowania sprzęgającego Content udostępnia obszerny zestaw metod ACL, które są wystarczające do modelowania list kontroli dostępu większości repozytoriów.

Uwaga: pakiet SDK Content Connector obsługuje listy kontroli dostępu (ACL) dla jednej domeny, ale nie między domenami. Nie możesz przyznać dostępu użytkownikom ani grupom spoza organizacji. Wszelkie listy kontroli dostępu (ACL) odwołujące się do użytkowników lub grup spoza organizacji nie mają żadnego efektu.

Utwórz listę kontroli dostępu

Tworzenie listy kontroli dostępu to proces dwuetapowy:

1. Utwórz Principal przy użyciu metod statycznych w klasie ACL.
2. Użyj klasy Acl.Builder do utworzenia listy kontroli dostępu przy użyciu podmiotu zabezpieczeń.

W pozostałej części tego dokumentu omawiamy pewne pojęcia, które warto znać, aby modelować i tworzyć listy kontroli dostępu. Dotyczy to m.in. dziedziczenia i izolacji.

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. Pakiet SDK Content Connector SDK umożliwia jednak indeksowanie elementu za pomocą dowolnego identyfikatora zewnętrznego (identyfikatora, który przyznaje użytkownikowi lub grupie dostęp do elementów repozytorium) zamiast adresu e-mail. Aby utworzyć podmioty zabezpieczeń zawierające identyfikatory zewnętrzne, użyj metody getUserPrincipal() lub getGroupPrincpal(). W klasie ACL jest kilka innych metod statycznych używanych do tworzenia obiektów Principal.

Uwaga: użytkownicy nie będą widzieć elementów w wynikach wyszukiwania, dopóki ich zewnętrzny identyfikator nie zostanie zsynchronizowany z kontem Google. Takie zewnętrzne identyfikatory użytkowników lub grup można zsynchronizować z adresem e-mail Google za pomocą oprogramowania sprzęgającego tożsamości. Więcej informacji o oprogramowaniu sprzęgającym tożsamości znajdziesz w artykule na temat tworzenia oprogramowania sprzęgającego tożsamości.

Ostrzeżenie: po zmapowaniu tożsamości elementu na inną tożsamość musisz ponownie zindeksować elementy, aby nowa tożsamość miała zastosowanie. Więcej informacji znajdziesz w artykule na temat zmieniania mapowania tożsamości.

Dziedziczenie ACL

Dziedziczenie ACL odnosi się do autoryzacji dla określonego elementu i użytkownika na podstawie wyniku kombinacji list kontroli dostępu elementu i list kontroli dostępu jego łańcucha dziedziczenia. Reguły używane do podejmowania decyzji o autoryzacji zależą od repozytorium i właściwości elementu.

Ustaw dziedziczenie

Każdy element może mieć bezpośrednie dozwolone podmioty zabezpieczeń i bezpośrednio odrzucone podmioty zabezpieczeń określone za pomocą metod setReaders() i setDeniedReaders(). Podmiot zabezpieczeń dozwolony bezpośrednio to użytkownik określony na liście kontroli dostępu (ACL), który daje mu bezpośredni dostęp do określonego elementu. Podmiot zabezpieczeń bezpośrednia to użytkownik określony na liście kontroli dostępu (ACL) jako nieposiadający dostępu do określonego elementu.

Element może też dziedziczyć Podmioty zabezpieczeń dozwolone pośrednio i Podmioty zabezpieczeń pośrednio odrzucone za pomocą metody setInheritFrom(). Podmiot zabezpieczeń dozwolony pośrednio to użytkownik, który przez dziedziczenie ACL ma pośredni dostęp do określonego elementu. Podmiot zabezpieczeń pośredniej odmowy to użytkownik, który przez dziedziczenie ACL odmawia dostępu do określonego elementu.

Uwaga: jeśli ustawisz dziedziczenie za pomocą metody setInheritFrom(), musisz ustawić typ dziedziczenia za pomocą metody setInheritanceType(). Informacje o typach dziedziczenia znajdziesz w artykule Ustawianie typu dziedziczenia.

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

Rysunek 1. Metoda setInheritFrom().

Kontrole dostępu zostały przedstawione na ilustracji 1:

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

W zależności od ustawień dostępu reguły dostępu są następujące:

• Użytkownik 1 nie musi być wyraźnie określony jako podmiot zabezpieczeń elementu B, aby być dozwolonym pośrednim podmiotem zabezpieczeń elementu B. Dostęp jest dziedziczony, ponieważ użytkownik 1 jest wymieniony jako dozwolony podmiot zabezpieczeń elementu A i element B dziedziczy listę kontroli dostępu z elementu A.
• Użytkownik 2 nie jest dozwolonym pośrednim 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 elementu podrzędnego jest łączona z listą kontroli dostępu elementu nadrzędnego. Acl.InheritanceType implementuje 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 (ACL) elementu podrzędnego, jak i dziedziczona lista kontroli dostępu elementu nadrzędnego (ACL) umożliwiają mu dostęp do tego elementu.

• CHILD_OVERRIDE – ustaw typ dziedziczenia na CHILD_OVERRIDE, aby lista kontroli dostępu elementu podrzędnego miała pierwszeństwo przed listą kontroli dostępu odziedziczonego elementu nadrzędnego, w przypadku konfliktu między nimi. Jeśli więc lista kontroli dostępu (ACL) elementu nadrzędnego odmówi przyznania użytkownikowi dostępu w roli odczytującego, użytkownik nadal będzie miał dostęp, jeśli ma dostęp do elementu podrzędnego jako odczytujący. I na odwrót: nawet jeśli lista kontroli dostępu (ACL) elementu nadrzędnego przyznaje dostęp użytkownikowi, nie ma on dostępu, jeśli osoba ta została odrzucona jako odczytujący element podrzędny.

• PARENT_OVERRIDE – ustaw typ dziedziczenia na PARENT_OVERRIDE, aby lista kontroli dostępu elementu nadrzędnego miała pierwszeństwo przed listą kontroli dostępu elementu podrzędnego, w przypadku wystąpienia konfliktu. Jeśli więc lista kontroli dostępu elementów podrzędnych odmówi przyznania użytkownikowi dostępu jako odczytującego, użytkownik nadal ma dostęp, jeśli ma dostęp do elementu nadrzędnego jako odczytujący. I na odwrót: nawet jeśli lista kontroli dostępu (ACL) elementu podrzędnego przyzna dostęp użytkownikowi, nie będzie on miał dostępu, jeśli zostanie zablokowany jako odczytujący element nadrzędny.

Podczas oceny łańcucha dziedziczenia ACL kolejność oceny może zmienić wynik decyzji dotyczącej autoryzacji. Cloud Search udostępnia łańcuchy dziedziczenia ACL od liści do roota. W szczególności decyzja ACL dotycząca łańcucha rozpoczyna się od oceny elementu podrzędnego wraz z jego elementami nadrzędnymi i może przechodzić 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 oceniać elementu nadrzędnego. Jeśli jednak element podrzędny ma ustawienie PARENT_OVERRIDE lub BOTH_PERMIT, Dysk będzie dalej oceniać dziedziczenie na dalszych etapach łańcucha.

Przechowywanie i usuwanie elementów

Podczas indeksowania elementu możesz oznaczyć go jako kontener za pomocą metody setContainer() klasy IndexingItemBuilder. Relacja kontener/element zawartości określa fizyczną hierarchię elementów i zapewnia ich prawidłowe usuwanie. Po usunięciu kontenera usunięte zostaną również jego elementy.

Relacje i reguły są całkowicie niezależne od reguł dziedziczenia ACL. Na przykład plik w systemie plików może być zawarty w folderze na potrzeby usunięcia, ale będzie 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 znajdują się one również w hierarchii izolacji folderu.

Kontrole dostępu zostały przedstawione na ilustracji 2:

• Użytkownik 1 jest bezpośrednio dozwolonym podmiotem zabezpieczeń elementu A.
• Użytkownik 2 jest bezpośrednio dozwolonym podmiotem zabezpieczeń elementu B.
• Użytkownik 3 jest bezpośrednim dozwolonym podmiotem zabezpieczeń elementu C.
• Element C dziedziczy listę kontroli dostępu elementu A.
• Element B nadaje nazwę elementowi A jako kontener.
• Element C nadaje nazwę elementowi B jako kontener.

W zależności od ustawień dostępu reguły dostępu są następujące:

• Dostęp pośredni jest uzyskiwany za pomocą metody setInheritFrom(). Dlatego użytkownik 1 ma dostęp do elementu C, ponieważ element C dziedziczy listę kontroli dostępu elementu A.
• Dostęp pośredni nie wynika z tego, że element C znajduje się w elemencie B. Dlatego użytkownik 2 nie ma dostępu do elementu C.

Rysunek 2. Używana metoda setInheritFrom().

Oddzielenie dziedziczenia ACL od hierarchii izolacji umożliwia modelowanie wielu różnych istniejących struktur.

Po usunięciu elementu:

• Każdy element zawierający usunięty element staje się niedostępny do wyszukiwania i zaplanowany do usunięcia ze źródła danych Google.
• Każdy element, w którym określono usunięty element przy użyciu metody setInheritFrom(), przestaje być dostępny do przeszukiwania.

Jeśli zasób ma element usunięty za pomocą metody setInheritFrom(), ale nie ma zbioru kontenerów za pomocą setContainer() lub jego hierarchia przechowywania nie zawiera żadnych usuniętych elementów, ten element i jego dane pozostaną w źródle danych Google. Ponosisz odpowiedzialność za usunięcie tego elementu.

Rysunek 3 przedstawia przykład działania usuwania w hierarchii elementów.

Rysunek 3. Usunięcie elementu i dziedziczenia ACL.

Kontrole dostępu zostały przedstawione na ilustracji 3:

• Użytkownik 1 jest bezpośrednio dozwolonym podmiotem zabezpieczeń elementu A.
• Użytkownik 2 jest bezpośrednio dozwolonym podmiotem zabezpieczeń elementu D.
• Elementy D i E dziedziczą listę kontroli dostępu elementu A.
• Element D nadaje nazwę elementowi A jako kontener.
• Elementy A i E to elementy na poziomie głównym, ponieważ nie zawierają elementu kontenera.

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

• Wszystkie elementy potomne pliku referencyjnego setInheritFrom() utracą dostęp dla 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 zostanie usunięty, ponieważ usunięcie jest realizowane kaskadowo przez odwołania do kontenerów.
• Element E staje się nieosiągalny i żaden użytkownik nie może wyszukać elementu E.