0

在我工作的公司；我们正在计划一个自定义授权服务（使用 Open Policy Agent 作为策略引擎）来进行细粒度的 authZ 决策。

高级架构如下所示： 在此处输入图像描述

基本上，启用授权的微服务将身份（JWT 主题）、操作（GET/POST/PUT/PATCH/DELETE）和资源（/thing/12345）传递给授权服务以获得 authZ 决策。该决定只是一个布尔允许/拒绝响应。权利保留有关用户、组和角色的信息（它从 IDP 和其他系统异步接收），因此它能够从其本地数据源中查找此信息并将其传递给 OPA（使用重载输入模式）。权利/OPA 只是作为独立服务运行 - 我们不会将 OPA 作为边车或任何类似的东西运行......

我们试图解决的问题是，对于大多数路由，资源所有者不是资源路径的一部分，但我们仍然需要资源所有者能够做出 authZ 决定。

我可以想出 3 种方法让资源所有者获得权利。我正在寻求一些关于什么是最好的方法的建议。

  1. 在所有资源路径中包括资源所有者信息，例如/user/{id}/thing/12345. TBH 不确定这种方法在我们的生态系统中的可行性，所以这可能是我最不喜欢的。
  2. 启用权利的服务需要查找资源所有者（针对给定资源）并将其传递给权利（连同身份、操作和资源）。
  3. 在创建资源时将资源标识符（映射到资源所有者）同步到授权，以便启用授权的服务随后只需传递身份、操作和资源即可获得 authZ 决策。
4

1 回答 1

0

这通常归结为对内存消耗和数据预期更改频率的要求。尝试和总结：

使用请求或在策略中查找权限数据

优点：

  • 已知数据在做出决定时是最新的。

缺点：

  • 额外的查找都会增加总请求时间。在微服务架构等分布式环境中，影响可能很大。

将权限数据保存在内存中

优点：

  • 由于查找是从内存中完成的，它们通常非常快。

缺点：

  • 数据仅与上次同步的时间一样最新。
  • 除非每次更新都推送所有数据是可行的，否则需要实现和维护仅用于同步差异/增量的自定义逻辑。这在很大程度上取决于底层数据源。
  • 根据数据的大小，可能需要大量内存 - 特别是如果分布在许多 OPA 实例中，因为它们都将携带数据的副本。
于 2020-09-14T06:38:58.650 回答