asp.net-mvc - 常见的地方 MVC .NET 中的授权规则最佳实践

Question

我目前面临的情况是，我正在使用特定的授权属性来装饰我的 HttpPost Controller 操作方法，并在我的 HttpGet 中指定相同的规则，以确保某些功能在我的 View 中不可用。

是否有最佳实践或更好的解决方案，以便我可以在一个地方指定实际的业务规则以启用 DRY，并且不会陷入代码爆炸的情况，即为每个规则都有一个特定的 Authorize 属性..

我目前的情况是这样的:

public class MyController
{

   [HttpGet]
   public ActionResult List()
   {
       // This action is responsible for showing the list of records.  Each record
       // can potentially have a delete link but this is only shown for Administrators

       var viewModel = new MyViewModel()
       {
          CanDeleteRecordRole = Role.Administrator, // Duplicated rule here
          // other properties
       }
   }

   [HttpPost]
   [Authorize(Role.Administrator)]
   public ActionResult Delete(int id)
   {
      /// do stuff
   }
}

public class Role
{
   public const string Administrator = "Administrator";
}

然后在我看来，使用扩展方法我会使用 CanDeleteRecordRole，例如:

@if(Model.DisplayIfAuthorized(Model.CanDeleteRecordRole))
{
   <th>Delete record</th>
}

// and for td columns

@if(Model.DisplayIfAuthorized(Model.CanDeleteRecordRole))
{
   <td>My action link here for deletion</td>
}

Answer 1

是的，肯定有一种方法可以将业务逻辑与授权逻辑解耦并进行 DRY。该区域称为外部化授权管理 (EAM)(请参阅 Gartner's definition)。

要实现 EAM，您需要使用的不仅仅是角色。您需要使用属性，其中属性本质上只是一个键值对，例如citizenship=加拿大、clearance=SECRET、department=sales...

角色还不够。引用article之前在评论中分享过:

What’s Wrong With Role-Based Authorization Checks?

Plenty of authorization systems have been created with role-based checks, so what’s wrong with them? A lot of things, including documentation and coupling, modeling and encapsulation issues, and requirements growth and change.

基于角色的授权(也称为基于角色的访问控制或 RBAC )不够灵活，无法表达丰富的授权场景。您需要求助于ABAC，即Attribute-Based Access Control NIST 定义的模型。

使用 ABAC，您可以轻松实现以下规则:

• 用户可以编辑他/她拥有的文档
• 用户可以查看属于同一部门的所有文档
• 如果文档是草稿且文档敏感度等于或低于用户的许可，则具有审阅者角色的用户可以批准该文档。

您可以在 ABAC 中表达的内容没有限制。

可用于实现 ABAC 的事实上的标准和技术是 XACML，eXtensible Access Control Markup Language 。 XACML 定义:

• 具有以下概念的授权架构
  • 达成决策的外部政策决策点 (PDP)
  • 策略执行点 (PEP)，用于保护您的应用程序/代码/API 并调用 PDP
  • 用于检索其他属性和元数据的策略信息点 (PIP)。
• 请求/响应方案:如何提出问题并获得答案，例如Alice 可以查看文档#123吗？
• 丰富的政策语言，用于实现政策，例如我之前给出的示例。

在 XACML 中，所有策略都集中在一个位置。一些好处包括: - 更快的开发时间:您不再需要在应用程序中编写授权代码(if/else) - 更好的安全性:无论语言或技术如何，您都可以在所有应用程序中使用相同的策略。因此，我的答案并不特定于 .NET - 更好的审核能力:如果您将 authZ 逻辑移至基于策略的中心点，那么检查它们会更容易 - 实现DRY原则。

这些只是一些可用的好处。

有多种开源和供应商解决方案，例如:

• SunXACML(Java)
• Heras AF(Java)
• Axiomatics Policy Server (Java 和 .NET)
• IBM TSPM(Java)

HTH， 大卫。