Actualmente estoy desarrollando una administración miembro para una asociación local aquí y estoy desarrollando el esquema de la base de datos en este momento. Me gustaría compartirlo con usted para mejorarlo y darle a otros un ejemplo de un Modelo de acceso basado en roles (RBAC). Agradecería cualquier crítica constructiva, especialmente sobre las relaciones que utilicé entre las mesas.

Enlace a highres:http://i.stack.imgur.com/WG3Vz.png

Aquí está el esquema:

Cómo funciona:

Estoy asignando clientes existentes (en realidad miembros de la asociación) desde una aplicación externa a mi aplicación de administración. (tabla de clientes)

La asociación está estructurada en División, Subdivisiones, etc. (tabla de estructuras internas). Cada cliente puede ser miembro en múltiples divisiones, subdivisiones, secciones, etc.

Cada cliente puede tener uno o múltiples roles en tales membresías (divisiones, ...) como Presidente, Actuario, Tesorero, etc. y cada rol tiene ciertos privilegios que el propietario del rol puede aplicar a otros en su División, Subdivisión, Sección, etc. .

Una credencial está conectada a una determinada acción de una aplicación. El propietario de la credencial puede ejecutar esta acción en otros miembros en su alcance. Puede haber múltiples aplicaciones "independientes" pero todas comparten el mismo sistema de autenticación / autorización.

Una aplicación está estructurada en Módulos / Submódulos / Acciones, etc. Un ejemplo podría ser un módulo de "Detalles personales" y este módulo contiene un submódulo llamado "Imagen" y puede aplicar las acciones "ver, eliminar, editar" en esta imagen. Pero no puede eliminar ninguna imagen a menos que la persona cuya imagen intente eliminar esté en una división / sección donde tenga el rol adecuado para hacerlo.

La estructura interna y de aplicación son ambos árboles, implementados como una lista de adyacencia.y conjunto anidado La lista de adyacencia asegura la integridad y el conjunto anidado me permite atravesar el árbol rápidamente.

Una excepción es que puede darle a alguien ciertas credenciales directamente (client_credentials). Esto es necesario si alguien necesita realizar ciertas acciones en alguien que no está en su sección / división.

Entonces, alguien puede ser miembro en múltiples divisiones / secciones y obtener múltiples roles en cada división / sección de la que es miembro. Voy a fusionar todas las credenciales que alguien tiene a través de sus múltiples roles. Y las credenciales son siempre positivas, significa que las credenciales restrictivas no son posibles.