6

我正在实现一个 Intranet 站点的访问控制。如果公司没有 200 多名员工并且几乎每个人都没有自定义权限，这将很容易。这很疯狂，我知道，但我无法改变它。

所以，我试图找到一个可以满足我需求的通用实现，但找不到，所以我自己去做。最后，我想出了一个相当通用的解决方案，这让我想到：以前一定有人做过！

我称之为 STOP（主题任务对象权限）访问控制。我有以下关系：

.-------.     .-----------.     .-------.
| users |1---*| STOPRules |*---1| tasks |
`-------'     '-----------'     '-------'

STOP 规则具有以下属性

STOPRule {
    Subject;
    Task;
    ObjectType;
    Permission;
    Relation;
}

对象关系可以是：所有者、创建者、修订者等。此字段不是必需的，以支持通用任务。当它在那里时，当前用户和对象实例之间的关系由委托计算。然后将当前关系与规则上所需的关系进行比较，以允许或拒绝访问。

如果我不够清楚，请告诉我。

出现两个问题：

  1. 有没有像这样的开源实现？

  2. 你看到我在这条路上会遇到什么问题吗？

编辑：我继续并实际上开始实施这个模型。第一个问题是我需要主客体之间的关系来支持任何用例。现在，我可以存储以下规则：

如果约翰（主体）是订单的创建者（关系），他可以（许可）编辑（任务）订单（对象） 。

拜托，你们能提供一个无法用这个模型表达的真实用例吗？

4

2 回答 2

1

实际上，让一个表具有按某些角色分组的权限，并使用另一个表来获得可以覆盖一般权限的扩展权限。如果是只让约翰访问某些东西的情况，为什么还要提到彼此不能呢？就像您在上面的评论中提供的最后一个示例一样：是否有一个具有权限的表。一条记录如下所示：1645 edit_some_field。然后 group_permissions 看起来像：1645 everyone false最终的异常表将是1645 (Jane Doe's ID) true.

如果假设有 50 人有权编辑此字段，那么您只需在组表中添加另一个组，例如：89 editors_of_field_X，将人员的 ID 放入表中group_members，例如89 (John Smith's ID) true。然后在最后一步，您可以覆盖上面提到的具有单人权限的那些。因此，总而言之，您将拥有 3 层方案。每个人-组-人。你走得越深，这个角色的重要性就越高。例如，如果不允许所有人，但允许您所在的组，那么您可以编辑某些内容。

此外，如果不允许您访问第三人称级别，那么您再次成为该组中的例外。这样您就可以在以后重用组，只需添加较小的更改。

于 2012-05-28T00:46:32.653 回答
1

John 创建了一个订单并希望让 Bob 查看它。

于 2012-05-28T03:33:24.630 回答