Безопасность (aka Разрешения) и Lucene - Как? Должно ли это быть сделано?

Вначале расскажу о моем вопросе.

Отдельные объекты могут читать Разрешения.
Если пользователь не может проверить проверку чтения, они не могут видеть этот экземпляр.

Задача связана с введением Lucene и выполнением поиска, который просто возвращает список совпадающих экземпляров сущностей. Затем мой код должен будет фильтровать объекты по одному. Этот подход крайне неэффективен, поскольку существует ситуация, когда пользователь может видеть только небольшое меньшинство и проверять многие, чтобы вернуть несколько, менее чем идеально.

Что подходит или как разработчики решат эту проблему - помня, что индексирование и поиск выполняются с использованием Lucene?

ИЗМЕНИТЬ

Определения

Пользователь может принадлежать многим группам.
В роли может быть много групп - это может измениться.
Разрешение имеет роль - (косвенность).
X может иметь разрешение на чтение.
Можно изменить определение роли в любое время.

Индексация

Добавление набора групп (расширение Permmission) во время индекса может привести к тому, что определение перестает синхронизироваться, когда меняется список групп-членов для ролей.
Я надеюсь избежать необходимости переиндексации X всякий раз, когда изменяется определение прав/роли.

Проверка безопасности

Чтобы пройти проверку прав, Пользователь должен принадлежать группе, входящей в набор групп, принадлежит роли для данного Разрешения.

Ответ 1

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

У нас была аналогичная проблема, которую мы решили следующим образом: при индексировании мы добавили разрешенные группы в документ, и при поиске мы добавили логический запрос с группами, в которых был пользователь. Это хорошо отразилось на нашем сценарии.

Ответ 2

Это зависит от вашей модели безопасности. Если разрешения просты - скажем, у вас есть три класса документов. Вероятно, лучше всего создать отдельный индекс Lucene для каждого класса и объединить результаты, когда пользователь может видеть более одного класса. В Wiki-интерфейсе Solr предлагается нечто похожее на предложение HakonB - добавление учетных данных пользователя к запросу и поиск по ним. См. Также это обсуждение в группе пользователей Lucene. Другая стратегия будет заключаться в том, чтобы обернуть поиск Lucene отдельным классом безопасности, который выполняет дополнительную фильтрацию из Lucene. Это может быть быстрее, если вы можете сделать это, используя базу данных для разрешений.

Изменить: Я вижу, что у вас довольно сложная система разрешений. Ваш основной выбор дизайна - реализовать его внутри Lucene или вне Lucene. Мой совет - использовать Lucene как поисковую систему (ее основную силу) и использовать другую систему/приложение для обеспечения безопасности. Если вы все равно решите использовать Lucene для обеспечения безопасности, я предлагаю вам хорошо изучить Lucene Filters и использовать фильтр битов для фильтрации результатов запроса, У него есть проблемы, которые вы указали из-за необходимости обновления разрешений.

Ответ 3

Как отметил Ювал, возможно, что механизм разрешения не зависит от индекса lucene.

Один из способов сделать это - реализовать собственный Collector, который отфильтрует результаты, которые пользователь не должен иметь доступ к.

Ответ 4

Я бы предположил, что у вас есть два вида документов:

1) Real_documents с полем, называемым "DocumentID"

2) Защищенный документ с полями: "Роль" "Группы" "Пользователи" "PermisionId" "DocumentsIds"

тогда псевдокод может быть:

   Field[] docIds =searcher.search("Users", "currentUser").getFields("DocumentIds");
   TermsFilter filter = new TermFilter();

   foreach(field:docIDs){
       filter.add(new Term(field.field(),field.text());
   }
   searcher.search(query.getWeight(searcher), filter, numberOfDocuments);

Быть тем, что Lucene очень быстро ищет два поиска, очень легко сделать. Таким образом, у вас также есть лучший tf-idf для каждого пользователя.