如果你需要，用你自己的话说，
ASP.Net core 中的细粒度权限限制
您需要外部化您的授权，而不是在您的代码中构建它。挑战在于现有框架（在 .NET、Java...中）为您提供角色，有时您可以在代码中使用这些框架来确定用户是否应该有权访问给定的函数/事务/数据集。
但这会迫使您每次都编写该代码（在您的情况下使用 C#）。当然，如果您的用例发生变化，您需要重写代码。它还迫使您在数据库中创建数据模型/信息模型，在其中创建用户和角色之间的链接，也许还有一天的权限。然后您最终想知道如何处理您的代码和信息模型都不允许的职责分离或委派或其他情况。
另一种方法是将您的授权外部化到将为您处理授权请求的外部化授权管理器/API。这称为 ABAC（或基于属性的访问控制；abac）。 ABAC 为您提供：
- 架构（见下文）
- 一种策略语言（xacml 或 alfa）
- 一种查询授权引擎的方法
- 通过是/否许可/拒绝请求/响应流程，例如“爱丽丝可以查看项目#123吗？” “是的，允许”
- 或通过开放式接口，例如“爱丽丝能看到什么？” “销售文件”
架构
在 ABAC 中，您选择以仅关注应用的核心业务逻辑的方式构建您的应用/API/解决方案，例如提供医疗记录。
应用程序本身不会对谁可以查看哪些医疗记录做出任何决定。您将决策委托给称为策略决策点 (PDP) 的外部授权引擎。
要委派授权，您可以使用称为策略执行点 (PEP) 的拦截器。该拦截器可以在您的应用程序代码中，或者 - 更好的是 - 位于众所周知的接口前面，以便它可以拦截您的事务/数据流。例如，如果您有一个 API，例如/myservice/records 然后你会让 PEP 坐在 API 前面拦截流（JSON、XML...）
PEP 向 PDP 发送请求，例如：
- Alice 可以查看病历#123 吗？
- Bob 可以编辑医疗记录 #34 的 SSN 字段吗？
- Carol 可以打印记录 #123 吗？
PDP 根据使用属性的策略以 Permit、Deny 进行回复。这将我们带到第二部分：政策。
属性和政策
在 ABAC（和 XACML）中，您可以编写任意数量的策略，使用您能想到的任意数量的属性。简单地说，属性是键值对，例如
-
role=="manager"（是的，角色可以是一个属性）。
dateOfBirth = 1901/04/01-
citizenship = "German" 和 "Canadian"
属性可以是关于用户（如上所述）或资源或操作，甚至是上下文信息，例如时间。
- 记录
owner、size、classification、department都是资源的属性。
一旦您定义了属性，您就可以开始定义您的策略了。假设用例是控制对医疗记录的访问，您可能有授权要求，例如
- 医生可以查看分配给他们的患者的医疗记录。
- 其他医务人员可以查看本单位患者的病历。
- 患者可以查看自己的病历
- 如果患者是该患者的法定监护人，则该患者可以查看该患者的医疗记录。
- 如果 B 正在休假且 A 在 B 的代表名单上，则医生 A 可以查看另一位医生 (B) 的患者病历。
- 任何人在医院外都无法查看病历。
如您所见，您可以编写任意数量的政策，而且您根本不需要接触您的应用程序。您需要做的就是编辑您的政策。
它变得更好：这种方法不是特定于 ASP.NET。您可以对其他语言（Kotlin、Java...）、层（API、数据、UI...）等使用相同的方法和架构。
HTH,
大卫。
进一步阅读