Разрешения/фильтрация SOLR в зависимости от прав доступа

Например, у меня есть документы A, B, C. Пользователь 1 должен иметь возможность видеть документы A, B. Пользователь 2 должен иметь возможность видеть документ C. Возможно ли это сделать в SOLR без фильтрации метаданными? Если я использую фильтр метаданных, каждый раз, когда есть права доступа, мне нужно переиндексировать.

[обновление 2/14/2012] К сожалению, в случае клиента часто происходят изменения. Данные конфиденциальны и обычно управляются только владельцами, которые являются внутренними пользователями. Тогда конкретный случай - они должны иметь возможность обмениваться этими документами с определенными внешними пользователями и определять уровни доступа для этих пользователей. И большую часть времени это задача adhoc, и не выявлено раньше времени.

Ответ 1

Я хотел бы предложить сохранить роли доступа (да, их множественное число) в качестве метаданных документа. Здесь обязательное поле access_roles является фасетным многозначным строковым полем.

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

Пользователь, владеющий документом, - это роль по умолчанию для этого документа.

Чтобы изменить роли доступа к документу, вы редактируете access_roles.

Когда Джейн ищет, роли запроса , принадлежащие, будут частью запроса. Solr будет извлекать только документы, соответствующие роли доступа пользователя.

Когда Джейн (user_jane), менеджер в офисе vienna (manager_vienna) выполняет поиск, выполните следующие действия:

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

который извлекает все документы, содержащие user_jane ИЛИ manager_vienna в access_roles; Doc1 и Doc2.

Когда Bob, (user_bob), член специальной команды (specia_team) выполняет поиск,

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

который извлекает для него Doc2.

Запросы, адаптированные из http://wiki.apache.org/solr/SimpleFacetParameters#Multi-Select_Faceting_and_LocalParams

Ответ 2

Возможно, вы захотите проверить уровень безопасности на уровне документа.

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

Ответ 3

Я думаю, что мой подход будет похож на @aitchnyu ответ. Однако я бы не использовал отдельных пользователей в метаданных. Если вы создаете группы для каждого документа, вам придется реиндексировать по соображениям безопасности реже.

Для данного документа у вас могут быть access_roles: group_1, group_3

Таким образом, group_1 и group_3 всегда сохраняют права на документ. Тем не менее, я могу варьировать группы, к которым принадлежит каждый пользователь, и соответствующим образом корректировать запрос.

Когда запрос генерируется, он всегда проходит как часть запроса, который пользователь группирует. Если я принадлежу к group_1 и group_2, мой запрос будет выглядеть так:

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

Так как группы динамически генерируются в запросе, я просто удаляю пользователя из группы, и когда выдается новый запрос, они больше не будут включать удаленную группу в запрос. Поэтому удаление пользователя из group_1 будет новым создавать запрос следующим образом:

q=mainquery
&fq=access_roles:group_2

Все документы, для которых требуется группа 1, больше не будут доступны пользователю.

Это позволяет сделать большинство изменений в режиме реального времени без необходимости переиндексации документов. Единственная причина, по которой вам придется переиндексировать по соображениям безопасности, - это если вы решили, что конкретная группа больше не должна иметь доступ к документу.

Во многих реальных сценариях это должно быть относительно необычным явлением. Скорее всего, HR-документы всегда будут доступны для отдела кадров, однако конкретный пользователь не всегда может быть частью группы HR.

Надеюсь, что это поможет.

Ответ 4

Вы можете реализовать свою модель безопасности, используя Solr PostFilter. Для получения дополнительной информации см. http://searchhub.org/2012/02/22/custom-security-filtering-in-solr/

Примечание. Вероятно, вы должны кэшировать свои права доступа, иначе производительность будет ужасной.

Ответ 5

Помня о том, что solr - это система поиска на основе чистого текста, система индексирования, чтобы облегчить быстрый поиск, вы не должны ожидать от него стилей стиля RDMS. solr не обеспечивает безопасность индексируемых документов, вы должны написать такую реализацию, если хотите. В этом случае у вас есть два варианта. 1) Просто проиндексируйте документы в solr и сохраните данные авторизации в RDBMS.Now запрос solr для поиска и получения возвращенных результатов. Теперь оставьте еще один запрос в DB для идентификаторов doc, возвращаемых solr, чтобы узнать, имеет ли пользователь доступ к ним или not.Filter из тех документов, на которые пользователь в действии не имеет доступа. Вы готовы! Но на самом деле, ваша проблема не начинается здесь. Предположим, что, если все результаты, возвращаемые solr, будут отфильтрованы? (Предполагая, что вы не получаете доступ ко всем документам за раз, значит, вы получаете результаты из 1000 лучших результатов только из набора результатов solr, иначе вы не можете быстро найти поиск). Вы должны снова запросить solr для следующей группы результатов и выполнить итерацию эти шаги, пока вы не получите достаточно результатов для отображения. 2) Второй подход к этому заключается в том, чтобы индексировать метаданные авторизации вместе с документом в solr.Same как aitchnyu объяснил. Но чтобы ответить на ваш запрос на совместное использование документов внешнему пользователю, наряду с информацией о группе и роли, вы индексируете эти внешние пользовательские userid в поле access_roles или вы можете просто добавить другое поле в вашу схему access_user. Теперь вы можете изменить поисковые запросы для внешнего доступа пользователей, чтобы включить поле access_user в свой запрос фильтра. например

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

Теперь самое главное - обновить индексированные документы. Нужно выполнять его утомительную задачу, но с тщательной обработкой и асинхронной обработкой вместе с функцией частичного обновления документа solrs (solr 4.0 = > ) вы можете достичь разумно хорошего TPS с помощью Solr. Если вы используете solr < 4.0, вы можете иметь отдельные системы для поиска и обновления и с полным вниманием использовать балансировщик нагрузки и основные стратегии репликации подчиненных, у вас будет улыбка на вашем лице!

Ответ 6

Нет встроенных механизмов для Solr, о которых я знаю, что позволит вам контролировать доступ к документам без сохранения прав в метаданных. Подход, описанный aitchnyu, кажется разумным, если вы держите его в качестве истинного уровня ролей и не назначаете определенные разрешения пользователю для документа. Таким образом, вы можете назначать роли пользователям, и это даст им возможность видеть документы в индексе. Конечно, вам все равно придется переделывать документы при изменении ролей, но, надеюсь, вы сможете определить большую часть необходимых ролей вперед, если время и уменьшить необходимость частого переиндексации.