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

Question

Сначала немного предыстории моего вопроса.

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

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

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

EDIT

Определения

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

Индексация

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

1) Реальные_документы с полем под названием: «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 для каждого пользователя.

Answer 4

Как упомянул Ювал, возможно, стоит иметь механизм разрешений, независимый от индекса люцена.

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