每个微服务是不是应该管理自己的用户权限和用户角色？

Posted 2023-02-26

【中文标题】每个微服务是不是应该管理自己的用户权限和用户角色？

【英文标题】：Should each microservice manage its own user-permissions and user-roles?每个微服务是否应该管理自己的用户权限和用户角色？

【发布时间】：2018-09-11 18:07:04

【问题描述】：

我有一个不知道如何解决的设计问题。

假设我的主应用程序包含 6 个模块：

客户 网关 身份验证服务 论坛 画廊 消息

客户端应该只与网关服务通信。

我是否应该让我的网关进行用户身份验证（理想情况下会产生 JWT），而其他 3 个生产服务（论坛、图库、消息）只是验证令牌并检索权限和角色他们自己管理 为给定的用户？

为了说明我的一些麻烦，我创建了一个序列图：

Click here 用于原始 draw.io 图形，如果您愿意的话。

我不想使用任何第 3 方身份验证服务；我只希望我的身份验证服务（几乎完成）注册用户并让他们登录。还是我也应该管理该服务中的权限和角色？

几个月来，我一直试图围绕这个问题思考，但我根本找不到合适的结构，因此我可以让用户注册、登录/注销并与各种生产服务进行通信。我目前在后端使用 Java，但微服务的好处是，我不必为它们都使用一种编程语言。

欢迎任何帮助！

P.s.：我读过 Microservice Authentication strategy 和 Zuul - Api Gateway Authentication，但似乎都不适用于我的情况。

【问题讨论】：

@sschrass 这不是很有帮助...如果我没有考虑过至少 两次？

对您的用户来说可能是这样。

【参考方案1】：

我使用了以下设置，并且效果很好：

登录流程：

新浏览器请求特定资源 网关服务检测到没有 jwt cookie 并重定向到登录表单 登录表单通过网关与 auth-service 对话。网关只允许对 auth-service 进行非 jwt 调用 身份验证服务为登录表单提供一个新创建的 jwt cookie 并重定向到原始 URL

正常运行：

浏览器请求资源和 jwt cookie 网关服务拦截请求并将 jwt 转发给 auth-service 进行验证 Auth 服务检查签名、时间戳、黑名单并返回肯定或否定结果 如果是肯定的，网关服务将请求转发到相应的后端服务，否则重定向到登录 后端服务不进行 jwt 验证 - 它只是信任网关仅发送有效请求。 后端服务会检查 jwt 中定义的角色/权限/权利

注销流程：

浏览器向 auth-service/logout 发出请求 Auth 服务将 jwt 放入黑名单并重定向到登录表单

现在，这是我们在没有任何（大量）第三方帮助的情况下实施的简单工作流程。在某些时候，我们确实不得不使用会话 cookie，但这是出于其他原因。请注意，除了认证服务的黑名单外，系统几乎是无状态的。 One does not simply log out with jwt! 我们有一个 REDIS 来管理黑名单。您可以在网关或身份验证服务中使用会话 cookie 实现注销。

大多数后端服务都希望在 jwt 中有自己的一组角色/特权/权利。这些角色由身份验证服务授予用户，并写入授予的 jwt。如果将新角色授予用户，则用户必须注销/登录以反映该特权。如果删除了某些权限，则用户必须强制注销 - 这就是 REDIS 发挥作用的地方。

【讨论】：

我根据您的回答想到了一些事情。我猜 REDIS 你的意思是redis.io 所以我想我会试一试（我已经做了一些事情，但我没有继续工作，因为它是一个私人项目）。

【参考方案2】：

这取决于权限设置的复杂程度。

如果您的权限非常简单，即所有服务都需要身份验证并且只有一个角色可以使用，您可以在网关 api 处添加。

如果您需要更精细的方法，则需要在模块级别进行。通常在微服务架构中，每个服务都会调用另一个服务，并且在模块级别进行授权设置可以避免预先了解网关 api 所需的权限。您可以部署这些模块中的每一个，而无需过多考虑其他服务，在方法级别拥有细粒度权限等。