Listy ACL mapy

Aby mieć pewność, że tylko użytkownicy z dostępem do danego produktu mogą go zobaczyć w wynikach wyszukiwania, należy zindeksować produkty z listami kontroli dostępu (ACL) z repozytorium korporacyjnego. Musisz modelować uprawnienia ACL w swoim repozytorium i uwzględniać je podczas indeksowania elementów w repozytorium. Pakiet SDK Content Connector udostępnia bogaty zestaw metod ACL, które są wystarczająco wydajne, aby modelować listy kontroli dostępu (ACL) większości repozytoriów.

Tworzenie listy ACL

Utworzenie reguły dostępu to proces dwuetapowy:

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

W pozostałej części tego dokumentu omówiono pojęcia, które musisz znać, aby modelować i tworzyć listy ACL, np. dziedziczenie i zawieranie.

Tworzenie podmiotu za pomocą identyfikatora zewnętrznego

Google Cloud Search wymaga, aby użytkownicy i grupy rozwiązywali się do adresu e-mail Google. Podczas indeksowania elementów repozytorium łączniki treści mogą nie mieć tych adresów e-mail. Pakiet SDK Content Connector umożliwia jednak indeksowanie elementów za pomocą dowolnego identyfikatora zewnętrznego (identyfikatora przyznającego użytkownikowi lub grupie dostęp do elementów repozytorium) zamiast adresu e-mail. Aby utworzyć podmioty zawierające identyfikatory zewnętrzne, użyj metody getUserPrincipal() lub getGroupPrincpal(). W klasie ACL jest kilka innych statycznych metod służących do tworzenia obiektów Principal.

Dziedziczenie listy ACL

Przekazywanie list kontroli dostępu odnosi się do autoryzacji dotyczącej konkretnego elementu i konkretnego użytkownika na podstawie kombinacji list kontroli dostępu elementu i list kontroli dostępu z łańcucha dziedziczenia. Reguły używane do podejmowania decyzji o autoryzacji zależą od repozytorium i właściwości elementu.

Ustawianie dziedziczenia

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(). Bezpośredni podmiot upoważniony to użytkownik zidentyfikowany na liście ACL, który ma bezpośredni dostęp do konkretnego elementu. Bezpośredni podmiot odmowy to użytkownik zidentyfikowany w pliku ACL jako niemający dostępu do określonego elementu.

Element może też dziedziczyć bezpośrednie podmioty zabezpieczeń z dostępem i bezpośrednie podmioty zabezpieczeń z odmową za pomocą metody setInheritFrom(). Bezpośredni pełnomocnik to użytkownik, który dzięki dziedziczeniu listy ACL ma pośredni dostęp do określonego elementu. Podmiot zabezpieczeń z odmową pośrednią to użytkownik, któremu z powodu dziedziczenia reguł ACL odmówiono dostępu do określonego elementu.

Rysunek 1 pokazuje, jak metoda setInheritFrom() jest używana do dziedziczenia pośrednich dozwolonych i pośrednich zablokowanych podmiotów.

Rysunek 1 przedstawia te elementy kontroli dostępu:

• Użytkownik 1 jest bezpośrednim upoważnionym podmiotem w przypadku elementu A.
• Użytkownik 2 jest bezpośrednim upoważnionym podmiotem w przypadku elementu B.
• Obiekt B dziedziczy listę ACL obiektu A.

Na podstawie kontroli 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ł pośrednio dozwolonym podmiotem zabezpieczeń elementu B. Dostęp jest dziedziczony, ponieważ użytkownik 1 jest wymieniony jako bezpośredni dozwolony podmiot zabezpieczeń elementu A, a element B dziedziczy listę kontroli dostępu od elementu A.
• Użytkownik 2 nie jest pośrednim upoważnionym podmiotem w przypadku elementu A.

Ustawianie typu dziedziczenia

Jeśli dziedziczenie zostało skonfigurowane za pomocą metody setInheritFrom(), musisz ustawić typ dziedziczenia za pomocą metody setInheritanceType(). Typ dziedziczenia określa sposób, w jaki lista ACL obiektu podrzędnego jest łączona z listą ACL obiektu nadrzędnego. Klasa 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 ACL elementu podrzędnego, jak i odziedziczony ACL elementu nadrzędnego zezwalają temu użytkownikowi na dostęp do tego elementu.

• CHILD_OVERRIDE – ustaw typ dziedziczenia na CHILD_OVERRIDE, aby wymusić, aby ACL elementu podrzędnego miał pierwszeństwo przed ACL elementu nadrzędnego w przypadku konfliktu. Jeśli więc reguły ACL elementu nadrzędnego odmawiają użytkownikowi dostępu jako czytelnikowi, użytkownik nadal ma dostęp, jeśli ma dostęp do elementu podrzędnego jako czytelnik. Z drugiej strony, nawet jeśli ACL elementu nadrzędnego przyznaje użytkownikowi dostęp, użytkownik nie będzie mieć dostępu, jeśli nie ma on uprawnień do odczytu elementu podrzędnego.

