¿Cómo diseñar el control de acceso basado en roles?

Estoy tratando de seguir el modelo de control de acceso de bases de roles para restringir lo que los usuarios pueden o no pueden hacer en mi sistema.

Hasta ahora tengo las siguientes entidades:

Usuarios : personas que utilizarán el sistema. Aquí tengo nombres de usuario y contraseñas. roles : colección de roles que los usuarios pueden tener. Cosas como recursos de administrador, administrador, etc. - Cosas que los usuarios pueden manipular. Operaciones como contratos, usuarios, borradores de contratos, etc. - Cosas que los usuarios pueden hacer con los recursos. Como crear, leer, actualizar o eliminar.

Ahora, mi duda surge aquí en el diagrama donde tengo una relación como esta:

Las operaciones (0 .. *) se ejecutan sobre los recursos (0 .. *) que genera una tabla que llamé permisos y que almacenará la operación y el recurso .

La tabla de permisos se verá así (una fila): ID: 1, operación: crear, recurso: contrato.

Lo que significa un permiso para crear un contrato .

Lo hice así porque siento que algunos recursos pueden no tener todo tipo de operaciones. Por ejemplo, para registrar contratos , los usuarios pueden cargar archivos , pero esta operación no está disponible para registrar un proveedor .

Entonces, cuando el administrador otorgue permisos a un rol , no tendrá una lista de recursos con cada operación registrada en el sistema.

Creo que cada recurso tiene su propia colección de operaciones que se pueden ejecutar sobre él.

Puedo aclarar si algo no es comprensible.

¿Es esta la forma correcta de implementar el rbac?

EDITAR

Lo que quiero decir es que al tener una tabla de permisos que tiene operación y recursos , tengo DOS tablas adicionales porque quiero asociar recursos con operaciones . También podría haber hecho que los recursos tengan permisos donde la tabla de permisos almacenaría los permisos.

Pero lo que habría sucedido es que algunos permisos que ni siquiera existen para algunos recursos habrían aparecido cuando el administrador los estaría asignando.

Entonces, quiero saber desde el punto de vista del diseño de la base de datos si este permiso de tabla que tiene una operación de columna y otro recurso es correcto. ¿Tendré problemas si sigue así?

Tu diseño me parece bastante cercano. Solo un par de sugerencias.

Usuarios: personas que utilizarán el sistema. Aquí tengo nombres de usuario y contraseñas.

Multa

roles: colección de roles que los usuarios pueden tener. Cosas como gerente, administrador, etc.

Bien también. Pero también necesitará una entidad / tabla "UserRoles" que le dirá qué usuarios tienen qué roles. Es probable que un usuario determinado tenga dos o más roles.

recursos: cosas que los usuarios pueden manipular. Como contratos, usuarios, borradores de contratos, etc.

Podría ser solo una cuestión de semántica. No creo que los usuarios manipulen directamente los recursos; los papeles hacen Así va usuario -> rol de usuario -> rol -> operación -> recurso

operaciones: cosas que los usuarios pueden hacer con los recursos. Como crear, leer, actualizar o eliminar.

sí, excepto "roles" en lugar de "usuarios"

La tabla de permisos se verá así (una fila): ID: 1, operación: crear, recurso: contrato. Lo que significa un permiso para crear un contrato.

Hmmm Hay dos maneras de ir con esto. Podría tener la tabla de permisos que describe, pero también necesitaría una RolePermissionstabla / entidad adicional que le diga qué función tiene qué permiso. Pero no estoy seguro de que sea necesario.

Una forma más sencilla de hacerlo es una tabla / entidad de permisos con estas columnas / atributos: ID de rol, ID de operación, ID de recurso. De esa forma, las combinaciones de operaciones x recursos se asignan directamente a un rol, en lugar de cargarse en un permiso asignado a un rol. Elimina una entidad. Realmente no hay necesidad de una tabla de permisos independiente de roles, a menos que desee predefinir qué combinaciones de permisos están permitidas y cuáles no.

No usaría ni implementaría RBAC. En cambio, usaría ABAC. Dejame explicar...

• RBAC o control de acceso basado en roles se trata de la administración de usuarios y la asignación de roles. En RBAC, puedes decir que Alice es un gerente. Puede definir permisos estáticos junto con eso. Por ejemplo, un gerente puede aprobar préstamos. Entonces, hay un enlace de Alice al gerente para aprobar el Préstamo como un permiso. Hay muchos sistemas que le permitirán hacerlo para que no necesite implementar sus propias tablas. Incluso LDAP tiene soporte para conjuntos limitados de RBAC. Eso está bien siempre que tenga un conjunto relativamente pequeño de roles y permisos. Pero, ¿qué sucede si desea tener en cuenta los permisos específicos, como es su caso? Ver, eliminar, insertar? ¿Qué pasa si quieres tener en cuenta las relaciones?
• El control de acceso ABAC o basado en atributos se trata de una autorización específica basada en políticas. Con ABAC puede usar roles como se define en RBAC y escribir políticas, por ejemplo
  • Los gerentes pueden ver documentos en su departamento
  • Los empleados pueden editar documentos que poseen

En su pregunta, esencialmente definió el modelo de información. Sus objetos y sus atributos, por ejemplo, un usuario (nombre, contraseña, departamento ...); un objeto (por ejemplo, un contrato) y así sucesivamente.

En ABAC, por lo tanto, desacoplaría por completo su código / lógica de la aplicación de la lógica de autorización que luego se almacena como políticas utilizando atributos. Los permisos mismos se almacenan directamente en la política (consulte el ejemplo anterior). La arquitectura de implementación de ABAC tiene el siguiente aspecto

El punto es que si adopta un enfoque ABAC, escribe políticas para ABAC (ya sea en XACML o ALFA; hay muchas herramientas para eso) y nunca tendrá que codificar o implementar RBAC de forma personalizada o controlar el acceso nuevamente.