Prawa SOLR/Filtrowanie wyników w zależności od praw dostępu

Question

Na przykład mam dokumenty A, B, C. Użytkownik 1 może tylko widzieć Dokumenty A, B. Użytkownik 2 może tylko zobaczyć Dokument C. Czy jest to możliwe zrobić to w SOLR bez filtrowania przez metadane? Jeśli korzystam z filtra metadanych, za każdym razem, gdy są zmiany w prawach dostępu, muszę ponownie zindeksować.

[aktualizacja 2/14/2012] Niestety, w przypadku klienta, zmiana jest częsta. Dane są poufne i zazwyczaj są zarządzane wyłącznie przez właścicieli, którzy są użytkownikami wewnętrznymi. W takim przypadku należy udostępnić te dokumenty niektórym użytkownikom zewnętrznym i określić poziomy dostępu dla tych użytkowników. I przez większość czasu jest to zadanie ad hoc, a nie identyfikowane z wyprzedzeniem.

Answer 1

Proponuję przechowywanie ról dostępu (tak, liczba mnoga) jako metadanych dokumentu. Tutaj wymagane pole access_roles jest polem o wielowartościowym łańcuchu wartości.

Doc1: access_roles:[user_jane, manager_vienna] // Jane and the Vienna branch manager may see it 
Doc2: access_roles:[user_john, manager_vienna, special_team] // Jane, the Vienna branch manager and a member of special team may see it 

Użytkownik posiadający dokument jest domyślna rola dostęp do tego dokumentu. Aby poprawić role dostępu do dokumentu, edytujesz access_roles.

---

Kiedy Jane przeszukuje role dostępu ona należy do będzie częścią zapytania. Solr pobierze tylko te dokumenty, które pasują do roli dostępu użytkownika.

Kiedy Jane (user_jane), kierownik w biurze Wiedeń (manager_vienna) wyszukiwania, jej wyszukiwania iść jak:

q=mainquery 
&fq=access_roles:user_jane 
&fq=access_roles:manager_vienna 
&facet=on 
&facet.field=access_roles 

który pobiera wszystkie dokumenty, które zawiera user_janeLUBmanager_vienna w access_roles; Doc1 i Doc2.

Kiedy Bob (user_bob), członek specjalnego zespołu (specia_team) wyszukiwania,

q=mainquery 
&fq=access_roles:user_bob 
&fq=access_roles:special_team 
&facet=on 
&facet.field=access_roles 

który pobiera Doc2 dla niego.

Zapytania adaptacją http://wiki.apache.org/solr/SimpleFacetParameters#Multi-Select_Faceting_and_LocalParams

Answer 2

Tam nie są wbudowane mechanizmy Solr, że zdaję sobie sprawę, że będzie można kontrolować dostęp do dokumentów bez zachowania prawa w metadanych. Podejście nakreślone przez aitchnyu wydaje się uzasadnione, jeśli utrzymujesz go na poziomie prawdziwej roli i nie przypisujesz uprawnień użytkownika do dokumentu. W ten sposób możesz przypisać role użytkownikom, a to pozwoli im widzieć dokumenty w indeksie. Oczywiście nadal będziesz potrzebował ponownie indeksować dokumenty, gdy role się zmienią, ale miejmy nadzieję, że będziesz w stanie zidentyfikować większość potrzebnych ról, jeśli zajdzie taka potrzeba, i zmniejszyć potrzebę częstego ponownego indeksowania.

Answer 3

Może zajść potrzeba sprawdzenia poprawek zabezpieczeń na poziomie dokumentu.

https://issues.apache.org/jira/browse/SOLR-1872
https://issues.apache.org/jira/browse/SOLR-1834

Answer 4

Myślę, że moje podejście byłoby podobne do użytkownika @ aitchnyu odpowiedź. Nie używałbym jednak indywidualnych użytkowników w metadanych. Jeśli utworzysz grupy dla każdego dokumentu, będziesz musiał rzadziej ponownie wyszukiwać ze względów bezpieczeństwa.

dla danego dokumentu, może mieć access_roles: group_1, group_3

W ten sposób group_1 i group_3 zawsze zachowują uprawnienia do dokumentu. Mogę jednak zmieniać grupy, do których należy każdy użytkownik i odpowiednio dostosowywać zapytanie.

Gdy zapytanie jest generowane, zawsze przekazuje jako część zapytania grupy użytkowników. Jeśli należę group_1 i group_2, moja kwerenda będzie wyglądać następująco:

