在 ASP.Net 核心中应用粒度权限限制

Sea*_*lai 3 c# security authentication authorization asp.net-core

背景

在 ASP.Net 核心中应用精细的权限级别限制的最佳方法是什么。我已经设置了身份验证,并且我的应用程序会发出在一定时间后过期的令牌。

我的 Web 应用程序还使用了角色和权限,其中某个角色可以与一组权限相关联。我已经播种了权限并限制了对它们的访问,因为即使是管理员用户也无法更改、创建或删除任何内容(即只读)。另一方面,角色是动态的,尽管超级管理员和管理员是固定的。任何具有超级管理员访问角色的用户都有权创建新角色并为该角色分配权限。

我想要做的是根据这些权限限制对我的应用程序中所有其他控制器的访问。

我正在考虑使用基于策略的授权,其中每个权限都将与特定策略相关联(即[Authorize(Policy = "delete users")])。然后我会将用户拥有的所有权限嵌入我在登录时发出的令牌中。

我不愿意以这种方式实现它,因为虽然权利可能是硬编码的,但它们可能/会随着时间的推移而增加,如果我拥有大量的权利,那么我将所有这些都嵌入到令牌。

有没有更好的方法可以达到这种安全级别???

Dav*_*ard 11

如果你需要,用你自己的话来说,

ASP.Net 核心中的细粒度权限级别限制

您需要外部化您的授权,而不是在您的代码中构建它。挑战在于现有框架(在 .NET、Java 中...)为您提供角色,有时您可以在代码中使用声明来确定用户是否应该有权访问给定的功能/事务/数据集。

但这迫使您每次都编写该代码(在您的情况下使用 C#)。而且,当然,如果您的用例发生变化,您需要重写您的代码。它还迫使您在数据库中创建一个数据模型/信息模型,您可以在其中创建用户和角色之间的链接,也许有一天权限。然后你最终想知道如何处理职责分离或委派或其他你的代码和信息模型都不允许的场景。

另一种方法是将您的授权外部化给外部授权管理器/API,它将为您处理授权请求。这称为 ABAC(或基于属性的访问控制;)。ABAC 为您提供:

  • 一个架构(见下文)
  • 策略语言(
  • 一种查询授权引擎的方法
    • 通过是/否允许/拒绝请求/响应流,例如“Alice 可以查看项目 #123 吗?” “是的,允许”
    • 或通过开放式界面,例如“Alice 能看到什么?” “销售文件”

架构

在 ABAC 中,您选择以仅关注应用程序的核心业务逻辑(例如提供医疗记录)的方式构建您的应用程序/API/解决方案。

该应用程序本身不会决定谁可以查看哪些医疗记录。您将决策委托给称为策略决策点 (PDP) 的外部授权引擎。

要委派授权,您可以使用称为策略执行点 (PEP) 的拦截器。该拦截器可以在您的应用程序代码中,或者 - 更好的是 - 位于众所周知的界面前,以便它可以拦截您的交易/数据流。例如,如果您有一个 API,例如,/myservice/records那么您将使 PEP 位于拦截流的 API 前面(JSON、XML...)

PEP 向 PDP 发送请求,例如:

  • Alice 可以查看病历 #123 吗?
  • Bob 可以编辑医疗记录 #34 的 SSN 字段吗?
  • Carol 可以打印记录 #123 吗?

ABAC 架构

PDP 根据使用属性的策略回复许可、拒绝。这将我们带到了第二部分:政策。

属性和策略

在 ABAC(和 XACML)中,您可以编写任意数量的策略,使用您能想到的任意数量的属性。简单地说,属性是键值对,例如

  • role=="manager" (是的,角色可以是一个属性)。
  • dateOfBirth = 1901/04/01
  • citizenship = "German""Canadian"

属性可以是关于用户(如上)或资源或动作,甚至是上下文信息,例如时间。

  • record ownersizeclassificationdepartment都是资源的属性。

一旦定义了属性,就可以开始定义策略。假设用例是控制对医疗记录的访问,您可能有授权要求,例如

  • 医生可以查看分配给他们的患者的病历。
  • 其他医务人员可以查看本单位患者的病历。
  • 患者可以查看自己的病历
  • 如果患者是该患者的法定监护人,则该患者可以查看该患者的医疗记录。
  • 如果 B 正在休假并且 A 在 B 的委托名单上,则医生 A 可以查看另一位医生 (B) 的患者病历。
  • 如果他们在医院外,没有人可以查看病历。

如您所见,您可以编写任意数量的策略,并且根本不需要接触您的应用程序。您需要做的就是编辑您的政策。

它变得更好:这种方法不是特定于 ASP.NET。您可以对其他语言(Kotlin、Java...)、层(API、数据、UI...)等使用相同的方法和架构。

HTH,大卫。

进一步阅读

  • 这是一本非常好的读物,但不幸的是这不是我想要的。我最终要做的是制定与索赔相关的政策。每项政策都有一个单独的声明,即用户权利。然后我使用这些策略来授权我的 API。 (2认同)