usuario sistemas sistema privilegios perfiles matriz los informacion español ejemplo control basado acceso ruby-on-rails permissions roles access-control rbac

ruby on rails - sistemas - Mejor modelo de base de datos de control de acceso basado en roles(RBAC)



roles de usuario en un sistema (10)

Aquí hay un diagrama simple para ilustrar la excelente respuesta de Amr Mostafa

¿Cuál es el mejor esquema de base de datos para seguir los controles de acceso basados ​​en roles para una aplicación web?

Estoy usando Rails, pero el complemento RBAC vinculado por Google parece no mantenido (solo 300 confirmaciones para SVN, la última fue hace casi un año).

El concepto es lo suficientemente simple como para implementarlo desde cero, pero es lo suficientemente complejo e importante como para merecer la pena.

Entonces, ¿cómo otros diseñan e implementan su modelo de RBAC?


Creo que la respuesta a tu pregunta es tan profunda como deseas. Si piensas en poner roles en grupos y luego asociar grupos con usuarios, no sería suficiente. Eventualmente, deberá otorgar permisos específicos a un usuario en un objeto específico (un foro, un video, etc.).

Estoy más cerca de la respuesta de Yuval, todo lo que necesitamos es asociar objetos de todo el proyecto + acciones + usuarios. Para proporcionar esto; un objeto base (Entidad) tiene perfecto sentido. Cualquier objeto que herede de Entity se puede asociar fácilmente con un usuario + acción de esta manera.

Como también deseas mantener las cosas simples; mi sugerencia sería;

  • Cualquier objeto debido a restricciones de rbac debe derivar de una entidad base.
  • Debería haber una lista de roles, que están relacionados uno a uno con una Entidad.
  • Debería haber una lista de relaciones entre usuarios y roles.

Para llevar las cosas un paso más allá, también recomendaría lo siguiente (para un rbac automático)

  • Utilizo el acceso basado en servicios a mis objetos. Es decir; Creo repositorios de objetos (que hacen el acceso db) y accedo a repositorios a través de funciones de servicio.
  • Utilizo un atributo personalizado al comienzo de cada función de servicio. Esto define el rol requerido para acceder a esa función.
  • Utilizo el parámetro User para acceder a todas mis funciones de servicio, y cada función de servicio realiza una comprobación de roles antes de ejecutarse. La reflexión me ayuda a comprender qué función invoco y qué tipo de función tiene (a través de atributos personalizados)
  • También ejecuto un inicializador en el inicio de mi aplicación, y comprueba todas las funciones (y sus atributos) y veo si agregué un nuevo rol requerido. Si hay un rol que acabo de agregar y no parece estar en el db, lo crea en db.

Pero, por desgracia, eso solo está disponible para .NET, por lo que sé que Java no tiene atributos personalizados, por lo que aún no es probable que esté disponible para Java.

Me gustaría encontrar algunos ejemplos de código pero soy demasiado flojo para hacer eso. Aún si tienes preguntas sobre mi forma de rbac; puedes preguntar aquí y seguramente responderé.


Estoy trabajando en el subsistema RBAC aquí en el trabajo en ese momento ... qué casualidad.

Mi modelo se basa en los componentes básicos de las diferentes entidades del sistema que requieren permisos, ya sean atributos para ver / actualizar o acciones para realizar. También hay, por supuesto, diferentes roles en el sistema (que se pueden dar a los usuarios), y el pegamento que lo mantiene todo unido es la regla de acceso , que conecta un rol específico, una entidad específica que necesita permisos y el permiso concedido. Una regla de acceso puede verse así:

rule 14: guest role + page name + read permission rule 46: approver role + add column + execute permission

y así. Dejaré el ERD como un ejercicio para el lector ;-) si tiene alguna pregunta, deje un comentario.

Yuval = 8-)


Introducción a RBAC -

El sistema de control de acceso basado en roles es un método para restringir el acceso a ''algunas fuentes o aplicaciones o algunas características de las aplicaciones'' en función de los roles de los usuarios de la organización.

Aquí, las restricciones pueden ser por medio de permisos múltiples, los crea el administrador para restringir el acceso, y estos permisos colectivamente representan un rol, que se asignará al usuario.

Y si vamos un poco más profundo en RBAC, básicamente contiene 3 características.

1) Autenticación: confirma la identidad del usuario. Por lo general, se realiza a través de cuentas de usuario y contraseñas o credenciales.

2) Autorización: define lo que el usuario puede hacer y lo que no puede hacer en una aplicación. Ex. Se permite "modificar el orden", pero no se permite "crear un nuevo pedido".

3) Auditoría de las acciones del usuario en las aplicaciones. - Realiza un seguimiento de las acciones del usuario en las aplicaciones, así como quién ha otorgado qué acceso a qué usuarios?

Esta era una imagen de vista superior muy básica del sistema RBAC.

La estructura básica del sistema RBAC puede contener los siguientes componentes: usuarios, roles, permisos o restricciones, recursos.

  • Permisos o restricciones: los permisos representan un acceso al recurso de la aplicación.
  • Rol: contiene una colección de permisos
  • Usuario: roles únicos o múltiples asignados al usuario, por lo que, finalmente, el usuario puede tener permisos a través del rol.

Además de esto, también puede tener una colección de usuarios llamados grupos, y la función se puede asignar a grupos si desea admitir escenarios complejos. Entonces, esta era información muy básica sobre la estructura de RBAC.

También puedes consultar este artículo para más información:




Para mi conocimiento bastante básico en esa área, los actores básicos de un RBAC son:

  • Recursos.
  • Permisos
  • Usuarios.
  • Roles (es decir, grupos).

Recursos <- require -> ( uno o muchos ) Permisos .

Roles <- son colecciones de -> ( uno o muchos ) Permisos .

Los usuarios <- pueden tener -> ( uno o muchos ) Roles .

Las tablas para tal modelo serían:

  • permiso
  • papel
  • usuario
  • role_permission
  • rol del usuario

Ahora puede incluir recursos aquí también si desea que los usuarios de su aplicación puedan configurar qué permisos necesita un recurso. Pero nunca lo necesité. Espero que ayude.




Role Requirement funciona muy bien con Restful Authentication para proporcionar funciones de autenticación basadas en roles y está bien mantenido.