q=mainquery 
&fq=access_roles:group_1 
&fq=access_roles:group_2 

Ponieważ grupy są generowane dynamicznie w zapytaniu, po prostu usunąć użytkownika z grupy, a kiedy nowe zapytanie zostało wydane, oni nie będzie już zawierać usuniętej grupy w zapytaniu. Więc usunięcie użytkownika z group_1 będzie nowy utworzyć kwerendę tak:

q=mainquery 
&fq=access_roles:group_2 

Wszystkie dokumenty, które wymagają grupy 1 nie będą już dostępne dla użytkownika.

To pozwala większość zmian zrobić w czasie rzeczywistym bez konieczności ponownego indeksowania dokumentów. Jedynym powodem, dla którego należy ponownie wykonać reindeks ze względów bezpieczeństwa, jest decyzja, że ​​dana grupa nie powinna już mieć dostępu do dokumentu.

W wielu rzeczywistych scenariuszach powinno to być stosunkowo rzadkie zjawisko. Wydaje się znacznie bardziej prawdopodobne, że dokumenty HR będą zawsze dostępne dla działu HR, jednak określony użytkownik może nie zawsze być częścią grupy HR.

Nadzieję, że pomaga.

Answer 5

Pamiętając o tym, że solr jest wyszukiwarką opartą na czystym tekście, systemie indeksowania, aby ułatwić szybkie wyszukiwanie, nie należy oczekiwać od niego możliwości stylu RDMS. Solr nie zapewnia bezpieczeństwa dla indeksowanych dokumentów, jeśli chcesz, musisz napisać taką implementację. W takim przypadku masz dwie opcje. 1) Po prostu zindeksuj dokumenty w Solr i przechowuj szczegóły autoryzacji w RDBMS. Teraz wyszukuj solr dla swojego wyszukiwania i zbieraj wyniki zwrócone. Teraz wywołaj zapytanie do DB dla dokumentów zwróconych przez solr, aby sprawdzić, czy użytkownik ma do nich dostęp lub nie. Wydrukuj te dokumenty, do których użytkownik w akcji nie ma dostępu. Skończyłeś! Ale nie do końca, twój problem zaczyna się tylko tutaj. Przypuśćmy, co jeśli wszystkie wyniki zwrócone przez solr zostaną odfiltrowane? (Zakładając, że nie uzyskujesz dostępu do wszystkich dokumentów na raz, oznacza to, że pobierasz najlepsze 1000 wyników tylko z zestawu wyników solr, w przeciwnym razie nie możesz uzyskać szybkiego wyszukiwania) Musisz ponownie zapytać solr dla następnej paczki zestawu wyników i musisz iterować wykonaj te kroki, aż uzyskasz wystarczającą liczbę wyników do wyświetlenia. 2) Drugie podejście do tego polega na indeksowaniu meta-danych autoryzacji wraz z dokumentem w solr.Same jak wyjaśnił aitchnyu. Ale aby odpowiedzieć na zapytanie o udostępnianie dokumentów użytkownikowi zewnętrznemu, wraz z grupą użytkowników i szczegółami roli, indeksuje się te zewnętrzne użytkownika. userid w polu access_roles lub możesz po prostu dodać inne pole do swojego schematu "access_user". Teraz możesz modyfikować zapytania dotyczące udostępniania zewnętrznego użytkownika, aby uwzględnić pole access_user w zapytaniu filtru. np

q=mainquery 
&fq=access_roles:group_1 
&fq=access_user:externaluserid 

Teraz najważniejszą rzeczą, aktualizacja do indeksowanego documents.Well jej z kursu żmudne zadanie, ale przy starannym projektowania i przetwarzania asynchronicznego wraz z solrs częściowej funkcji aktualizacji dokumentu (solr 4,0 =>), ty może osiągnąć względnie dobre TPS z solr. Jeśli używasz Solr < 4.0 możesz mieć osobne systemy zarówno do wyszukiwania, jak i aktualizacji oraz z pełnym wykorzystaniem mechanizmów równoważenia obciążenia i master slave, które będziesz uśmiechał się na twarzy!

Answer 6

Możesz zaimplementować swój model zabezpieczeń za pomocą funkcji PostFilter Solr. Aby uzyskać więcej informacji, zobacz: http://searchhub.org/2012/02/22/custom-security-filtering-in-solr/

Uwaga: prawdopodobnie powinieneś buforować swoje prawa dostępu, w przeciwnym razie wydajność będzie straszna.