授权和微服务

时间:2018-10-10 09:30:26

标签: microservices rbac authz

我们的系统正在从单片架构过渡到微服务架构。 微服务架构带有我们需要解决的技术挑战,其中之一就是AuthN / AuthZ。

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

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

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

为设计这种情况的解决方案,我的团队致力于以下假设/前提条件:

  • 微服务必须始终强制执行权限(至少对于重要的API操作,例如创建成员)。因此,即使产品经理可能仅需要顶级“注册”权限,也可以在上面的示例中获得对MemberService的CRUD权限。
  • 能够启动用例的用户,因为该用例具有“顶级”权限 权限必须能够完成。含义它不会得到 错误,因为他缺少 基础服务的呼叫链。
  • 管理员用户不必了解权限链 执行用例所需的功能。在我们的示例中,管理员应 只能向用户提供“注册”权限。

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

  1. 用户先前已登录的Web应用程序, 发送成员注册请求到ReceptionService API 在标题中包含用户访问令牌。

  2. ReceptionService验证用户令牌,确保用户 获得“注册”许可的情况下,可以执行任何业务逻辑 它需要做的,最后将成员创建请求发送到 MemberService API在标头中包含其自己的服务令牌(和 因此请替换原始用户令牌。

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

使用该解决方案,将以从管理权限分配的管理员用户中过滤出AuthN系统中服务的身份的方式对其进行标记。对服务身份的权限分配将是预先定义的,用户无法对其进行配置。尽管它可以满足我们的假设/前提条件,但我对这种方法的担心很少:

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

难道我们的某些假设/前提条件是错误的吗?

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

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

1 个答案:

答案 0 :(得分:0)

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

相关问题