Estoy implementando el sistema de seguridad modelo de Control de acceso basado en roles (RBAC) y tengo un dilema: un usuario1 está en rol1 y en rol2. Role1 permite el acceso al Resource1 y Role2 niega el acceso al mismo. Es un problema bien conocido. Podría alguien ayudarme, cómo resolverlo, tal vez algunas explicaciones. Cómo explicar a User1 por qué no tiene acceso a algún recurso. ¿Hay alguna solución para superarla?
Gracias.
Parece que estás confundiendo entre RBAC y DAC (control de acceso discrecional): Deny Access no se emplea normalmente en RBAC, sino que proviene del mundo DAC. F.e. es común ver una ACL de NTFS (Lista de control de acceso) con DENY en ella.
Puede estar intentando implementar un modelo combinado (vea el ejemplo en mi respuesta aquí ) - por ejemplo, construyendo una ACL con entradas de control de acceso (Access Control Entry) que apunta a roles. P.ej. utilizando grupos para otorgar acceso a las carpetas ...
Hay dos soluciones posibles que puedes usar, tal vez incluso mix'n'match, dependiendo de lo que tenga sentido para tu sistema (he construido y usado ambos, en diferentes contextos):
Tenga en cuenta que es posible que no esté implementando esto con un modelo de ACL estándar, pero que realmente solo verifique los roles de los usuarios; aún así está bien, lo anterior aún se aplica (es más difícil de visualizar y explicar).
La pregunta real que necesita resolver es: ¿Qué tiene sentido para su sistema? ¿Está intentando implementar SoD (Segregación / Separación de tareas)? Si es así, está claro que DENY debe anular cualquier PERMISO. Si desea que el usuario configure esto (en cuyo caso es su DAC, no RBAC), la primera opción ofrece la mayor flexibilidad, ya que existe una manera de evitarlo.
No estoy seguro de que este sea un problema bien conocido. Si su posición predeterminada es denegar a todos, y debería serlo, entonces las reglas solo deben indicar lo que puede hacer cada rol puede . Si un usuario / rol tiene acceso a un recurso bajo cualquier regla, creo que deberían estar permitidos.
Es posible que tenga que volver a pensar en la forma en que se presentan sus roles. Pienso que en los conflictos, el más alto privilegio ganaría. Las herramientas pueden manejar esto de diferentes maneras. Es importante entender exactamente cómo funciona su entorno , no cómo debería funcionar .
Puede que me falte algo, pero ¿no es una solución bastante simple utilizar un concepto como un "rol activo"?
En otras palabras, el usuario elige su rol activo de la lista de roles a los que está asignado y luego usted solo verifica las ACL contra ese único rol.
Es posible que desee considerar el uso de lo que he oído mencionar como una seguridad de acceso híbrida basada en Reclamaciones. Básicamente, en este modelo, cada tarea se desglosa y se usa como un perfil para mantener la seguridad más fácil de administrar (aunque es más difícil de implementar inicialmente).
Básicamente configura tablas similares a:
Users --> Groups --> Profiles --> Rights
| |_______________________^
|____________________^
|_________________________________^
Tabla de usuarios, cada usuario puede tener uno o más grupos Los usuarios también pueden tener uno o más perfiles (también conocidos como subgrupos de derechos para una tarea) Los usuarios también pueden tener uno o más derechos. Los grupos tienen uno o más perfiles. Los grupos pueden tener uno o más derechos. Los perfiles pueden tener uno o más derechos
La desventaja proviene de la capa adicional de grupos orientados a tareas, sin embargo, es más fácil para la mayoría de los desarrolladores no poder conceptualizar este diseño.
También puede usar un sistema basado en Reclamaciones puras, pero es difícil mantener algo como ese IMO a largo plazo. Probablemente estaría mejor con el RBAC estándar (no con el RB-RBAC) y usaría un conjunto coherente de reglas como conflictos = denegación de acceso.
Lea otras preguntas en las etiquetas authorization access-control rbac