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.

Uwaga: Content Connector SDK obsługuje listy ACL dla jednej domeny, ale nie obsługuje list ACL dla wielu domen. Nie możesz przyznać dostępu użytkownikom i grupom spoza organizacji. Wszystkie listy ACL odnoszące się do użytkowników lub grup spoza organizacji nie mają żadnego wpływu.

Tworzenie listy ACL

Utworzenie listy ACL to proces dwuetapowy:

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

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 były mapowane na adres 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.

Uwaga: użytkownicy nie widzą elementów w wynikach wyszukiwania, dopóki ich identyfikator zewnętrzny nie zostanie zsynchronizowany z kontem Google. Synchronizację tych identyfikatorów użytkowników lub grup zewnętrznych z adresem e-mail Google można wykonać za pomocą łącznika tożsamości. Więcej informacji o oprogramowaniu sprzęgającym tożsamości znajdziesz w artykule Tworzenie oprogramowania sprzęgającego tożsamości

Ostrzeżenie: po przemapowaniu tożsamości elementu na inną tożsamość musisz ponownie zindeksować elementy, aby nowa tożsamość zaczęła obowiązywać. Więcej informacji znajdziesz w artykule Przemapowanie tożsamości.

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 uprawnień 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.

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

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

Rysunek 1. Metoda setInheritFrom().

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ć wymieniony jako bezpośredni 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 reguły ACL elementu podrzędnego odmawiają użytkownikowi dostępu 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 ACL 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 kontenera 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 opcje dostępu 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.

Rysunek 2. Używana metoda setInheritFrom().

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 wskazywał usunięty element 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 elementu odpowiadasz Ty.

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

Rysunek 3. Usuwanie elementu i dziedziczenie listy ACL.

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ć.