asp.net – 非RBAC用户角色和权限系统：具有属性的角色

2019年8月1日 214次阅读

我们目前正在我们的Web应用程序(ASP.NET)中设计用户角色和权限系统,似乎我们有几个案例不适合传统的基于角色的访问控制(RBAC).我将发表几个问题,每个问题专门针对特定案例.这是我的第二个问题(第一个问题是：
Non RBAC User Roles and Permissions System: checking the user’s City).

我们有以下情况：我们需要在Web应用程序中实现Manager角色.但是,经理可以属于一个或多个公司(在我们创建此Web应用程序的大公司集团内).比如,可以有“公司A和B的经理”,“公司C的经理”等.

根据管理公司所属的公司,他可以访问某些操作：例如,他只能与他所属的公司的客户进行通信.也就是说,“公司A和B的经理”只能与公司A和B的客户联系,而不能与公司C的客户联系.他还可以查看公司A和B的客户详细信息页面,而不是C公司的客户详细信息页面等. .

看来这个案子属于RBAC.但事实并非如此.我们需要创建一个具有Companies属性的ManagerRole类 – 也就是说,这不仅仅是作为权限集合的角色(如在经典RBAC中),而是具有属性的角色！

这只是具有属性的角色的一个示例.还有其他人：例如,管理员角色也将属于许多公司,并且还将具有其他自定义属性.

这意味着我们将使用层次结构或角色类：


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

我们在几个系统中研究了纯RBAC及其实现,发现没有具有层次结构或角色的系统,每个系统都具有自定义属性.在RBAC中,角色只是权限的集合.

我们可以使用属性的权限来建模我们的案例,例如ManagerPermission,AdministratorPermission,但这有很多缺点,主要是我们无法直接向用户分配“公司A和B的经理”这样的角色,但是,必须为公司A和B创建一个包含ManagerPermission的角色…此外,“经理”似乎是一个“角色”(在公司中的位置),而不是从语言角度来看的“许可”.

非常感谢有关此主题的任何想法,以及该领域的任何经验！

谢谢.

最佳答案 首先我要说的是,你的两个问题基本相同,应该合并.在同一概念的多个变体中没有价值.

您希望在基本角色中增加额外的任意歧视.

要实现这种RBAC并保留利用任何内置基础架构的能力,您需要做出一些妥协并构建一些自定义实现.

第一步是采用角色定义约定的妥协.例如当你想确定一个用户是否在’companyA’的角色’manager’时,你会将规则定义为’manager-companyA’,即isUserInRole(“manager-companyA”),无论是属性,代码还是站点地图.

第二步是自定义RoleProvider实现,它可以解析此问题并适当地查询维护层次关系的基础数据源,您必须为维护提供自定义UI.

您至少需要实现ASP.Net使用的方法,以确保以正确的格式检查或输出角色.

IsUserInRole将获得一个字符串,您必须使用约定解析为组成段以进行验证,如前所述.

在缓存cookie中的角色时可以调用GetRolesForUser,并且必须执行角色的层次递归并输出所有排列.例如用户是companyA和companyB的经理,因此GetRolesForUser(“user”)应该返回一个由值manager-companyA和manager-companyB组成的数组,供asp.net基础结构使用,该基础结构利用缓存的角色并且不以交互方式轮询RoleProvider.

这种方法将为您提供已建立的ASP.Net RBAC设施的最广泛可用性,同时为您提供所需的定制.

因此,总而言之,无论何时您可以调整您的期望和/或重新定义您的要求,以便尽可能使用现有基础架构,您必须实际设计,实施,测试和维护的代码越少(无需更少),您拥有的时间就越多专注于系统中尚未建立基础架构的其他方面.

点赞