授权和微服务

Posted

技术标签:

【中文标题】授权和微服务【英文标题】:Authorization and microservices 【发布时间】:2019-03-15 04:09:15 【问题描述】:

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

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

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

    用户先前登录的 Web 应用程序向 ReceptionService API 发送成员注册请求,其中包括标头中的用户访问令牌。 ReceptionService 验证用户令牌,确保授予用户“注册”权限,执行它需要执行的任何业务逻辑,最后向 MemberService API 发送一个成员创建请求,包括标头中的用户访问令牌。 MemberService 验证用户令牌,确保授予用户“member.create”权限,最后创建成员。

为了为这种情况设计解决方案,我的团队基于以下假设/先决条件:

微服务必须始终强制执行权限(至少对于重要的 API 操作,例如创建成员)。因此,即使产品经理可能只需要***“注册”权限,上例中 MemberService 的 CRUD 权限也是如此。 能够启动用例的用户,因为它具有“***” 权限必须能够完成它。含义它不应该得到 错误,因为他缺乏来自某个地方的另一个许可 底层服务的调用链。 管理员用户不必了解权限链 这是执行用例所必需的。在我们的示例中,管理员应该 只能向用户提供“注册”权限。

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

    用户之前登录的 Web 应用程序, 向 ReceptionService API 发送会员注册请求 在标头中包含用户访问令牌。

    ReceptionService 验证用户令牌,确保用户是 授予“注册”权限,执行任何业务逻辑 它需要做,最后向 MemberService API 在标头中包含自己的服务令牌(和 所以替换原来的用户令牌)。

    MemberService 验证服务令牌,确保服务 授予“member.create”权限,最后创建 会员。

使用此解决方案,AuthN 系统中的服务身份将被标记为从管理权限分配的管理员用户中过滤出来。服务身份的权限分配将是预先定义的,用户无法对其进行配置。虽然它满足了我们的假设/先决条件,但我对这种方法没有什么顾虑:

在处理“谁做了什么”(审计)时,用户身份和 令牌中提供的服务身份将被列出 冷漠。在我们的示例中,RegistrationService 将审核 发起操作但 MemberService 的实际用户 将审核该操作是否由 “注册服务”。在报告场景中,这意味着我需要 协调两个系统的审计,以确定“谁实际上 确实使用关联 ID 创建了成员”。 虽然我了解为系统创建身份的必要性 不涉及实际用户的场景中的组件(自动 批处理/第三方访问..),我不喜欢更换 在用户实际使用的场景中,带有服务令牌的用户令牌 启动用例。这是标准设计模式吗?

会不会是我们的一些假设/先决条件错了?

例如,某些微服务是否真的存在安全漏洞? 即使只有其他人可以访问,也不会强制执行权限 在安全的环境中控制微服务?假设答案 对后者来说是“不,这不会是一个安全漏洞”,那么如果 明天,我需要让 MemberService API 也可以访问 在安全环境之外(例如,因为我做到了 可供第三方使用)。我很可能需要添加一个 许可,这会破坏我的注册流程。 说我们确实希望管理员用户知道哪一组是错误的 用例需要权限,而我们应该 构建系统,使其优雅地处理由于缺少一个而导致的故障 调用链中的权限(可能使用 Sagas 和补偿 例程)?

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

【问题讨论】:

【参考方案1】:

每个服务都应该拥有自己的权限架构,但我建议您使用 Service Mesh,而不是在每个跃点/微服务中对用户进行身份验证。

【讨论】:

以上是关于授权和微服务的主要内容,如果未能解决你的问题,请参考以下文章

使用 graphql 订阅和微服务的授权(不是身份验证!)模式

微服务和分布式系统中的授权解决方案

微前端和微服务有啥区别

springcloud01-微服务和微服务架构

SpringCloud01:回顾微服务和微服务架构

我所理解的SOA和微服务