基于 Keycloak ABAC 的策略执行器，无需在令牌中添加属性

Posted 2023-02-27

【中文标题】基于 Keycloak ABAC 的策略执行器，无需在令牌中添加属性

【英文标题】：Keycloak ABAC based policy enforcer without adding the attribute in token

【发布时间】：2018-07-15 15:47:26

【问题描述】：

我正在尝试为我的 API 设置基于密钥斗篷的 ABAC、基于属性的访问控制。我能够将其设置为创建一个基于 javascript 的策略，该策略会查找特定的用户属性，然后授予访问权限，例如

var context = $evaluation.getContext();
var identity = context.getIdentity();
var attributes = identity.getAttributes();
var privileges = attributes.containsValue('userAttributeFlag','Y');
if (privileges) 
    $evaluation.grant();
else
    $evaluation.deny();

这只有在属性 userAttributeFlag 被添加为客户端的用户属性映射器时才有可能，以便在访问令牌中添加相同的属性

我的问题是，是否总是需要在访问令牌中添加属性才能使 ABAC javascript 策略起作用。将它添加到令牌的问题是，如果我们有很多属性会不必要地增加我们希望避免的令牌的大小。

在映射器中，可以选择将属性添加到 userInfo，但是否可以通过基于 javascript 的策略对其进行评估。

感谢您的帮助。

【参考方案1】：

在我看来，您使用 Keycloak 的 ABAC 来实现基于权限的 AC 或 RBAC。 真正的 ABAC 假设一组（相对）小的关于用户的属性和一组资源属性，例如user department 和 resource department。在这种情况下，您有一个基于这些属性授予或拒绝访问的策略。

例如，ALFA 策略如下所示：

namespace example
   policy example
      apply firstApplicable
      rule allowSameDepartment
         permit
         condition user.department == doc.department
      
   

在您的情况下，您的代码似乎正在执行检查。这迫使您创建更多用户属性以实现粒度。这会导致令牌膨胀。这是所有基于令牌/基于身份的授权方案共有的问题。 SAML 也是如此。 JWT 确实如此。

【讨论】：

感谢@David Brossard 对此进行调查。是的，我们正在尝试使用 ABAC 实现基于权限的 AC。如果是这种情况，我们不禁让 JWT 膨胀。我想知道映射器中“UserInfo”的用途是什么，有没有办法可以使用它来代替令牌？

如果您只发送用户的基本属性，即部门、出生日期、角色...并在后端使用带有 XACML 策略的 PDP，该怎么办？

感谢会调查它。尚未研究 XACML 政策