control de acceso basado en roles: el mismo rol, diferentes departamentos

0

Esta pregunta sobre la implementación de RBAC. ¿Puede un sujeto tener un papel en un cierto reino?

Supongamos que una universidad está formada por departamentos. Los departamentos tienen cursos. Los cursos tienen alumnos. Los estudiantes tienen calificaciones en los cursos.

Tenga en cuenta que estas calificaciones se encuentran DENTRO del ámbito de un departamento en particular, pero no están directamente Apropiadas por el departamento.

Deseamos declarar que el rol de "jefe de departamento" debería tener acceso a todas las cosas dentro del ámbito de su departamento, incluidos todos los grados. ¿Hay alguna forma estándar / recomendada para hacer esto? Estoy (ligeramente) familiarizado con la propiedad, pero las calificaciones son propiedad del estudiante. El hecho de que el grado esté dentro del departamento es indirecto.

A partir de mi lectura inicial, parece que al menos, uno tendría que crear muchos roles duplicados: "jefe del departamento de matemáticas", "jefe del departamento de historia", "jefe del departamento de inglés", etc. Parece preferible definir el " el "jefe de departamento" desempeña un papel y asigna ese rol a una asignatura relativa a un determinado departamento, luego tiene ese flujo hacia abajo en las calificaciones dentro del departamento X. ¿Es eso posible? Muchas gracias por su ayuda.

    
pregunta Ray Morris 14.02.2014 - 04:29
fuente

3 respuestas

2

desea utilizar el control de acceso basado en atributos que se extiende más allá del control de acceso basado en roles para incluir otros atributos sobre usuarios, recursos y más.

En su ejemplo, debe crear un rol "MathDepartmentHead" si usa RBAC. Pero si usa ABAC, puede escribir una regla de la siguiente manera:

Un usuario con el rol " jefe de departamento " puede hacer la acción " ver " en todos los recursos si y solo si resource.department = = user.department .

Puede leer más sobre el control de acceso basado en atributos aquí:

Hay un par de formas de lograr el control de acceso basado en atributos. La forma estándar es utilizar XACML, el lenguaje de marcado de control de acceso extensible. También vale la pena considerar las reclamaciones de Microsoft

En el mundo de XACML, hay varias implementaciones de código abierto y proveedores disponibles. Trabajo para uno de los proveedores, Axiomatics .

Algunos de los casos de uso que se ven en este espacio incluyen la protección de datos médicos confidenciales, PII e incluso información académica como es su caso de uso.

Si desea comenzar a modelar políticas de control de acceso basadas en atributos, consulte plugin de ALFA para Eclipse , una herramienta gratuita que te permite escribir XACML en pseudo-código.

Espero que esto ayude. Si vas por la ruta ABAC, deberás:

  • evitar la explosión de roles
  • habilitar el control de acceso basado en la relación (Permitir si user.department == resource.department)
  • ser capaz de implementar reglas de segregación de tareas, por ejemplo, el jefe del departamento puede ver los datos en su departamento, excepto los datos relacionados con los estudiantes o el personal que son miembros de la familia.
respondido por el David Brossard 14.02.2014 - 10:17
fuente
0

Sí, es posible. Piense en los foros, donde los moderadores podrían moderar solo ciertos temas.

Lo que deberías hacer es, en mi opinión, definir diferentes reglas, como "Puede cambiar las matemáticas", "Puede cambiar el arte", "Puede ver las matemáticas" ... etc., dependiendo de lo que tengas ... Teach tendría un valor VERDADERO para "Puede cambiar matemáticas" y falso para otras reglas de "cambio" pero "verdadero" para otros.

O bien, puede establecer reglas en los departamentos ... por ejemplo, una lista que determine cómo se puede editar y quién puede ver solo las calificaciones, etc. ...

sin embargo, debe dar más información sobre su sistema para una respuesta directa. Espero que esto ayude.

    
respondido por el cengizUzun 14.02.2014 - 09:50
fuente
0

No está tan bien documentado como RBAC, pero lo que estás describiendo he considerado Control de acceso basado en la responsabilidad.

Un ejemplo sencillo de nuestro favorito, el DMV: puede tener un rol de DMVEmployee que puede crear un objeto Título. Una de las propiedades del objeto de título sería (al menos en un sistema normalizado) una referencia a una persona, una "responsabilidad". Puede utilizarse como un rol de nivel de objeto, pero como propiedad tiene la capacidad de contribuir a la validez del objeto. (La actualización del título requiere Owner.age > = 18 y Owner.Deceased! = True) Esa responsabilidad podría otorgarle al propietario la posibilidad de cambiar la dirección del vehículo (si CurrentUser == Title.Owner) pero nada más.

    
respondido por el CarryWise 11.12.2014 - 21:52
fuente

Lea otras preguntas en las etiquetas