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

发布于 2024-09-01 07:28:23 字数 1519 浏览 4 评论 0原文

我们目前正在我们的网络应用程序 (ASP.NET) 中设计一个用户角色和权限系统,并且似乎我们有几个案例 不适合经典的基于角色的访问控制(RBAC)。我将发布几个问题,每个问题专门针对一个特定案例。这是我的第二个问题(第一个问题在这里:非 RBAC 用户角色和权限系统:检查用户的城市)。

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

根据经理所属的公司,他可以访问某些操作:例如,他只能与他所属公司的客户进行沟通。即“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 的角色……此外,“经理”似乎更像是一个“角色”(在公司中的职位),而不是来自 A 公司和 B 公司的“​​权限”语言学的观点。

对于有关此主题的任何想法以及该领域的任何经验,我们将不胜感激!

谢谢。

We are currently designing a User Roles and Permissions System in our web application (ASP.NET), and it seems that we have several cases that do no fit within the classical Role-Based Access Control (RBAC). I will post several questions, each devoted to a particular case. This is my second question (the first question is here: Non RBAC User Roles and Permissions System: checking the user's City).

We have the following case: we need to implement a Manager role in our web application. However, a Manager can belong to one or several companies (within a big group of companies for which we are creating this web app). Say, there can be “Manager of companies A and B”, “Manager of company C”, etc.

Depending on the companies that the Manager belongs, he has access to certain operations: for example, he can communicate with clients only of those companies that he belongs to. That is, “Manager of companies A and B” can only have contacts with clients of companies A and B, and not with those of company C. He can also view clients’ details pages of companies A and B and not of C, etc.

It seems that this case falls within the RBAC. However, this is not really the case. We will need to create a ManagerRole class that will have a Companies property – that is, this will not be just a role as a collection of permissions (like in the classical RBAC), but a role with properties!

This was just one example of a role having properties. There will be others: for example, an Administrator role that will also belong to a number of companies and will also have other custom properties.

This means that we will a hierarchy or roles classes:


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

We investigated pure RBAC and its implementation in several systems, and found no systems featuring a hierarchy or roles, each having custom properties. In RBAC, roles are just collections of permissions.

We could model our cases using permission with properties, like ManagerPermission, AdministratorPermission, but this has a lot of drawbacks, the main being that we will not be able to assign a role like “Manager of Companies A and B” to a user directly, but will have to create a role containing a ManagerPermission for companies A and B… Moreover, a "Manager" seems to be rather a "role" (position in the company) rather than a "permission" from the linguistic point of view.

Would be grateful for any ideas on this subject, as well as any experience in this field!

Thank you.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

很快妥协 2024-09-08 07:28:23

首先我想说,你的两个问题基本相同,应该合并。同一概念的多种变体没有任何价值。

您希望在基本角色的基础上添加额外级别的任意歧视。

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

第一步是妥协采用角色定义约定。例如,当您想要确定用户是否处于“companyA”的“经理”角色时,您可以定义规则,无论是属性、代码还是站点地图,如“manager-companyA”,即 IsUserInRole("manager -companyA")

第二步是自定义 RoleProvider 实现,它可以解析此数据并适当查询维护层次结构关系的底层数据源,为此您必须提供自定义 UI 进行维护。

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

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

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

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

因此,总而言之,只要您可以调整您的期望和/或重新定义您的要求,以便尽可能与现有基础架构配合使用,您实际设计、实现、测试和维护的代码就越少 并且您必须花费更多时间专注于尚未建立基础设施的系统的其他方面。

Let me first say that both of your questions are basically the same and should be consolidated . There is no value in multiple variations of the same concept.

You wish to add an extra level of arbitrary discrimination to the basic role.

To implement this sort of RBAC and retain the ability to take advantage of any of the inbuilt infrastructure you will need to make a few compromises and build a few custom implementations.

The first step is the compromise of adopting a role definition convention. e.g. when you want to determine if a user is in role 'manager' of 'companyA' you would define the rule, be it an attribute, code or perhaps a sitemaps, as 'manager-companyA' i.e. IsUserInRole("manager-companyA").

The second step is a custom RoleProvider implementation that can parse this and appropriately query your underlying data source maintaining the hierarchial relationships, for which you will have to provide a custom UI for maintenance.

You will need to, at a minimum, implement the methods used by ASP.Net to ensure that the roles are checked or output in the correct format.

IsUserInRole will get a string that you will have to, using convention, parse into constituent segments for verification, as described previously.

GetRolesForUser can be called when caching roles in cookies and must perform a hierarchial recursion of the roles and output all permutations. e.g. A user is manager for companyA and companyB so GetRolesForUser("user") should return an array consisting of the values manager-companyA and manager-companyB for use by the asp.net infrastructure that utilizes cached roles and does not interactively poll the RoleProvider.

This type of approach will provide you with the widest availability of established ASP.Net RBAC facilities while providing you with the customization you require.

So, to conclude, whenever you can adjust your expectations and/or redefine your requirements to work as much as possible with the existing infrastructure the less (MUCH LESS) code you must actually design, implement, test and maintain and the more time you have to spend concentrating on other aspects of your systems that do not already have an established infrastructure in place.

寂寞清仓 2024-09-08 07:28:23

我目前正在努力实现我自己的 RBAC 库版本(原因很简单,即始终学习 RBAC 的本质,同时让它专门针对我的代码库/数据库进行调整)。 (注意:约束是最难的部分)!

我处理这个问题的方法(尚未完全实现)是创建组,它基本上是用户的集合。所以在这种情况下,我会创建三个组;公司 A、公司 B 和公司 C,然后将每个用户适当地分配到这些组(公司)。

然后,您可以将管理员角色分配给特定用户,也可以为组分配角色。我喜欢这个,因为它允许我一次向许多用户添加一个卷(在数据库事务期间非常非常快,并且一旦缓存,内存占用就会小得多)。

因此,在您的示例中,假设您有一个显示在 UI 中的机构模型(或对象实例)。只需单击它,然后选择它的“安全”菜单,您就会看到一个窗口,允许您添加用户/组成员(如 Windows 安全性)。通过添加(组)公司 A 并允许“读取”权限,您实质上允许该组内的所有用户对该公司及其子对象(即客户联系人和数千个其他模型实例)进行读取访问。

它可能并不完美,但它是迄今为止我找到的最好的解决方案(尽管我自己仍然有疑问,我将就此提出问题)。

I'm currently struggling myself trying to implement my own version of an RBAC library (for the simple reasons of learning the guts of RBAC all the while having it tunes specifically for my codebase/database). (Note: Constraints are the hard part)!!

The way I have dealt with that (yet to be fully implemented) is that I created Groups, which basically are a collection of Users. So in this case, I would create three groups; Company A, Company B and Company C and then assign each user appropriately to such groups (companies).

You can then assign the Manager role to specific users and the Groups can also be assigned Roles. I like this because it allows me to add a single roll to many users at once (very, very fast during DB transactions and once cached the memory footprint is much smaller).

So in your example, let's say you have an Institution model (or object instance) that is shown in your UI. By simply clicking on it and then selecting the 'Security' menu for it, you get a window for which allows you to add user/group members (like Windowns security). By adding (group) Company A and allowing 'read' permissions, you are in essence allowing all users within that group read access to that company and its child object which would be client contacts and thousands of other model instances.

It's probably not perfect, but it's the best solution that I have found thus far (although I still have questions myself for which I'm about to ask a question on SO).

酒解孤独 2024-09-08 07:28:23

如果您的问题可以通过实现角色继承来解决,您可以实现它。

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

If you're problem would be solved by implementing inheritance for roles you could implement that.

Your example is another opportunity to go the attribute based access control way (eg allow a user that has the role of manager AND works for Company A). It is much harder to implement that a RBAC system though.

煞人兵器 2024-09-08 07:28:23

我不确定这是否是您正在寻找的东西,但在我自己搜索有关 RBAC 系统的信息时,我想我可能已经找到了适合您需求的东西。我正在阅读托尼·马斯顿 (Tony Marston) 的一篇文章,他谈到了虚拟专用数据库/行级安全性。这些将授予数据级别的权限,这意味着您可以将用户限制为数据库中信息的某些子集。该文章的链接如下。

http://www.tonymarston.net/php-mysql/ role-based-access-control.html (查看页面底部的“其他类型的访问控制”部分)

同样,我不确定这是否是您正在寻找的内容,但它可能值得快速浏览。

I'm not sure whether this might be what you are looking for or not but in my own search for information on RBAC systems I think I may have found something that suits your needs. I was reading an article by Tony Marston he talks about Virtual Private Database/ Row Level Security. These would give permissions at the data level meaning that you could restrict users to certain subsets of the information in your database. The links to the article is below.

http://www.tonymarston.net/php-mysql/role-based-access-control.html (Look in the "Other Types Of Access Control" section at the bottom of the page)

Again, I am not sure this is what you are looking for or not but it might be worth a quick browse.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文