2

我正在构建某种复杂的库存系统，接受供应商的报价等。

通常我会拥有读/写/编辑/删除之类的基本权限，并且我可以轻松地更新每个页面上的读写布尔变量以检查是否为 true 这样做，否则就这样做。

但事实并非如此。我有一些权限，例如 (Owner, SamePseudoCity)，这分别意味着允许用户访问他只创建的记录，另一个意味着以用户身份返回属于 PsuedoCity 的记录。

目前，UI 具有具有适用权限的局部变量，当 UI 从数据库请求一些数据时，它会调用 BL，该 BL 首先获得用户有权获得的权限并将它们绑定到 UI/Page 局部变量。

它还检查权限列表是否包含“所有者”，然后它将获取由 UserID 创建的记录，如果它包含“SamePseudoCity”，它将获取同一城市的所有记录。

我不确定这是否是一个好的设计，是否可以修改它。我知道这里没有对错，但有臭的设计、好的设计和更好的设计。所以我只是在寻找一些想法，如果有人以前实现过这个。

如果仍然不清楚，我花了很多时间来解释我的问题，请告诉我，我可以从我的代码中发布一些片段。

4

1 回答 1

2

掌握您的要求

您需要的是一个足以处理您的需求的授权框架。在你的帖子中，你提到你有

  • 权限，例如读/写/编辑/删除
  • 其他参数，例如 Owner，SamePseudoCity 表示不同的东西：
    • 允许用户访问他仅创建的记录
    • 以用户身份返回属于 PsuedoCity 的记录。

基于属性的访问控制

您需要转向 [tag: ABAC]（基于属性的访问控制），这将使您能够使用属性（键值对）和策略来定义您的需求。策略在称为策略决策点 (PDP) 的第 3 方引擎内进行维护和评估。

ABAC 是NIST定义的标准。它是 RBAC（基于角色的访问控制）的演变。XACML，可扩展访问控制标记语言是 ABAC 的实现，

您可以将应用到架构中的不同层，从UI（表示层）到业务层，一直到数据层。

策略以或表示。

例子：

namespace stackoverflow{

你首先定义你的属性

    namespace user{
        attribute identifier{
            category = subjectCat
            id = "user.identifier"
            type = string
        }   
        attribute city{
            category = subjectCat
            id = "user.city"
            type = string
        }           
    }
    namespace item{
        attribute owner{
            category = resourceCat
            id = "item.owner"
            type = string
        }
        attribute city{
            category = resourceCat
            id = "item.city"
            type = string
        }
    }
    attribute actionId{
        category = actionCat
        id = "actionId"
        type = string
    }

然后定义使用这些属性的策略

    /**
     * Control access to the inventory
     */
    policy inventory{
        apply firstApplicable
        /**
         * Anyone can view a record they own
         */
        rule viewRecord{
            target clause actionId == "view"
            condition user.identifier == item.owner
            permit
        }
        /**
         * Anyone can view a record that is in the same city
         */
        rule viewRecordsSameCity{
            target clause actionId == "view"
            condition user.city == item.city
            permit          
        }
    }
}

下一步

然后，您需要部署一个策略决策点/策略服务器。您可以从以下几个中进行选择：

  • Axiomatics Policy Server（免责声明我为 Axiomatics 工作）
  • SunXACML
  • Oracle 权利服务器
  • WSO2 身份服务器

如果您想将您的策略​​同时应用于 UI 和数据库，那么您可以通过称为Data Access Filter MD的 Axiomatics 产品使用称为动态数据屏蔽的功能。

ADAF MD 架构

更新

OP后来评论了以下内容

ABAC”从未听说过，听起来很棒，但我认为我需要访问专用服务器或 VPS 才能安装 PDP，对吗？.. 我知道这可能太多了，但我有 3 个问题，我可以通过编程方式改变规则吗？是否可以实现这种场景，每个产品都有一个伪城市，每个经理也有一个伪城市，经理只能访问他们自己的城市产品？是否可以做简单的读/写/编辑规则和基于此隐藏和显示 UI？-</p>

所以首先，让我们从 ABAC 架构图开始：

  • PEP 是策略执行点，负责保护您的应用程序、API 和数据库。它执行授权决定。
  • PDP 是策略决策点，负责评估策略并做出决策。它处理从 PEP 收到的请求并返回授权决定（许可、拒绝）。
  • PAP 是您定义和管理策略的策略管理点
  • PIP 是策略信息点。它是 PDP 用来连接到第三方属性源的接口，例如用户 LDAP、数据库或 Web 服务。当 PDP 需要了解有关用户或资源的更多信息时，它会使用 PIP。

ABAC XACML 架构

我假设我需要访问专用服务器或 VPS 来安装 PDP，对吗？

是的，您可以在服务器（或云）上安装 PDP。它成为您基础设施的一部分。

我可以以编程方式更改规则吗？

是的你可以。Axiomatics PAP 有一个 API，您可以使用它以编程方式上传、导出和创建策略。

是否可以实现每个产品都有一个伪城市并且每个经理也有一个伪城市并且经理只能访问他们自己的城市产品的场景？

是的，这实际上是我在原始示例中所写的，这就是 ABAC 的美妙之处。无论城市数量如何，您都编写了一个有效的策略：A user can view a record if user.city==record.city

是否可以执行简单的读/写/编辑规则并基于此隐藏和显示 UI？

是的，您可以在策略中使用任意数量的属性。因此，例如，您可以：

  • 拒绝用户访问其所在城市以外的记录
  • 用户可以查看记录
  • 用户可以编辑他们拥有的记录
  • 用户可以批准他们不拥有的记录

您可以使用该逻辑在您的 UI 或业务层甚至数据层驱动授权。所以你可以问PDP：

  • 我可以显示编辑按钮吗？
  • 我可以显示详细信息按钮吗？
  • 我可以显示删除按钮吗？
于 2016-01-27T11:49:43.930 回答