微服务架构中的授权答案

【问题标题】：Authorization in microservice architecture微服务架构中的授权
【发布时间】：2017-12-09 16:56:34
【问题描述】：

目前我开发了一个基于微服务架构的后端。不幸的是，我有一个如何实现授权的问题。

让我解释一下我的系统 - 有以下服务：

每个用户都属于一个或多个组。每个资源（如 ToDo 列表）也属于一个组。这意味着如果某个用户创建了一个待办事项列表，该列表将存储在该组的名称中。

情景：

有没有人知道如何在微服务架构中实现这一点并将服务之间的依赖关系保持在最低限度？

当然，如果用户在资源所属的组中，我可以在每次请求时询问组服务。但是所以我在资源服务和组服务的存在之间得到了一个非常严重的依赖关系——我喜欢避免这种依赖关系。另一种选择是将用户所属的所有组存储在访问令牌中。但是使用此选项，当用户获得新组的成员时，客户端每次都必须向 OAuth 服务询问新令牌。

那么我还有其他选择如何实现这个场景吗？

【问题讨论】：

通过将依赖关系保持在最低限度，我想您希望您的系统更具弹性，即如果授权 MS 失败，那么 ToDos MS 应该继续工作，我是这样写的吗？
是的，这是一回事。但这并不是真正的问题。这可以通过水平扩展组服务轻松解决。相反，我喜欢抑制这两个服务之间的完全依赖关系。
完全移除依赖是不可能的。
另外，水平缩放并不能解决级联故障。
相反，我喜欢抑制这两个服务之间的完全依赖关系，并尽可能降低服务之间的通信 - 这样我可以获得更高的速度 - 服务不必每次组服务时都询问如果用户是该组的成员。所以我的问题是朝那个方向发展的，我想知道这是否可以通过另一种方式解决。我应该在每个依赖于组的资源服务器上保存一些成员信息吗？或者是否有另一种可能的机制来获得授权在这种情况下工作？

【解决方案1】：

所以，您有三个域：

您已经很好地识别了三个bounded contexts，每个域一个并在三个微服务 (MS) 中实现。您正在遵守有关 DDD 的最佳实践。

不，您的问题是如何以系统为resilient 的方式集成这三个微服务，即即使其他一些微服务出现故障，它的微服务也能继续工作。

关于集成（微服务之间的通信），您有两种选择：

同步通信：每次 Todos MS 收到请求时，它都会查询 Authorization MS 以检查是否允许用户做它想做的事。这具有易于实现的优点，但它具有易受级联故障影响的缺点：如果授权 MS 失败，则该 MS 也失败。所以，这个选项不适合你。
异步通信：不知何故，在后台，有一些数据从授权 MS 复制到 Todos MS。要完成此复制，您至少有两个选项：a) 在cron 或scheduled tasks 或类似中，b) 使用event driven architecture。这具有提供更多弹性的优点，但它具有更复杂、更难以实施的缺点。 此选项似乎符合您的需要。

进一步阅读：

【讨论】：

您的意思是，访问权限应该由 Todos MS 验证吗？
@Ngob 理想情况下，在 API 网关中
在API网关中验证访问业务规则是否安全？这是否意味着当我添加与访问规则关联的新功能时，我必须更新 API 网关？这不意味着我的域将被分成多个服务吗？
@Ngob 如果你的意思是“授权”，那么是的，它是安全的，因为授权不是域的一部分
我不确定我们在这里是否相互理解。我不是在谈论 RBAC，如果我简化这个例子：“用户 C 不允许更新另一个用户的 TODO”。在这里，我的意思是用户 C 有权“更新”“待办事项”，但无权更新用户 A 的“待办事项”。从您的回答中，我了解到这种验证是由域完成的，但从您的评论来看，它看起来像它不属于“TODO”域。你的想法？谢谢，

【解决方案2】：

我建议将授权处理放入 API 网关。当有传入请求时，将执行以下步骤

1.API网关访问OAuth服务器获取一个透明token，里面包含用户的访问角色和组 2.API网关然后使用访问令牌调用to do服务，to do服务使用访问令牌来决定特定用户是否被授权。

这种集成模式的优点是单个服务不必调用组服务来获取角色。

【讨论】：