2009-05-05 10 views
18

Primero algunos antecedentes de mi pregunta.Seguridad (también conocido como Permisos) y Lucene - ¿Cómo? ¿Debería hacerse?

  • Las entidades individuales pueden haber leído Permisos.
  • Si un usuario falla lea, compruebe que no pueden ver esa instancia.

El problema se refiere a la introducción de Lucene y la realización de una búsqueda que simplemente devuelve una lista de instancias de entidades coincidentes. Mi código necesitaría filtrar entidades una a una. Este enfoque es extremadamente ineficiente, ya que existe la posibilidad de que un usuario solo pueda ver una pequeña minoría y comprobar que devolver muchos es menos que ideal.

¿Qué enfoques o cómo resolverán los desarrolladores este problema, teniendo en cuenta que la indexación y las búsquedas se realizan con Lucene?

EDIT

Definiciones

  • Un usuario puede pertenecer a varios grupos.
  • Un rol puede tener muchos grupos; estos pueden cambiar.
  • Un permiso tiene un rol - (direccionamiento indirecto).
  • X puede tener un Permiso de lectura.
  • Es posible que la definición de un Rol cambie en cualquier momento.

Indexing

  • Adición del conjunto de grupos (expansión de un Permmission) en tiempo de índice puede resultar en la definición convertirse fuera de sincronización cuando la lista de grupos de miembros para un cambio de función.
  • Espero no tener que reindexar X cada vez que cambie la definición de Permiso/Rol.

Control de seguridad

  • pasar una verificación de permiso de un usuario debe pertenecer a un grupo que se encuentra dentro del conjunto de grupos pertenecen a la función de un permiso dado.

Respuesta

7

Depende de la cantidad de grupos de seguridad diferentes que sean relevantes en su contexto y de cómo se aplica la seguridad a sus datos indexados.

Tuvimos un problema similar que resolvimos de la siguiente manera: Al indexar, agregamos los grupos permitidos al documento y al buscar agregamos una consulta booleana con los grupos de los que el usuario era miembro. Eso funcionó bien en nuestro escenario.

+0

Probablemente hicimos algo muy similar: los objetos indexados tienen grupos id: s con privilegios de lectura en un campo de metadatos: "G1, G6, G203" y las búsquedas solo están dirigidas con "contiene G1 o G70". También se extiende a los usuarios usando un prefijo diferente. – Manne

+0

Uso la misma idea, aquí está mi implementación concreta: http://lifeinide.blogspot.com/2013/02/lucene-permissions-and-hibernate-search.html –

3

Depende de su modelo de seguridad. Si los permisos son simples, digamos que tiene tres clases de documentos, probablemente sea mejor construir un índice de Lucene por clase por separado, y combinar los resultados cuando un usuario puede ver más de una clase. The Solr security Wiki sugiere algo similar a la sugerencia de HakonB: agregar las credenciales del usuario a la consulta y buscarlas. Véase también this discussion in the Lucene user group. Otra estrategia será ajustar la búsqueda de Lucene con una clase de seguridad separada que filtre filtros adicionales de Lucene. Puede ser más rápido si puede hacer esto usando una base de datos para los permisos.

Editar: Veo que tiene un sistema de permisos bastante complejo. Su elección de diseño básico es si implementarlo dentro de Lucene o fuera de Lucene. Mi consejo es utilizar Lucene como motor de búsqueda (su principal fortaleza) y usar otro sistema/aplicación para la seguridad. Si elige usar Lucene para la seguridad de todos modos, le sugiero que aprenda bien Lucene Filters y use un filtro de conjunto de bits para filtrar los resultados de una consulta. Tiene los problemas que enumera de tener que mantener los permisos actualizados.

+0

Agregaré más detalles a mi original q .. –

+0

Se agregaron detalles a mi respuesta original. HTH –

0

Como mencionó Yuval, podría valer la pena tener el mecanismo de permiso independiente del índice de lucene.

Una forma de hacerlo es implementar su propio Collector, que filtrará los resultados a los que el usuario no debería tener acceso.

0

Lo que yo sugiero es tener dos tipos de documentos:

1) Real_documents con un campo llamado: "DocumentID"

2) un documento de seguridad con campos: "Role", "Grupos" "Usuarios " "" "PermisionId DocumentsIds"

a continuación, un pseudo-código podrían ser:

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); 

Siendo que Lucene es muy rápido en la búsqueda de dos búsquedas son muy fáciles de hacer. De esta forma, también tiene un mejor tf-idf por usuario.

Cuestiones relacionadas