Autorización sobre propiedad compleja

Question

Autorización sobre propiedad compleja

#1 de Jacco (2 votos)
#2 de AviD (0 votos)

1

Tengo problemas con la propiedad de objetos en mi aplicación web. En mi aplicación web. Hay tipos de objetos:

1. Faculty
2. Student
3. Student Group
4. Student Lesson

Los siguientes roles de usuario están disponibles:

1. Group Leader
2. Teacher
3. Dean
4. Admin

Cada tipo de objeto tiene muchos objetos. En la aplicación, el rol "Usuario" tiene permisos en tipos de objetos específicos, por ejemplo:

GroupLeader1 has permission on StudentGroup5
Dean4 has permission on Faculty2

Y los tipos de objetos tienen jerarquía:

Faculty has Students.
StudentGroup has Students.
Student has Lessons



Dean4 has permission on all students which corresponds to Faculty2.
Dean3 has permission on all students which corresponds to Faculty4.
GroupLeader1 has permission on all student which corresponds to StudentGroup5.

¿Cómo puedo manejar este complejo problema de propiedad, existen modelos para esta situación?

authentication authorization access-control

pregunta Taleh Ibrahimli 18.03.2016 - 21:13

fuente

2 respuestas

0

Si bien me gustan muchos de los conceptos mencionados por @Jacco, la verdad es que sería bastante exagerado en tu escenario. Incluso RBAC es realmente el inverso de lo que necesitas ...

El único modelo que necesita aquí es simplemente DAC, con herencia. Es decir, en su ejemplo, Faculty2 tendrá un permiso ACE para otorgar a Dean4 , y todos los estudiantes que correspondan a Faculty2 heredarán estos permisos. Entonces, si Dean4 va a realizar alguna operación en Student6 , que pertenece a Faculty2 , se le autorizará el mismo ACE que se estableció en Faculty2 y es heredado por todos los estudiantes.

Si lo desea, puede tratar el requisito de GroupLeaders can only get permissions on StudentGroups y etc, como una especie de "meta-restricción RBAC", por lo que no otorga acceso según la función del usuario, pero sí lo trata como una restricción de tiempo de ejecución.

A partir de ahí, solo debe tratar el sistema conceptualmente como un sistema estándar basado en DAC.

Lo importante en estos tipos de sistemas es soportar solo la complejidad que se requiere estrictamente, pero no más.
En algún momento es menos complejo invertir la perspectiva de control.

respondido por el AviD 18.12.2016 - 16:17

fuente

Lea otras preguntas en las etiquetas authentication authorization access-control

Kali Linux metasploit y ataque de Android con PAYLOAD Conexión segura HTTPS entre arduino yun y apache server - certificado autofirmado

score 2 · Accepted Answer

Este es un problema clásico. He estado interesado en este desde hace algún tiempo y no conozco ningún modelo estándar que realmente lo resuelva de inmediato (aún).

RBAC se puede adaptar para trabajar para su situación introduciendo parámetros. Hay varios nombres que pasan por estas adaptaciones, el más común es el RBAC parametrizado (pRBAC). También he visto nombres como Context Aware RBAC, Object Aware RBAC y RBAC relacional, que son diferentes encarnaciones de la misma idea básica. Desafortunadamente, algunos de estos términos, debido a que no hay estandarización o consenso, también se refieren a otros modelos de acceso.

Hay varios conceptos de pRBAC flotando alrededor, que difieren en todos los detalles pero siguen siendo en gran medida la misma idea.
Puede consultar los documentos Un diseño para roles parametrizados por Mei Ge y Sylvia L. Osborn . Un modelo formal de ha sido descrito por Ali E. Abdallah y Etienne J. Khayat en su documento Un modelo formal para el control de acceso parametrizado basado en roles .

Al igual que en el RBAC estándar, en pRBAC, a un sujeto se le asigna un rol. El rol consiste en uno o más permisos, cada permiso consiste en una operación, par de objetos.
Además de RBAC, pRBAC permite que los objetos tengan parámetros y que los usuarios se inicialicen para un determinado rol con valores de parámetros para un objeto en el que tienen permiso en ese rol.

Entonces, por ejemplo, al objeto studentCourseResult se le asignaría el parámetro studentId . En lugar de tener un rol llamado Teacher , definiría el rol TeacherOf con los valores del parámetro studentId = {1, 2, 7, 9, 11} .
Si el valor del parámetro para el objeto está dentro del conjunto de valores de parámetro asignados a un sujeto para este rol, se otorga el acceso.

Tenga en cuenta que es un paso fácil desde aquí no solo permitir el operador = para restricciones de parámetros, sino también permitir > , < , <= , etc.

Además de pRBAC, puede consultar Control de acceso basado en atributos (ABAC) , que está bastante de moda en este momento ( pero está resolviendo un problema diferente y creando otros nuevos) y control de acceso basado en autorización (ZBAC) que es definitivamente un concepto muy interesante, pero es probable que sea una exageración para el caso de uso que usted describe, ya que soluciona el problema de la autorización entre dominios en su mayoría (y de manera muy clara).