Listy ACL mapy

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:

  1. Utwórz Principal za pomocą metod statycznych ACL zajęcia.
  2. 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ą funkcji 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
Rysunek 1. Metoda 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 na BOTH_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 na CHILD_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 na PARENT_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
Rys. 2. Używana metoda 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
Rysunek 3. Usuwanie elementu i dziedziczenia ACL.

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