ASP.NET MVC中的基于角色访问控制（RBAC）与基于声明访问控制（CBAC）的区别

我认为这个问题可以从数据库的角度来回答。如果您注意到了实现中涉及的表格，您会发现以下内容：

1. AspNetUsers：每个用户都有一个包含所有用户所需属性（如电子邮件、地址、电话、密码等）的行。
2. AspNetRoles：根据应用程序要求定义不同的角色，如GM、CTO、HRM、ADMIN、EMP。每个角色的定义根据应用程序需要而定。
3. AspNetUserRoles：每行连接AspNetUsers和AspNetRoles，并有效地连接一个用户和多个角色。
4. AspNetUserClaims：每行具有指向AspNetUsers的键和一种类型和值。因此，每个用户都可以在运行时添加/删除一个属性。

这些表的使用可以在用户/应用程序生命周期的某个时刻进行调整，以满足特定需求。

考虑“采购经理”（PM）的早期阶段，我们可以有三种方法：

1. 应用程序将AspNetUserRoles填充为一个行，以授予“PM”购买权。用户只需要“PM”角色即可发布任何金额的采购订单。

2. 应用程序将AspNetUserRoles填充为一个行，以授予“PM”购买权，并在AspNetUserClaims中填充一个TYPE为“采购金额”的声明，并将值设置为“＜1000”，以设置金额限制。用户需要具有“PM”并且订单金额小于声明类型“采购金额”的声明值才能发布采购订单。

3. 应用程序将AspNetUserClaims填充为一个TYPE为“采购金额”的声明，并将值设置为“＜1000”。任何用户都可以发布采购订单，只要该用户的金额小于此用户的声明类型“采购金额”的声明值即可。

正如您可能已经注意到的那样，基于角色是粗粒度的刚性权限，从系统管理的角度来看，这将简化应用程序用户的生活。但是，它将从业务需求的角度限制用户的能力。另一方面，基于声明的权限非常细致，需要为每个用户分配权限。基于声明的权限会将业务推向极限，但会使系统管理变得非常复杂。

另一个要考虑的选择是ABAC。
基于属性的访问控制采用不同的方法，根据每个用户的属性、他们请求的资源和他们发出请求的环境来授予用户访问权限。
ABAC的主要好处是您可以对每个用户的权限进行细粒度控制。例如，使用ABAC，您可以为人力资源应用程序的用户授权仅在他们负责的地区导出人员报告。由于该模型旨在扩展到任意数量的属性和权限，因此通常更容易在ABAC中构建更动态的权限。
这里有一篇很好的文章总结了差异：https://cerbos.dev/blog/the-hidden-costs-of-user-authorization