Listy ACL mapy

Aby mieć pewność, że tylko użytkownicy z dostępem do elementu mogą go zobaczyć w wynikach wyszukiwania, indeksuj elementy za pomocą list kontroli dostępu (ACL) z repozytorium firmowego. Musisz modelować listy ACL repozytorium i uwzględniać je podczas indeksowania elementów w repozytorium. Pakiet SDK łącznika treści udostępnia bogaty zestaw metod ACL, które są wystarczająco zaawansowane, aby modelować listy ACL większości repozytoriów.

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

Tworzenie listy ACL

Tworzenie listy ACL to proces dwuetapowy:

1. Utwórz obiekt Principal za pomocą 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ówimy niektóre pojęcia, które musisz znać, aby modelować i tworzyć listy 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 adresem 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ą 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 zawierające identyfikatory zewnętrzne. W klasie ACL jest kilka innych metod statycznych, które służą 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 zewnętrznych identyfikatorów użytkowników lub grup z adresem e-mail Google można przeprowadzić za pomocą łącznika tożsamości. Więcej informacji o łącznikach tożsamości znajdziesz w artykule Tworzenie łącznika tożsamości.

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

Dziedziczenie listy ACL

Dziedziczenie listy ACL odnosi się do autoryzacji konkretnego elementu i konkretnego użytkownika na podstawie wyniku połączenia list ACL elementu i list ACL jego ł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średnio dozwolone podmioty zabezpieczeń i bezpośrednio odrzucone podmioty zabezpieczeń, określone za pomocą metod setReaders() i setDeniedReaders(). Bezpośredni dozwolony podmiot to użytkownik zidentyfikowany na liście ACL, który ma bezpośredni dostęp do konkretnego elementu. Bezpośrednio odrzucony podmiot to użytkownik zidentyfikowany w liście ACL jako niemający dostępu do określonego 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 to użytkownik, który dzięki dziedziczeniu listy ACL ma pośredni dostęp do określonego elementu. Pośrednio odrzucony podmiot zabezpieczeń to użytkownik, któremu odmówiono dostępu do określonego elementu z powodu dziedziczenia listy ACL.

Uwaga: jeśli dziedziczenie zostało skonfigurowane za pomocą metody setInheritFrom(), typ dziedziczenia musi zostać skonfigurowany za pomocą metody setInheritanceType(). Więcej informacji o typach dziedziczenia znajdziesz w artykule Ustawianie typu dziedziczenia.

Ilustracja 1 pokazuje, jak metoda setInheritFrom() jest używana do dziedziczenia pośrednio dozwolonych i pośrednio zabronionych podmiotów.

Rysunek 1. Metoda setInheritFrom()

Te ustawienia kontroli dostępu są przedstawione na rysunku 1:

• 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 kontroli dostępu obowiązują te reguły dostępu:

• Użytkownik 1 nie musi być wyraźnie określony jako podmiot zabezpieczeń elementu B, aby być pośrednim 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 z elementu A.
• Użytkownik 2 nie jest pośrednim dozwolonym podmiotem w przypadku 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 dziecka łączy się z listą ACL rodzica. 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 lista ACL elementu podrzędnego, jak i lista ACL dziedziczonego elementu nadrzędnego zezwalają temu użytkownikowi na dostęp do tego elementu.

• CHILD_OVERRIDE – ustaw typ dziedziczenia na CHILD_OVERRIDE, aby wymusić, aby lista ACL elementu podrzędnego miała pierwszeństwo przed odziedziczoną listą ACL elementu nadrzędnego w przypadku konfliktu. Jeśli lista ACL elementu nadrzędnego odmawia 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 lista ACL elementu nadrzędnego przyznaje użytkownikowi dostęp, nie będzie on miał dostępu, jeśli jest czytelnikiem z odmową dostępu do elementu podrzędnego.

• PARENT_OVERRIDE – ustaw typ dziedziczenia na PARENT_OVERRIDE, aby wymusić, aby lista ACL elementu nadrzędnego miała pierwszeństwo przed listą ACL elementu podrzędnego w przypadku konfliktu. Jeśli lista ACL elementu podrzędnego odmawia użytkownikowi dostępu jako czytelnikowi, użytkownik nadal ma dostęp, jeśli ma dostęp do elementu nadrzędnego jako czytelnik. Z drugiej strony, nawet jeśli lista ACL elementu podrzędnego przyznaje użytkownikowi dostęp, nie będzie on miał dostępu, jeśli jest czytelnikiem zablokowanym w elemencie nadrzędnym.

Podczas oceny łańcucha dziedziczenia listy ACL kolejność oceny może zmienić wynik decyzji o autoryzacji. Cloud Search zapewnia kolejność oceny od liścia do korzenia w przypadku łańcuchów dziedziczenia list kontroli dostępu. W szczególności decyzja ACL dotycząca łańcucha rozpoczyna się od oceny wydawcy podrzędnego i jego wydawców nadrzędnych i może obejmować wszystkich wydawców nadrzędnych aż po wydawcę nadrzędnego najwyższego poziomu.

Jeśli na przykład dziecko ma CHILD_OVERRIDEtyp dziedziczenia, a użytkownik ma dostęp do dziecka, Dysk nie musi sprawdzać rodzica. Jeśli jednak dziecko ma uprawnienia PARENT_OVERRIDE lub BOTH_PERMIT, Dysk kontynuuje ocenę dziedziczenia na wyższych poziomach.

Kwarantanna i usuwanie elementów

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

Relacje zawierania są całkowicie niezależne od reguł dziedziczenia list ACL. Na przykład plik w systemie plików może być zawarty w folderze w celu 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 zawierania folderu.

Te ustawienia kontroli dostępu przedstawiono na rysunku 2:

• 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 kontroli dostępu obowiązują te reguły dostępu:

• Dostęp pośredni pochodzi z metody setInheritFrom(). Użytkownik 1 może więc uzyskać dostęp do elementu C, ponieważ dziedziczy on 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 może uzyskać dostępu do elementu C.

Rysunek 2. Metoda setInheritFrom() w użyciu.

Oddzielenie dziedziczenia list ACL od hierarchii kontenerów 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ę niewyszukiwalny i jest zaplanowany do usunięcia ze źródła danych Google.
• Każdy element, w którym usunięty element został określony za pomocą metody setInheritFrom(), stanie się niedostępny do wyszukiwania.

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

Ilustracja 3 pokazuje przykład działania usuwania w przypadku hierarchii elementów.

Rysunek 3. Usuwanie elementu i dziedziczenie listy ACL.

Te ustawienia kontroli dostępu są przedstawione na rysunku 3:

• Użytkownik 1 jest bezpośrednim podmiotem uprawnionym do elementu A.
• Użytkownik 2 jest bezpośrednim dozwolonym podmiotem 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 najwyższego poziomu, ponieważ nie mają elementu kontenera.

Usuwanie kaskadowe odbywa się przez odwołania do kontenera. Gdy element A zostanie usunięty:

• Wszyscy potomkowie elementu setInheritFrom() tracą dostęp dla wszystkich użytkowników.
• Żaden użytkownik nie ma dostępu do elementu A.
• Element D jest usuwany w sposób dorozumiany. Żaden użytkownik nie ma dostępu do elementu D.
• Element E nie zostanie usunięty, ponieważ usunięcie jest kaskadowe tylko w przypadku odwołań do kontenera.
• Element E staje się niedostępny i żaden użytkownik nie może go wyszukać.