非RBAC用户角色和权限系统:具有属性的角色

Question

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

我们有以下情况:我们需要在我们的web应用程序中实现一个管理器角色。然而，Manager可以属于一个或几个公司(在一大群公司中，我们正在为其创建这个web应用程序)。例如，可以有“A、B公司经理”、“C公司经理”等。

取决于Manager所属的公司，他可以对某些业务进行access：例如，他只能与他所属的公司的客户进行通信。即“A、B公司的经理”只能与A、B公司的客户接触，而不能与C公司的客户接触。他也可以查看A、B公司的客户详细资料页，而不是C公司的详细资料页等。

这种情况似乎属于RBAC的范畴。然而，事实并非如此。我们需要创建一个ManagerRole类，它将具有Companies属性--也就是说，这将不仅仅是一个权限集合(如经典的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的角色此外，从语言角度看，“经理”似乎是“角色”(在公司的职位)，而不是“许可”。

感谢您对这一主题的任何想法，以及在这一领域的任何经验！

谢谢。

Answer 1

首先，让我说，你们的两个问题基本上是相同的，应该合并。同一概念的多个变体没有价值。

你希望在基本作用中增加额外的任意歧视。

要实现这类RBAC并保留利用任何内置基础设施的能力，您需要做出一些妥协并构建一些自定义实现。

第一步是采用角色定义约定的折衷方案。例如，当您想要确定用户是否在“companyA”的角色“manager”中时，您应该将规则定义为“manager”，即IsUserInRole("manager-companyA")，无论是属性、代码还是站点地图。

第二步是一个自定义RoleProvider实现，它可以解析该实现并适当地查询维护层次关系的底层数据源，为此您必须提供一个用于维护的自定义UI。

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

正如前面所述，IsUserInRole将得到一个字符串，您必须使用约定将其解析为组成段以进行验证。

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

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

因此，总之，只要您能够调整您的期望和/或重新定义您的需求，以便尽可能多地使用现有的基础结构，那么您必须实际设计、实现、测试和维护的代码就越少(更少)，并且您需要花费更多的时间来关注尚未建立基础设施的系统的其他方面。

Answer 2

目前，我正在努力实现我自己版本的RBAC库(原因很简单，就是为了学习RBAC的内核，同时专门为我的代码库/数据库进行调优)。(注:约束是困难的部分)！

我处理这个问题的方法(还没有完全实现)是我创建了组，它基本上是用户的集合。因此，在本例中，我将创建三个组:公司A、公司B和公司C，然后将每个用户适当地分配给这些组(公司)。

然后，您可以将Manager角色分配给特定的用户，并且还可以为组分配角色。我喜欢这一点，因为它允许我同时向许多用户添加一个卷(在DB事务期间非常非常快，一旦缓存，内存占用要小得多)。

因此，在您的示例中，假设您有一个显示在UI中的Institution模型(或对象实例)。只需单击它，然后为它选择'Security‘菜单，您就会得到一个窗口，该窗口允许您添加用户/组成员(就像Windowns安全性一样)。通过添加( group ) Company A并允许“read”权限，您本质上允许该组中的所有用户读取对该公司及其子对象的访问，该子对象将是客户端联系人和数千个其他模型实例。

这可能并不完美，但这是迄今为止我找到的最好的解决方案(尽管我自己也有问题要问)。

Answer 3

如果您的问题可以通过实现角色继承来解决，那么您可以实现这一点。

您的示例是另一个基于属性的访问控制方式(例如允许具有经理角色并为公司A工作的用户)。然而，实现RBAC系统要困难得多。