Aby mieć pewność, że tylko użytkownicy z dostępem do elementu będą mogli go zobaczyć w w wyniku wyszukiwania, musisz zindeksować elementy wraz z ich listami kontroli dostępu (ACL) z repozytorium firmy. Musisz modelować listy kontroli dostępu (ACL) swojego repozytorium. uwzględniania tych list kontroli dostępu podczas indeksowania elementów w repozytorium. Łącznik treści Pakiet SDK udostępnia bogaty zestaw metod ACL wystarczająco potężnych, aby modelować listy kontroli dostępu większość repozytoriów.
Tworzenie listy ACL
Tworzenie listy ACL jest procesem dwuetapowym:
- Utwórz
Principal
za pomocą metod statycznych ACL zajęcia. - Korzystanie z
Acl.Builder
do utworzenia listy kontroli dostępu (ACL) przy użyciu podmiotu zabezpieczeń.
W pozostałej części tego dokumentu omówiliśmy niektóre pojęcia, które musisz znać, aby móc tworzyć modele i tworzyć listy kontroli dostępu, np. dziedziczenie i przechowywanie.
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
adresu. Podczas indeksowania elementów repozytorium oprogramowanie sprzęgające treści może nie mieć tych
adresy e-mail. Pakiet Content Connector SDK umożliwia jednak korzystanie
external ID (identyfikator przyznający użytkownikowi lub grupie dostęp do elementów repozytorium).
adresu e-mail, aby zindeksować element. Użyj
getUserPrincipal()
lub
getGroupPrincpal()
do tworzenia podmiotów zabezpieczeń zawierających identyfikatory zewnętrzne. Istnieje kilka innych
metod statycznych w funkcji
ACL
klasa używana do tworzenia
Principal
obiektów.
Dziedziczenie ACL
Dziedziczenie ACL odnosi się do autoryzacji dla określonego elementu i użytkownika na podstawie kombinacji list kontroli dostępu dla elementu i Listy kontroli dostępu w łańcuchu dziedziczenia. Reguły, na podstawie których podjęto decyzję dotyczącą autoryzacji zależą od repozytorium i właściwości elementu.
Ustaw dziedziczenie
Każdy element może mieć podmioty zabezpieczeń z bezpośrednim zezwoleniem i podmioty zabezpieczeń bezpośrednich,
określony za pomocą funkcji
setReaders()
.
oraz
setDeniedReaders()
. Bezpośrednie dozwolone
podmiot zabezpieczeń to użytkownik zidentyfikowany na liście kontroli dostępu (ACL), która daje mu bezpośredni dostęp do
konkretnego elementu. Podmiot zabezpieczeń odmowy bezpośredniej to użytkownik określony na liście kontroli dostępu (ACL) jako niebędący
dostępu do konkretnego elementu.
Element może też dziedziczyć pośrednie dozwolone podmioty zabezpieczeń oraz
podmiotów zabezpieczeń odrzuconych pośrednio za pomocą metody
setInheritFrom()
.
. Podmiot zabezpieczeń dozwolony pośrednio to użytkownik, który przez dziedziczenie ACL
ma pośredni dostęp do konkretnego elementu. Podmiot zabezpieczeń odmowy pośredniej to użytkownik
którzy przez dziedziczenie ACL nie mają dostępu do określonego elementu.
Rysunek 1 pokazuje, jak
Metoda setInheritFrom()
służy do dziedziczenia pośrednich dozwolonych i pośrednich podmiotów zabezpieczeń.
![Rysowanie połączeń między elementami](https://developers.google.cn/static/cloud-search/images/inherit-from-SDK.png?authuser=8&hl=pl)
setInheritFrom()
.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żytkownik 1 nie musi być wyraźnie określony jako podmiot zabezpieczeń w przypadku pozycji B pośredni dozwolony podmiot zabezpieczeń produktu B; dostęp jest dziedziczony ponieważ użytkownik 1 jest wymieniony jako bezpośrednio dozwolony podmiot zabezpieczeń produktów A i B dziedziczy listę kontroli dostępu (ACL) z elementu A.
- Użytkownik 2 nie jest pośrednim dozwolonym podmiotem zabezpieczeń elementu A.
Ustaw typ dziedziczenia
Jeśli ustawisz dziedziczenie za pomocą parametru
setInheritFrom()
musisz ustawić typ dziedziczenia za pomocą metody
setInheritanceType()
. Typ dziedziczenia określa sposób
Lista ACL łączy się z listą kontroli dostępu swojej organizacji nadrzędnej. Acl.InheritanceType
implementuje 3 typy dziedziczenia:
BOTH_PERMIT
– ustaw typ dziedziczenia naBOTH_PERMIT
, aby przyznać dostęp użytkownikowi tylko wtedy, gdy lista kontroli dostępu (ACL) elementu podrzędnego i dziedziczona lista kontroli dostępu (ACL) elementu nadrzędnego i zezwolić mu na dostęp do tego elementu.CHILD_OVERRIDE
– ustaw typ dziedziczenia naCHILD_OVERRIDE
, aby wymusić stosowanie zasady przez wydawcę podrzędnego. listy ACL elementu nadrzędnego, aby mieć pierwszeństwo przed odziedziczoną listą ACL elementu nadrzędnego, gdy . Jeśli więc lista kontroli dostępu elementu nadrzędnego odmawia dostępu użytkownikowi jako użytkownik, któremu odmówiono odczytu, użytkownik nadal będzie miał dostęp, jeśli ma dostęp do konta podrzędnego jako czytelnik. I na odwrót, nawet jeśli lista kontroli dostępu (ACL) elementu nadrzędnego zapewnia dostęp do użytkownik nie będzie miał dostępu, jeśli odmówi dostępu do konta podrzędnego.PARENT_OVERRIDE
– ustaw typ dziedziczenia naPARENT_OVERRIDE
, aby wymusić stosowanie lista ACL elementu nadrzędnego ma pierwszeństwo przed listą ACL elementu podrzędnego, gdy . Jeśli więc lista kontroli dostępu elementu podrzędnego odmawia dostępu użytkownikowi w ramach do czytnika, użytkownik nadal będzie mieć dostęp, jeśli ma dostęp do elementu nadrzędnego jako . I odwrotnie, nawet jeśli lista kontroli dostępu (ACL) elementu podrzędnego przyznaje dostęp użytkownikowi, parametr użytkownik nie ma dostępu, jeśli nie ma uprawnień do odczytu elementu nadrzędnego.
Podczas oceny łańcucha dziedziczenia ACL może się zmienić kolejność ocen od wyniku wydania decyzji w sprawie upoważnienia. Cloud Search zapewnia dostęp na poziomie liścia do roota kolejność oceny łańcuchów dziedziczenia ACL. Konkretnie decyzja w sprawie kontroli dostępu (ACL) w przypadku łańcuszka rozpoczyna się od oceny dziecka wraz z rodzicami i może postępować aż do poziomu głównego.
Jeśli na przykład dziecko ma typ dziedziczenia CHILD_OVERRIDE
, a użytkownik
ma dostęp do elementu podrzędnego, Dysk nie musi przeprowadzać oceny konta nadrzędnego.
Jeśli jednak dziecko ma przypisane PARENT_OVERRIDE lub BOTH_PERMIT, Dysk będzie nadal działać.
na dokładniejszą ocenę dziedziczenia.
Przechowywanie i usuwanie elementów
Podczas indeksowania elementu możesz oznaczyć go etykietą kontenera za pomocą atrybutu
setContainer()
funkcji
IndexingItemBuilder
zajęcia. Relacja między kontenerem a kontenerem określa
hierarchię elementów i zapewnia ich prawidłowe usuwanie.
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 znajdować się w folderze na w celu usunięcia, ale odziedziczyć listę kontroli dostępu z innego folderu. Usunięcie nie usuwa elementów, które dziedziczą jego listę kontroli dostępu, chyba że te elementy też są w hierarchii zawartości 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
setInheritFrom()
. Dlatego użytkownik 1 ma dostęp do elementu C, ponieważ element C dziedziczy listę kontroli dostępu (ACL) 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.
![Rysowanie połączeń między elementami](https://developers.google.cn/static/cloud-search/images/doc-hierarchy-SDK.png?authuser=8&hl=pl)
setInheritFrom()
.Oddzielenie dziedziczenia ACL od hierarchii ograniczeń pozwala modelować w różnych istniejących strukturach.
Po usunięciu elementu:
- Element zawierający usunięty element staje się niedostępny do wyszukiwania i zostaje przeznaczone do usunięcia ze źródła danych Google.
- Każdy element, w którym określono usunięty element przy użyciu atrybutu
Metoda
setInheritFrom()
stanie się nie do wyszukania.
Jeśli zasób ma usunięty element przy użyciu
setInheritFrom()
, ale nie ma ustawionego kontenera ustawionego za pomocą
setContainer()
lub jego hierarchia ograniczeń nie zawiera żadnych usuniętych elementów, ten element i jego dane
wciąż pozostaje w źródle danych Google. Za usunięcie elementu odpowiadasz.
Ilustracja 3 pokazuje, jak działa usuwanie w hierarchii elementów.
![Rysowanie połączeń między elementami](https://developers.google.cn/static/cloud-search/images/doc-hierarchy-deletion-SDK.png?authuser=8&hl=pl)
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ą w kontenerze.
Usuwa kaskadowo przez odwołania do kontenerów. Po usunięciu elementu A:
- Wszystkie elementy potomne
setInheritFrom()
plik referencyjny utraci dostęp 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 został usunięty, ponieważ proces usuwania przebiega kaskadowo przez kontener. odwołania.
- Element E staje się nieosiągalny i żadni użytkownicy nie mogą go wyszukać.