microservices - 授权和微服务

Question

我们的系统正在从单体架构转向微服务架构。
微服务架构带来了我们需要解决的技术挑战，其中之一是 AuthN/AuthZ。

我们的方法是拥有一个身份验证服务，可以对用户进行身份验证并生成访问/刷新 token (JWT)。
然后，访问 token 将通过微服务链在请求 header 中传递，这样每个微服务只需验证 token 即可确定用户已成功通过身份验证。
对于 AuthZ 部分，权限强制是在微服务本身中完成的。我的问题与 AuthZ 有关。

为了说明这个谈话，让我们举一个具体的例子，一个接待员想要注册一个新成员到他的保真计划，例如从一个 Web 应用程序。
为了支持这个用例，我们假设系统有 2 个微服务，ReceptionService 和 MemberService。
ReceptionService 提供了一个 REST API 来启动成员(member)注册流程。它需要用户权限“注册”才能执行。
MemberService 提供一个 REST API 来创建受 CRUD 权限保护的新成员资源。
请求流将是:

用户先前登录的 Web 应用程序将成员注册请求发送到 ReceptionService API，在 header 中包含用户访问 token 。

ReceptionService 验证用户 token ，确保用户被授予“注册”权限，执行它需要执行的任何业务逻辑，最后向 MemberService API 发送成员创建请求，在 header 中包含用户访问 token 。

MemberService 验证用户 token ，确保用户被授予“member.create”权限，最后创建成员。

为了针对这种情况设计解决方案，我的团队研究了以下假设/先决条件:

微服务必须始终强制执行权限(至少对于重要的 API 操作，例如创建成员)。因此，上面示例中 MemberService 的 CRUD 权限，即使产品经理可能只需要顶级“注册”权限。

能够启动用例的用户，因为它具有“顶级”
权限必须能够完成它。意思它不会得到
错误，因为他缺乏来自某个地方的另一个许可
底层服务的调用链。

管理员用户不必了解权限链
这是执行用例所需的。在我们的示例中，管理员应该
只能向用户提供“注册”权限。

为了能够完成上述示例，需要为用户分配 2 种不同的权限，这打破了我们的一些假设/先决条件。为了克服这个问题，我的一位同事提议考虑在我们的 AuthN 系统中将微服务声明为身份/用户，以便为它们分配适当的权限。最初提供的用户 token 随后将被调用链中的参与服务 token 替换。
回到这个例子，新的请求流将是:

用户先前登录的 Web 应用程序，
向 ReceptionService API 发送成员(member)注册请求
在 header 中包含用户访问 token 。

ReceptionService 验证用户 token ，确保用户是
授予“注册”权限，执行任何业务逻辑
它需要做，最后发送一个成员创建请求给
MemberService API 在 header 中包含自己的服务 token (和
因此替换原始用户 token )。

MemberService 验证服务 token ，确保服务是
授予“member.create”权限，最后创建
成员。

使用此解决方案，AuthN 系统中的服务身份将通过从管理权限分配的管理员用户中过滤出来的方式进行标记。对服务身份的权限分配将是预先定义的，用户不可能对其进行配置。虽然它满足了我们的假设/先决条件，但我对这种方法几乎没有担忧:

在处理“谁做了什么”(审计)、用户身份和
将列出 token 中提供的服务标识
漠然。在我们的示例中，RegistrationService 将审核
发起操作的实际用户，但 MemberService
将审核该操作是由
“注册服务”。在报告场景中，这意味着我需要
协调来自两个系统的审计，以确定“谁实际上
确实使用相关 ID 创建了成员”。

虽然我理解为系统创建身份的必要性
不涉及实际用户的场景中的组件(自动
批量/第三方访问..)，我不喜欢更换
在用户实际使用的场景中，带有服务 token 的用户 token
启动用例。这是标准的设计模式吗？

难道我们的一些假设/先决条件是错误的？

比如，真的是一些微服务做的安全漏洞吗？
即使只有其他人才能访问，也不强制执行许可
在安全的环境中控制微服务？假设答案
后者是“不，它不会是一个安全漏洞”，那么如果
明天，我需要让 MemberService API 也可以访问
在安全环境之外(例如，因为我做到了
可供第三方使用)。我很可能需要添加一个
许可，这会破坏我的注册流程。

说我们确实希望管理员用户知道哪一组是错误的
用例需要权限，我们应该
构建系统，以便它优雅地处理由于缺少一个而导致的故障
调用链中的权限(可能使用 Sagas 和补偿
例程)？

任何评论或资源链接将不胜感激。
谢谢!

Answer 1

每个服务都应该拥有自己的权限模式，但我建议您使用服务网格不要在每个跃点/微服务中对用户进行身份验证。