Mejor modelo de Base de datos de Control de Acceso Basado en Roles (RBAC) [cerrado]

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

Resulta que estoy trabajando en el subsistema RBAC aquí en el trabajo en el momento... qué coincidencia.

Mi modelo se basa en los bloques de construcción de las diferentes entidades en el 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 mantiene todo unido es la regla de acceso , que conecta un rol específico, una entidad específica que necesita permiso y el permiso concedido. Una regla de acceso podría tener este aspecto:

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

Y así sucesivamente. Dejaré el ERD como un ejercicio para el lector; -) si tienes preguntas, deja un comentario.

Yuval = 8 -)

Puede usar El complemento Restful ACL Rails.

Creo que la respuesta a su pregunta va tan profundo como usted desea ir. Si piensas en poner roles en grupos y luego asociar grupos con usuarios no sería suficiente. Eventualmente necesitarás dar 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 heredado de La entidad se puede asociar fácilmente con una acción de usuario + de esta manera.

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

• Cualquier objeto debido a restricciones rbac debe derivar de una Entidad base.
• Debe haber una lista de roles, que están uno a uno relacionados con una Entidad.
• Debe 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 sistema automatizado rbac)

• Uso el acceso basado en servicios a mis objetos. Es decir, creo respositorios de objetos (que hacen el acceso a la base de datos por mí) y acceso a repositorios a través de funciones de servicio.
• Uso un atributo personalizado al principio 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 hace una comprobación de rol antes de ejecutarse. La reflexión me ayuda a entender a qué función llamo y qué tipo de rol tiene (a través de atributos personalizados)
• También corro un inicializador en el inicio de mi aplicación, y comprueba todas las funciones (y sus atributos) y ve si agregué un nuevo rol requerido. Si hay un rol que acabo de agregar y no parece estar en la base de datos, lo crea en la base de datos.

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

Me gustaría llegar a algunos ejemplos de código, pero soy demasiado perezoso para hacer eso. Aún así, si tiene preguntas sobre mi forma de rbac, puede preguntar aquí y seguramente le responderé.

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

Intenta https://github.com/ThoughtWorksStudios/piece , es un motor de reglas para administrar el control de acceso basado en roles de usuario:

1. Definir reglas de control de acceso
2. Combinar reglas para construir nuevas reglas

Puede encontrar un ejemplo completo de aplicación Rails aquí: https://github.com/xli/piece-blog

Para aplicaciones. net deberías mirar algo como Visual Guard http://www.visual-guard.com / para evitar tener que manejar permisos y roles desde cero.

También para.net, los proveedores de membresía y rol y la autorización se manejan con la configuración. http://www.odetocode.com/Articles/427.aspx

Me gusta mucho esta entrada de blog, http://pivotallabs.com/users/nick/blog/articles/272-access-control-permissions-in-rails.

EDITAR:

Parece que ryanb de railscasts pensó en la misma línea y creó una gema llamada cancan https://github.com/ryanb/cancan usando una técnica básica similar al post de pivotollabs.

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 aplicaciones' basado en los roles de los usuarios de la organización.

Aquí, las restricciones pueden ser por medio de múltiples permisos, los que son creados por el administrador para restringir el acceso, y estos permisos representan colectivamente un rol, que será asignado 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 no puede hacer en una aplicación. Ex. 'Modificar orden' está permitido, pero 'crear nuevo orden' no está permitido.

3) Auditoría de las acciones de los usuarios 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?

Esto 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 a recurso de la aplicación.
• Rol-Contiene colección de permisos
• User-Roles individuales o múltiples asignados al usuario, por lo que eventualmente el usuario contiene permisos a través de medios de rol.

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