Cómo restringir o filtrar el acceso a la base de datos de acuerdo con los atributos del usuario de la aplicación

Question

He pensado demasiado en esto ahora sin una solución obviamente correcta. Puede ser una situación real de madera para los árboles, por lo que necesito la ayuda de stackoverflow.

Estoy tratando de aplicar el filtrado de la base de datos a nivel regional. Mi sistema tiene varios usuarios y cada uno está asignado a una oficina regional. Solo quiero que los usuarios puedan ver los datos asociados con su oficina regional.

En pocas palabras, mi aplicación es: Java App - > JPA (hibernar) - > MySQL

La base de datos contiene objetos de todas las regiones, pero solo quiero que los usuarios puedan manipular objetos de su propia región. He pensado en las siguientes formas de hacerlo:

1) modifique todas las consultas de la base de datos para que lean algo como select * from tablex where region = " myregion " ;. Esto es desagradable. No funciona bien con JPA, por ejemplo, el método entitymanager.find () solo acepta la clave primaria. Por supuesto, puedo volverme nativo, pero solo tengo que perder una declaración de selección y mi seguridad se dispara

2) use un proxy mysql para filtrar resultados. Funky, pero entonces el proxy mysql solo ve la llamada sin procesar y realmente no sabe cómo debería filtrarlos (es decir, a qué región pertenece el usuario que realizó esta solicitud). Ok, podría iniciar un proxy para cada región, pero comienza a complicarse un poco ...

3) use esquemas separados para cada región. sí, simple, estoy usando spring para poder usar RoutingDataSource para enrutar las solicitudes a través de la fuente de datos correcta (1 fuente de datos por esquema). Por supuesto, el problema ahora está en algún punto de la línea que voy a querer filtrar por región y alguna otra categoría. ohps.

4) ACL: no estoy muy seguro de esto. Si a hizo un select * de tablex; ¿filtraría silenciosamente los objetos para los que no tengo acceso o se lanzaría una gran cantidad de excepciones de acceso?

¿Pero estoy pensando demasiado en esto? Esto parece un problema realmente común. Debe haber alguna solución fácil que soy demasiado tonto para ver. Estoy seguro de que será algo cercano a / o en la base de datos, ya que desea filtrar lo más cerca posible de la fuente, pero ¿qué?

No parece ser una cuchara: cualquier enlace, palabras clave, ideas, sugerencias de productos comerciales / de código abierto serán realmente apreciadas. gracias.

Answer 1

Acabo de implementar algo similar (REALbasic hablando con MySQL) durante las últimas semanas para una extensión jerárquica de varias compañías a un paquete de contabilidad.

Hay un gran cuerpo de código existente que compone las sentencias SQL, por lo que tuvimos que vivir con eso y solo auditar mucho para asegurarnos de que las restricciones se incluyeron en cada tabla según corresponda. Uno de los problemas era búsquedas relacionadas donde las tablas de búsqueda normalmente solo se usaban en combinación con una tabla primaria, pero para algunas GUI de mantenimiento se cargaba la tabla de búsqueda en sí, directamente.

Existe el peligro de revelar información implícita, como revelar que Acme Pornstars es cliente de alguna división de la compañía ;-)

La única solución para esa parte fue la construcción cuidadosa de los diagramas de DB para mostrar todas las relaciones implícitas y un montón de código fuente de auditoría y grepping, con comentarios cuidadosos para indicar áreas que habían sido aceptadas por no necesitar restricciones adicionales.

El único patrón que se me ocurrió para hacer esto más generalizado en el futuro es, en lugar de búsquedas explícitas de tipo region = currentRegionVar, utilizando un ID de entidad arbitrario que es suministrado por una función global CurrentEntityForRole (" blah ").

Esta abstracción permite compartir algunos datos, así como implementar pseudoentidades que representan otros límites de restricción.

No sé lo suficiente sobre Java y Spring para poder decirlo, pero ¿hay alguna manera de usar las vistas para proporcionar una búsqueda de una sola clave, donde las vistas están restringidas por el filtro de región?

El deseo de proporcionar agregaciones y posible intercambio de datos fue la razón por la que no tomamos una ruta de base de datos separada.

Answer 2

Buena pregunta.

Parece que el # 1 es el mejor ya que es el más flexible.

La región es lo que estás filtrando hoy, pero mañana podría ser región + departamento + color de cabello.

Si comienza a dividir los datos demasiado, parece que se quedará atascado trabajando más de lo necesario para volver a unirlos todos para informar.

Answer 3

Estoy teniendo el mismo problema. Es difícil creer que una tarea tan común (filtrar una lista de entidades modelo basadas en el perfil del usuario) no tenga una forma, patrón o práctica recomendada 'estándar' para hacerlo.

He encontrado pgacl , un módulo PostgreSQL. Básicamente, haces tu consulta como lo harías normalmente, y luego agregas un predicado acl_access () para que funcione como filtro.

Quizás haya algo similar para MySQL.

Answer 4

Te sugiero que uses ACL. Es más flexible que otras opciones. Use Spring Security. Puede usarlo sin usar Spring Framework. Lea el tutorial de texto del enlace