ABAC PIP属性请求

Question

ABAC PIP属性请求

3

如何解决PIP的正确属性值？它应该具有哪种接口才能解决属性值？例如，我需要获取用户角色，在这种情况下，我只需要传递用户ID的属性。现在让我们把这个任务变得更加复杂。如果我有上下文，用户角色可能会改变，所以单个用户ID在这里是不够的。在这种情况下，我需要传递我们正在尝试获取用户角色的访问级别。

因此，在这个例子中，我们可以看到，接口将随着每次的变化而改变，唯一合适的接口将是接受所有内容的接口。

在这种情况下，PIP通常如何实现？

更新：

示例：我们有以下层次结构：

Level 0           1          2
Organization < tenants < documents.

符号 < 表示右侧是左操作数的子节点。

每个层级上，用户可能具有管理员或普通用户角色。如果用户在第 n 级拥有管理员角色，则可以访问该级别以及第 n+1、n+2、n+3 ... 级别的所有内容。同时，用户在所有级别 n-1、n-2、n-3 ... 上都将具有普通用户角色。

例如：

    user        admin      admin
Organization < tenants < documents

这是第一部分。第二部分涉及文档。比如，我们有一些属性，例如publicTenant和publicDocument。在不同层级上的相互关系并不相关，并且需要了解不仅用户标识，还要知道我们所在的级别和资源属性，例如organizationId、tenantId和documentId才能正确解决不仅用户角色，而且还要考虑资源属性。

在ABAC中如何正确实现呢？当前的解决方案是混合使用ACL/RBAC/ABAC。ACL和RBAC隐藏在ABAC下面，并作为主体的属性使用，但这种方式并不合适。

- Artsiom Miksiuk

1

嗨，我也想在这个问题上得到一些澄清。当你说用户角色可能会改变时，你是指像“初级工程师被提升为高级角色”这样的情况吗？- 让我们假设这两个职称在所有实际目的上都有不同的角色。当你说访问级别时，那是像一个许可/分类级别吗？比如拥有机密许可的初级工程师想要访问机密级别的文件？ - Michael C Good

@MichaelCGood，我已经更新了帖子并附上了示例。 - Artsiom Miksiuk

1

你说：“当前的解决方案是ACL/RBAC/ABAC混合的。” 你是指你知道这样的解决方案吗？你能描述一下吗？如果可以，我们有很大的机会将其转换为“纯粹”的ABAC。事实上，与ABAC框架（如XACML）相比，ACL通常非常简单，被认为是ABAC的子集（特定用例）。RBAC0和RBAC1也是如此。因此，在大多数情况下，ACL/RBAC/ABAC=ABAC。当然，您仍然需要某些身份验证/访问管理系统来进行用户角色分配，并且确实需要PIP来将ABAC PDP与其集成。 - cdan

@CyrilDangerville，因此，ACL/RBAC/ABAC解决方案确实等同于ABAC。我在这里的意思是，所有ACL和RBAC属性都以ABAC属性的形式表达。例如，在ABAC属性中，主体角色是由ACL计算出来的，其中角色实际上是生活的。对于主体权限，我们正在取消主体角色并获取角色的权限。就像，感觉不太好，但更好的是，我会分别管理它们而不是单个的ABAC界面。 - Artsiom Miksiuk

好的。另一个澄清问题：在您的示例中，当您在租户上定义管理员和用户角色时，您是否指的是每个租户的级别？例如，一个人可能在租户A上拥有管理员角色，但在租户B上只有用户角色。对于文档也是同样的问题。一个人可能在文档A上拥有管理员角色，但在文档B上只有用户角色？ - cdan

@CyrilDangerville，是的。没错。 - Artsiom Miksiuk

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- cdan · Accepted Answer

以下方法基于XACML模型。如果您需要一种更好地处理请求中某些资源属性丢失情况的解决方案，请告诉我们。我可以更新我的回答，但是解决方案更加复杂，因为它会增加更多检查来检测空/未定义的属性。我使用了简化的语法，但是您可以轻松将其转换为XACML，具体规则如下：

如果针对政策（集）或规则没有提及目标，则表示它是空的（适用于任何请求）。
在示例中，像if attribute x = 'XXX'这样的谓词将转换为具有MatchId='string-equal'、AttributeValue 'XXX'以及相应属性设计器的XACML目标/AnyOf/AllOf/Match。
主体(资源)属性标识符以subject.（resp. resource.）作为前缀。
政策/规则组合算法隐含地设置为deny-unless-permit。

政策集将如下所示：

策略集 'root'
- 策略 '组织级别'
  - 规则 '管理员角色': 如果subject.organization-level-role = 'Admin'，则允许通过
  - 规则 '用户角色': 如果subject.organization-level-role = 'User' 并且...其他限制用户角色在组织级别可以做什么的条件...（如果过于复杂无法适应规则，则可以将这些规则更改为策略，并将封装策略更改为策略集）
- 策略 '租户级别'
  - 规则 '管理员角色': 如果subject.tenant-level-role = 'Admin'，则允许通过
  - 规则 '用户角色': 如果subject.tenant-level-role = 'User' 并且...其他条件限制用户角色在租户级别可以做什么...（如果过于复杂无法适应规则，则可以将这些规则更改为策略，并将封装策略更改为策略集）
- 策略 '文档级别'
  - 规则 '管理员角色': 如果subject.document-level-role = 'Admin'，则允许通过
  - 规则 '用户角色': 如果subject.document-level-role = 'User' 并且...其他条件限制用户角色在文档级别可以做什么...

为了使其工作，您需要实现一个或多个PIPs来解决以下主题属性（如果所有用户角色由同一系统管理，则可以在一个PIP中完成所有操作，这取决于您）：

subject.organization-level-role：组织级别的主题角色；要获得此角色，PIP需要以下属性作为输入：subject.userId、resource.organizationId
subject.tenant-level-role：租户级别的主题角色；要获得此角色，PIP需要以下属性作为输入：subject.userId、resource.organizationId、resource.tenantId
subject.document-level-role：文档级别的主题角色；要获得此角色，PIP需要以下属性作为输入：subject.userId、resource.organizationId、resource.tenantId、resource.documentId。

关于PIP实现的几点评论：

如果主体在相应级别上没有分配任何角色，则PIP可能会返回一个空的包。
如果从角色管理系统获取用户角色的成本很高，PIP可以通过一次性从角色管理系统获取所有角色（在所有级别上），以优化它，在策略评估期间第一次请求上述任何一个主体属性时，将其保存在缓存中，并在请求另一个这些主体属性时从缓存中返回。这里有很多缓存优化的可能性。