Estamos actualmentediseño a Roles de usuario y sistema de permisos en nuestra aplicación web (ASP.NET), y parece que tenemos varioscasos eseno encaja dentro de lo clásicoControl de acceso basado en roles (RBAC). Publicaré varias preguntas, cada una dedicada a un caso particular. Esta es mi segunda pregunta (la primera pregunta está aquí:Sistema de roles y permisos de usuarios no RBAC: verificar la ciudad del usuario)

Tenemos el siguiente caso: necesitamos implementar unRol de gerente en nuestra aplicación web. Sin embargo, un gerente puedepertenecer a una o varias empresas (dentro de un gran grupo de empresas para las que estamos creando esta aplicación web). Digamos, puede haber "Gerente de las empresas A y B", "Gerente de la empresa C", etc.

Dependiendo de las compañías a las que pertenece el gerente, él tieneacceso a ciertas operaciones: por ejemplo, puede comunicarse con clientes solo de aquellas compañías a las que pertenece. Es decir, el "Gerente de las empresas A y B" solo puede tener contactos con clientes de las empresas A y B, y no con los de la empresa C. También puede ver las páginas de detalles de los clientes de las empresas A y B y no de C, etc. .

Parece que este caso cae dentro del RBAC. Sin embargo, este no es realmente el caso. Necesitaremos crear unClase ManagerRole eso tendrá unPropiedad de las empresas Es decir, esto no será solo un rol como una colección de permisos (como en el RBAC clásico), sino unpapel con propiedades!

Este fue solo un ejemplo de un rol que tiene propiedades. Habrá otros: por ejemplo, unRol de administrador eso también pertenecerá a varias compañías y también tendrá otras propiedades personalizadas.

Esto significa que tendremos una jerarquía o clases de roles:

class Role – base class  
class ManagerRole : Role  
    List Companies  
class AdministratorRole : Role  
    List Companies  
    Other properties

Investigamos RBAC puro y su implementación en varios sistemas, yno se encontraron sistemas con unjerarquía o roles, cada uno con propiedades personalizadas. En RBAC, los roles son solo colecciones de permisos.

Podríamos modelar nuestros casos usandopermiso con propiedades, como ManagerPermission, AdministratorPermission, pero esto tiene muchos inconvenientes, el principal es que no podremos asignar un rol como "Gerente de Empresas A y B" a un usuario directamente, sino que tendremos que crear un rol que contenga un Permiso de Gerente para las empresas A y B ... Además, un "Gerente" parece ser más bien un "rol" (posición en la empresa) en lugar de un "permiso" desde el punto de vista lingüístico.

Agradecería cualquier idea sobre este tema, así como cualquier experiencia en este campo.

Gracias.