Question

我有一个工作流程，我要通过多个部门（位置）发送一个对象（在这种情况下为Order）。

每个过程阶段都使用相同的表单，但是基于某些条件，UI的不同元素被启用或可见：

用户角色（用户有权执行此操作）
位置（当对象位于此位置时可以更改此字段）
其他因素（此对象最初是由该用户创建的，是否经过修改等）

当前，我的方法相当简单，但是却很难维护，它非常适合我正在使用的类，并且每次权限更改时都需要编译代码（通常）：

类代码：

Public Class Order

    Public ReadOnly Property CanEditHeader
        If Me.Location = "Sales" AndAlso Me.UserRole = "Salesman" AndAlso Me.CreatorID = Me.UserID AndAlso Me.Revision = 0 Then
            Return True
        Else
            Return False
        End If
    End Property

    ...

End Class

UI代码：

Public Class OrderUI

    Public ThisOrder As Order        

    Public Sub UpdateUI()

        If ThisOrder.CanEditHeader Then
            Me.HeaderPanel.Enabled = True
        End If
        ...
    End Sub

    ...

End Class

感觉像这样此类代码对于此类来说太显式了，并且随着添加更复杂的权限而变得非常冗长：

Public ReadOnly Property CanEditHeader
    If Me.UserRole = "SuperUser" Then
        Return True
    ElseIf Me.OrderType = "SalesOrder" AndAlso Me.UserRole = "Salesman" AndAlso Me.CreatorID = Me.UserID AndAlso Me.Revision = 0 Then
        Return True
    ElseIf Me.OrderType = "DevelopmentOrder" AndAlso Me.UserRole = "Developer" AndAlso Me.CreatorID = Me.UserID AndAlso Me.Revision = 0 Then
        Return True
    Else
        Return False
    End If
End Property

一个想法是我必须同时授予用户和类的权限，并允许它们相交，但这似乎并没有改善，现在我必须在两个地方维护我的权限：

If ThisUser.CanEditHeader AndAlso ThisOrder.CanEditHeader Then
     Me.HeaderPanel.Enabled = True
End If

我一直在尝试研究基于属性的访问控制（ABAC）的示例，这似乎是一种对我有用的方法，但是我很难找到可以缠住我头的好示例。

有人可以提供一个更好的解决方案（ABAC或其他方式）的示例，以更好的方式解决此问题吗？

Answer 1

根据您的发言，例如：

[...]但它很难维护，非常适合我正在使用的类，并且每次权限更改时（经常）都要求编译代码。

这听起来像你需要一种方法来从你的应用程序，它基于属性的访问控制正好意味着外部化的授权。因此，您在正确的道路上！ :-)

首先，我是全公开的，我是Axiomatics的一名员工，该公司提供基于属性的访问控制解决方案，有时也称为动态授权。但是，我将尝试告诉您如何以与供应商无关的方式实现所需的功能。

基于属性的访问控制和可扩展访问控制标记语言的简要概述

eXtensible Access Control Markup Language是用于基于属性的访问控制的基于标准的语言。它定义了描述如何评估访问请求的体系结构和处理模型。

该体系结构包含以下组件：

策略执行点（PEP）：这是确保你要保护的API /应用程序的组件。 PEP拦截流，对其进行分析，然后向PDP发送授权请求（请参见下文）。然后，它接收到一个决定（允许/拒绝），其它强制。

策略决策点（PDP）接收授权请求（例如，爱丽丝能否查看记录123？）并根据已配置的策略集对其进行评估。最终，它会做出决定，并将其发送回PEP。在评估过程中，PDP可能需要其他元数据，例如用户的职务。为此，它可以求助于策略信息点（PIP）

Policy Information Point（PIP）是PDP与基础数据源（例如数据源）之间的接口。 LDAP，数据库，REST服务，其中包含有关用户，资源或其他内容的元数据。您可以使用PIP检索PDP在运行时可能需要的信息，例如风险评分，记录的位置或其他。

像执法点一样对待您的应用程序

要提高管理您的授权的效率，如上所述，我们需要一个解决方案，该解决方案可以从请求应用程序的应用程序逻辑外部处理决策。该请求的应用程序通常被称为策略执行点，因为授权策略在这一点上执行（是有道理的，对吧？）。

因此，在您的应用程序中，您将需要与外部授权服务器进行通信的方法。例如，您可以调用一种方法来批准如下所示的采购订单：

    XacmlAuthorizationDecision d = PDPUtil.PurchaseOrderAuthorization(User.Identity.Name, "approve", 
po.Identifier.ToString(), "purchase order",Request);

此方法的内容必须添加请求者的必要属性（主题-即用户的职称，部门，使他或她具有访问资格的培训是什么）以及与资源有关的任何属性。与资源有关的属性可能与该资源的标识符一样简单（即resource-id = 12345）。

要做更多的工作以实施具有环境属性（例如一天中的时间）的更精细的谷物访问控制。

在幕后，在要调用的方法的内容中，当然必须有一个HTTP到决策服务器（称为“策略决策点”）。在我们刚才讨论的请求的属性由该策略决策点通过。

决策者-政策决策点（PDP）

策略决策点提供策略执行点（PEP）负责实施的决策。

XACML语言具有基于标准的响应，以促进互操作性和通用术语。这意味着您是购买ABAC产品（例如Axiomatics）还是编写自己的ABAC软件，如果遵循标准，则可以在不影响授权的情况下更换该软件。

来自XACML引擎的JSON响应示例如下：

  {
  "Response" : {
    "Decision" : "Permit",
    "Status" : {
      "StatusCode" : {
        "Value" : "urn:oasis:names:tc:xacml:1.0:status:ok"
      }
    }
  }
 }

如果使用SOAP，示例响应如下：

<xacml-ctx:Response xmlns:xacml-ctx="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
  <xacml-ctx:Result>
    <xacml-ctx:Decision>Deny</xacml-ctx:Decision>
    <xacml-ctx:Status>
      <xacml-ctx:StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
    </xacml-ctx:Status>
  </xacml-ctx:Result>
</xacml-ctx:Response>

您的PEP将收到此响应，并且需要应用程序逻辑来处理它。例如，在DENY上，您可能希望选择不显示特定的UI组件。在PERMIT上，您将显示UI组件。您可以轻松地为网页做出这些决定，而不会影响性能。

如果你正在考虑购买一个ABAC产品，而不是建立自己的，请务必检查什么XACML配置文件支持。并非所有供应商都支持所有配置文件（如JSON或多决策）。

最后，为Axiomatics提供了一些插件-我们完全兼容XACML，并具有.NET SDK。

如果您对我所涵盖的内容有任何疑问，请告诉我。

基于多种因素（用户角色，位置等）的UI控件授权

1 个答案: