我们的系统正在从单片架构过渡到微服务架构。 微服务架构带有我们需要解决的技术挑战,其中之一就是AuthN / AuthZ。
我们的方法是拥有一个身份验证服务,该服务将对用户进行身份验证并生成访问/刷新令牌(JWT)。 然后,访问令牌将通过微服务链传递到请求标头中,以便每个微服务仅需验证令牌即可确定用户已成功通过身份验证。 对于AuthZ部分,权限实施是在微服务本身中完成的。我的问题与AuthZ有关。
为了说明这一话题,让我们举一个接待员的具体例子,他想例如通过Web应用程序向其保真程序注册新成员。 为了支持该用例,假设系统具有2个微服务,即ReceptionService和MemberService。 ReceptionService提供了一个REST API来启动成员注册流程。它需要用户许可“注册”才能执行。 MemberService提供了一个REST API来创建受CRUD权限保护的新成员资源。 请求流为:
为设计这种情况的解决方案,我的团队致力于以下假设/前提条件:
要完成上述示例,需要为用户分配2种不同的权限,这违反了我们的某些假设/先决条件。为了克服这个问题,我的一位同事建议考虑将微服务声明为我们的AuthN系统中的身份/用户,以便可以为其分配适当的权限。最初提供的用户令牌随后将被呼叫链中的参与服务令牌替换。 回到示例,新的请求流将是:
用户先前已登录的Web应用程序, 发送成员注册请求到ReceptionService API 在标题中包含用户访问令牌。
ReceptionService验证用户令牌,确保用户 获得“注册”许可的情况下,可以执行任何业务逻辑 它需要做的,最后将成员创建请求发送到 MemberService API在标头中包含其自己的服务令牌(和 因此请替换原始用户令牌。
MemberService验证服务令牌,确保服务是 授予“ member.create”权限,最后创建 成员。
使用该解决方案,将以从管理权限分配的管理员用户中过滤出AuthN系统中服务的身份的方式对其进行标记。对服务身份的权限分配将是预先定义的,用户无法对其进行配置。尽管它可以满足我们的假设/前提条件,但我对这种方法的担心很少:
难道我们的某些假设/前提条件是错误的吗?
任何评论或链接到资源将不胜感激。 谢谢!
答案 0 :(得分:0)
每个服务都应拥有自己的权限模式,但我建议您使用Service Mesh在每个跃点/微服务中都不对用户进行身份验证。