Безопасность данных в наборах результатов из Elastic Search, Solr или

Question

Мне нужно добавить возможности полнотекстового поиска в мою существующую базу данных. Конечно, первый поворот - это что-то вроде Solr или Elastic Search. И точка блокировки, к которой я пришел, - это то, как безопасно отображать результаты, возвращаемые базовой поисковой системой (давайте подумаем о Solr или Elastic Search на данный момент, однако любые другие решения или механизмы, которые достигли этой точки, также приветствуются).

Сложный контекст заключается в том, что, например, в моей системе есть записи личного профиля, которые нужно проиндексировать. Одно из полей в личном кабинете - обратная связь менеджера. Обычно в системе это поле видимо только непосредственному руководителю сотрудника и более высокой иерархии, т. Е. «Менеджер» из другого филиала не сможет увидеть это поле. Однако я хочу, чтобы это поле можно было искать с помощью полнотекстового поиска, но только для людей, которые действительно могут его видеть.

Теперь я запрашиваю у Solr «тупой» (то есть строку запроса), и он возвращает мне N документов. Когда я возвращаю это конечному пользователю, я уберу поле «Отзыв менеджера», потому что конечный пользователь не является менеджером заданных людей, а просто наличие документа в наборе результатов уже свидетельствует о «глупых» парнях ...

Вопрос в том, что является подходящим подходом для обработки этого варианта использования? Можно ли подключить к Solr / ES собственный фильтр безопасности для выходов?

Предостережения:

• фильтрация только полей не работает из-за вышеупомянутого сценария

• фильтрация полных документов не будет работать из-за

  1. поисковая система не сообщает, какие поля совпадают - поэтому нет способа вручную отфильтровать набор результатов по полю http://elasticsearch -users.115913.n3.nabble.com / Best-way-to-return-which-field- matched-td2713071.html
  2. даже если это работает, удаление документов из набора результатов приведет к повреждению граней (например, количества совпадений по отделам), возвращаемых механизмом - мне придется либо пересчитывать фасеты вручную, либо они не будут совпадать с записями, отфильтрованными вручную, и будут показать, что я на самом деле не хочу показывать конечным пользователям

Answer 1

Может быть, это полезно для вас https://github.com/salyh/elasticsearch-security-plugin Это добавляет безопасность уровня документа кasticsearch.

"В настоящее время для аутентификации и авторизации на основе пользователей Kerberos / SPNEGO и NTLM поддерживаются через сторонние вафельные библиотеки (только на серверах Windows). Для серверов UNIX Kerberos / SPNEGO поддерживается через сборку tomcat в SPNEGO Valve (Работает с любой реализацией Kerberos. Для авторизации поддерживается Active Directory и универсальный LDAP). Также поддерживается аутентификация сертификата клиента PKI / SSL (КЛИЕНТ-CERT метод). SSL / TLS также поддерживается без аутентификации клиента.

Вы можете использовать этот плагин также без Kerberos / NTLM / PKI, но тогда доступна только аутентификация на основе хоста.

Начиная степерь реализованы два модуля безопасности:

Actionpathfilter: ограничить действия против Elasticsearch на грубом уровне, например, кому разрешено читать, писать и даже вызывать api-вызовы ADMIN rest api. Уровень безопасности документа (dls): ограничивать действия науровень документа, например, кому разрешено запрашивать какие поля в документе "

Answer 2

В Solr вы можете создавать multiValued поля. В вашем случае вы можете использовать его для хранения ненормализованных значений организационной структуры.

В описанном сценарии вы создадите многозначное поле ouId (Идентификатор организационной единицы) и сохраните идентификатор сотрудника и все родительские идентификаторы. Другими словами, вы сохраните разрешенных ouIds в этом поле.

В сценарии поиска вы будете использовать FilterQuery - fq фильтрация параметров по ouId менеджера.

Пример:

..&fq=ouId:12

, где 12 - идентификатор организационной единицы выбранного менеджера.