(software personalizado) Reglas de seguridad en cada registro cuando se usan grupos de usuarios por aplicación

4

Estoy trabajando con software personalizado aquí, así que no te preocupes por lo que sea Microsoft, abre cualquier cosa o cualquier otra cosa. Apeguémonos a la teoría de cómo esto debe ir unido.

Digamos que tengo un sistema de usuario / base de datos.

La base de datos tiene una tabla de usuarios y sus grupos de usuarios asociados (administrador, soporte de TI, administrador, secretario, cliente, invitado). Estos no son jerárquicos, sino membresías a grupos. Por ejemplo, Alice puede ser administrador y cliente si es necesario.

Los permisos para una aplicación se asignan al grupo, y en el caso de la asignación de múltiples grupos a un usuario, los permisos forman un simple OR binario de derechos (es decir, Admin tiene X, Guest tiene Y, luego el usuario obtiene X e Y).

Las aplicaciones son una forma de hacer las cosas en una aplicación, impiden el acceso o lo permiten. Por ejemplo, tiene acceso a "StackExchange" pero solo a Lectura, o tiene acceso a herramientas de publicación, moderador, etc.

Entonces, para recapitular, los usuarios obtienen grupos que rigen a qué derechos pueden acceder.

El concepto con el que estoy teniendo problemas es bloquear registros específicos para el grupo de usuarios, especialmente si estamos trabajando en varias aplicaciones. Entonces, por ejemplo, solo el grupo de administradores puede ver algunas publicaciones en la aplicación "StackExchange".

No quiero tener que agregar derechos a cada registro, y no quiero hacer un código de aplicación redundante con un cambio menor.

¿Cómo abordaría esto?

    
pregunta Incognito 29.04.2011 - 18:12
fuente

3 respuestas

3

Además de las ACL, otro enfoque común es utilizar reglas. Por lo tanto, no define los derechos por nivel de registro, sino según las características de los registros.

BaseRight : leer publicaciones

Reglas : publicaciones con x upvotes, publicación creada por el usuario actual, todas las publicaciones

Esas reglas consisten en un nombre y alguna lógica de programa. Pueden ser muy flexibles, por ejemplo fragmentos de consultas SQL. En el software que desarrollo en el trabajo, incluso los administradores pueden definir nuevas reglas.

Los derechos reales ahora son una combinación de derechos base y reglas con parámetros opcionales.

Recomiendo que se omita el acceso y evite los derechos negativos, ya que hace que la implementación sea mucho más fácil y, por lo tanto, menos la eliminación de errores: simplemente puede iterar sobre todas las reglas y tan pronto como una regla diga "bien", habrá terminado. . Por razones obvias, se debe tener especial cuidado cuando esto se hace en SQL, pero la mejora del rendimiento en consultas con grandes conjuntos de resultados puede valer la pena.

Ejemplos

Por ejemplo, el pseudo rol de usuario anónimo puede hacer esto correctamente:

Derecha : lee publicaciones de alta calidad basadas en

  • BaseRight: leer publicaciones
  • Reglas: publicaciones con x upvotes
  • Parámetro: x = 3

Un administrador del sitio obtendrá este derecho:

Derecha : lee todas las publicaciones basadas en

  • BaseRight: leer publicaciones
  • Reglas: todas las publicaciones
respondido por el Hendrik Brummermann 30.04.2011 - 12:48
fuente
2

Parece que desea tener algunos registros restringidos a ciertos grupos y algunos (¿la mayoría?) registros sin restricciones.

Como otra forma de decir sin restricciones es 'todos tienen acceso', parece que necesita agregar el concepto de un grupo llamado 'todos', al que pertenecen todos los usuarios del sistema.

Luego, puede permitir explícita o implícitamente que los registros no restringidos sean accesibles para el grupo de "todos".

    
respondido por el frankodwyer 29.04.2011 - 18:55
fuente
1

No estoy seguro de que haya algún problema para tener una tabla de permisos por recurso.

  1. Tener una tabla de recursos que está indexada por un ID de recurso.
  2. Tener una tabla de roles indexada por un id de rol.
  3. Tener una tabla de usuarios indexada por un ID de usuario.
  4. Tenga una tabla de permisos que haga referencia a las claves anteriores.

Añade algo de sobrecarga, pero con los tipos de datos correctos debería ser rápido para consultar incluso con grandes conjuntos de datos.

    
respondido por el getahobby 30.04.2011 - 13:12
fuente

Lea otras preguntas en las etiquetas