tag spigot prestige plugin nametagedit name holder deluxechat configurado permissions authorization role-base-authorization

permissions - prestige - spigot papi



Patrón de diseño de permisos que permite el acceso basado en fechas (1)

Estoy buscando formas de implementar un esquema de autorización (no autenticación) en mi aplicación.

Actualmente hay dos roles en el sistema: A y B, pero puede haber más. El usuario solo tiene un rol.

Básicamente, el que tengo configurado ahora es con dos tablas de base de datos. Uno es para permisos basados ​​en roles en un modelo, y el otro es para permisos específicos basados ​​en el usuario. Estoy pensando que de esta manera, los usuarios pueden tener un conjunto de permisos predeterminados basados ​​en sus permisos basados ​​en roles, pero también pueden tener permisos específicos otorgados / revocados.

Así por ejemplo:

table: user_permissions columns: user_id: [int] action: [string] allowed: [boolean] model_id: [int] model_type: [string] table: role_permissions columns: role: [int] action: [string] model_type: [string]

En la tabla user_permissions , el campo allowed especifica si la acción está permitida o no, de modo que los permisos pueden revocarse si este valor es 0.

En otra tabla, tengo las definiciones para cada acción:

table: model_actions columns: action: [string] bitvalue: [int] model_type: [string]

Hago esto para que cuando verifico los permisos en un modelo, por ejemplo [''crear'', ''eliminar''], pueda usar una operación bit a bit para comparar los permisos del usuario con los permisos que estoy verificando. Por ejemplo, un modelo X podría tener las siguientes model_actions:

action: ''create'' bitvalue: 4 model_type: X action: ''delete'' bitvalue: 2 model_type: X action: ''view'' bitvalue: 1 model_type: X

Si mis permisos de usuario / función especifican que las acciones de creación, vista y eliminación para el modelo X son 1, 0 y 1, respectivamente, esto se representa como 110 basado en la tabla model_actions . Cuando compruebo si puedo crear el modelo X, utilizo el hecho de que create es 4 para construir el bitarray 100. Si el funcionamiento AND bit a bit de 110 y 100 es 100, entonces el permiso es válido.

DE TODOS MODOS, creo que tengo un patrón de diseño de permisos granular resuelto. Si no, POR FAVOR, siéntete libre de educarme sobre el tema.

El enfoque real de mi pregunta se refiere a lo siguiente:

Algunos de mis modelos tienen acciones que dependen del tiempo. Por ejemplo, solo puede eliminar un modelo Y no más de 24 horas después de su fecha de creación_en.

Lo que estoy pensando es crear automáticamente un trabajo cron cuando se crea el modelo que actualizará los permisos en la fecha en que esto ocurra. En el caso del modelo Y, me gustaría insertar un registro en user_permissions que revoca la acción ''borrar'' de este modelo.

Mi pregunta es: ¿es aconsejable?

Editar

¿Qué pasa si incluyo otra fila en las tablas SQL, que especifica una fecha para el permiso de ''flip'' (flipDate)? Si se define un flipDate, y si la fecha actual es posterior a la fecha de volteo, el permiso se revierte. Esto parece mucho más fácil de administrar que una serie de trabajos cron, especialmente cuando los modelos se pueden actualizar.

Sus modelos parecen estar bien, pero ... está reinventando la rueda un poco y, como se dio cuenta, su modelo no es lo suficientemente flexible como para adaptarse a parámetros adicionales, como el tiempo.

En la historia de la autorización, existe un modelo tradicional y bien aceptado, denominado control de acceso basado en roles (RBAC). Ese modelo funciona extremadamente bien cuando tienes un conjunto de roles claramente definido y una jerarquía entre estos roles.

Sin embargo, cuando la jerarquía no es tan clara o cuando hay relaciones (por ejemplo, una relación médico-paciente) o cuando hay atributos dinámicos (como el tiempo, la ubicación, IP ...), RBAC no funciona bien. Un nuevo modelo surgió hace unos años llamado control de acceso basado en atributos (ABAC). En cierto modo, es una evolución o generalización de RBAC. Con ABAC, puede definir la lógica de autorización en términos de atributos. Los atributos son un conjunto de pares clave-valor que describen el usuario, la acción, el recurso y el contexto. Con los atributos, puede describir cualquier cantidad de situaciones de autorización, como:

  • un médico puede ver el registro médico de un paciente entre las 9 a. m. y las 5 p.m. si y solo si el paciente es asignado a ese médico
  • una enfermera puede editar la historia clínica de un paciente si y solo si el paciente pertenece a la misma clínica que la enfermera.

ABAC habilita lo que se podría llamar PBAC o control de acceso basado en políticas, ya que ahora la lógica de autorización se aleja de los esquemas de código propietario y base de datos en un conjunto de políticas administradas centralmente. El estándar de facto para estas políticas es XACML, el Lenguaje de marcado de control de acceso extensible.

En pocas palabras, XACML le permite hacer lo que está buscando de una manera neutral en tecnología, de una manera desacoplada y externalizada. Significa que puedes definir la autorización una vez y aplicarla en todos los lugares donde importa.

Te recomiendo que eches un vistazo a estos excelentes recursos sobre el tema: