假设我在博客应用上有三种类型的用户
-
Author （能够修改自己的帖子，但不能修改其他帖子）
-
Administrator （能够修改所有帖子）
-
Reader （无法修改任何帖子）
要管理这个系统，我希望有三个主要服务：
-
API Gateway 公开客户端将消耗的所有API，根据需要组合服务 .
-
A Post Management Service 为博客文章提供CRUD操作（包括谁拥有哪些帖子的数据）
-
Authorization Service 存储角色和权限，公开一个API，它接受一组角色（请求用户拥有的角色）和一组权限（访问API所需的权限），并确定这些输入的角色是否涵盖所有权限输入 .
现在我正在努力的是资源的所有权（以及应该检查所有权的地方） .
如果不与其他服务通信，授权服务如何确定用户是否应该能够访问他们拥有的内容而不知道如何确定用户是否拥有给定资源 .
我已经为这个问题想出了一些不同的解决方案，虽然我对它们中的任何一个都不满意 .
-
API网关将查询管理帖子的其他服务，以确定请求用户是否拥有他们试图访问的帖子，这意味着在授权服务之外会发生授权逻辑 .
-
服务管理博客帖子将根据所有权处理授权，这也意味着在授权服务之外发生授权逻辑，以及未授权请求最初被标记为授权的事实（因为他们仍将通过授权服务）
-
授权服务可以了解如何检查所有权，必须能够告知API是否应该检查所有权以及权限 . 这会增加授权服务的复杂性并增加跨服务通信，我希望尽可能地将其降级到API网关，因为它应该是主服务组合器 .
寻找关于替代方法的想法或洞察这个问题的最佳解决方案 .
2 回答
由于它是外部化的，授权服务应该尽可能“愚蠢” . 有时，基于业务逻辑和数据的“授权”可能变得非常复杂 . 我认为业务逻辑属于负责管理它的服务 . 此外，API网关可能还需要为客户端提供所有权状态（来自管理这些博客帖子的服务？），以便客户端可以知道要公开的内容 . 因此，保持授权简单，并封装更复杂的业务检查，以查看服务本身可以执行的操作 .
另一种方法是加强授权服务以获取另一个参数，在这种情况下为所有权状态 . API网关或其他服务检查授权（Blog Post Manager？）可以首先从了解所有权业务的服务获取所有权状态，然后使用提供角色和所有权状态的授权服务 . 权限规则（可选）基于角色和真/假指示符 . 授权服务不知道true / false的含义，只是为角色"Reader" indicator = true授予权限"Edit Post"，对于角色"Administrator" indicator = false or Role "Administrator" indicator = true等 .
在我看来，你正在努力，因为你没有一次所需的所有信息 .
为什么不使用JWT（JSON Web令牌）？
他们可以存储有效负载（例如用户权限，权限等），您可以轻松检查他们声称的是否属实 .
https://auth0.com/learn/json-web-tokens/