• PARENT_OVERRIDE – ustaw typ dziedziczenia na PARENT_OVERRIDE, aby wymusić, aby ACL elementu nadrzędnego miał pierwszeństwo przed ACL elementu podrzędnego w przypadku konfliktu. Jeśli więc ACL elementu podrzędnego odmawia dostępu użytkownikowi jako odbiorcy, użytkownik nadal ma dostęp, jeśli ma dostęp do elementu nadrzędnego jako odbiorca. Z drugiej strony, nawet jeśli ACL elementu podrzędnego przyznaje użytkownikowi dostęp, użytkownik nie będzie mieć dostępu, jeśli nie ma on uprawnień do odczytu elementu nadrzędnego.

Podczas oceny łańcucha dziedziczenia zasad dostępu kolejność oceny może zmienić wynik decyzji autoryzacyjnej. Cloud Search stosuje kolejność od elementu do korzenia w przypadku łańcuchów dziedziczenia list kontroli dostępu. Konkretnie decyzja dotycząca listy ACL dla łańcucha zaczyna się od oceny elementu podrzędnego i jego elementów nadrzędnych, a może sięgać aż do elementu nadrzędnego wyższego poziomu.

Jeśli na przykład element podrzędny ma typ dziedziczenia CHILD_OVERRIDE, a użytkownik ma dostęp do tego elementu, Dysk nie musi sprawdzać elementu nadrzędnego. Jeśli jednak dziecko ma uprawnienia PARENT_OVERRIDE lub BOTH_PERMIT, Drive będzie kontynuować sprawdzanie dziedziczenia w łańcuchu.

Blokowanie i usuwanie elementów

Podczas indeksowania elementu możesz oznaczyć go jako kontener, używając metody setContainer() klasy IndexingItemBuilder. Relacja kontener/element definiuje fizyczną hierarchię elementów i zapewnia, że są one prawidłowo usuwane. Gdy usuniesz kontener, zostaną też usunięte znajdujące się w nim elementy.

Relacje kontenerowania są całkowicie niezależne od reguł dziedziczenia ACL. Przykładowo plik w systemie plików może być zawarty w folderze na potrzeby usunięcia, ale 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 kontenera folderu.

Te elementy sterujące dostępem są przedstawione na rysunku 2:

• Użytkownik 1 jest bezpośrednim upoważnionym podmiotem w przypadku elementu A.
• Użytkownik 2 jest bezpośrednim upoważnionym podmiotem w przypadku elementu B.
• Użytkownik 3 jest bezpośrednim upoważnionym podmiotem w przypadku 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 kontroli dostępu reguły dostępu są następujące:

• Dostęp pośredni pochodzi z metody setInheritFrom(). Dlatego użytkownik 1 ma dostęp do elementu C, ponieważ element C dziedziczy listę ACL elementu A.
• Dostęp pośredni nie wynika z tego, że element C jest zawarty w elemencie B. Dlatego użytkownik 2 nie ma dostępu do elementu C.

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

Gdy element zostanie usunięty:

• Każdy element, który zawierał usunięty element, staje się niedostępny w wynikach wyszukiwania i jest zaplanowany do usunięcia ze źródła danych Google.
• Żaden element, który zawiera usunięty element zdefiniowany za pomocą metody setInheritFrom(), nie będzie możliwy do wyszukania.

Jeśli zasób zawiera element usunięty za pomocą metody setInheritFrom(), ale nie ma zbioru kontenera za pomocą metody setContainer() lub jego hierarchia zawierających nie zawiera usuniętych elementów, ten element i jego dane pozostają w źródle danych Google. Za usunięcie produktu odpowiadasz Ty.

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

Te elementy sterujące dostępem są pokazane na rysunku 3:

• Użytkownik 1 jest bezpośrednim upoważnionym podmiotem w przypadku elementu A.
• Użytkownik 2 jest bezpośrednim upoważnionym podmiotem w przypadku elementu D.
• Element D i element E dziedziczą listę ACL elementu A.
• Element D wskazuje element A jako swój kontener.
• Elementy A i E są elementami na poziomie wyższym, ponieważ nie mają elementu kontenera.

Usuwanie w ramach łańcucha odniesień do kontenera. Gdy element A zostanie usunięty:

• Wszystkie elementy potomne odwołania setInheritFrom() tracą dostęp dla wszystkich użytkowników.
• Żaden użytkownik nie ma dostępu do elementu A.
• Element D zostaje usunięty. Żaden użytkownik nie ma dostępu do elementu D.
• Element E nie jest usuwany, ponieważ usunięcie odbywa się tylko w odniesieniu do odwołań do kontenera.
• Element E staje się niedostępny i żaden użytkownik nie może go wyszukać.