相关疑难解决方法(0)

我很难为微服务架构选择合适/安全的身份验证策略.我在这个主题上发现的唯一SO帖子就是这个:微服务架构中的单点登录

我的想法是在每个服务(例如,身份验证,消息传递,通知,配置文件等)中为每个用户提供一个唯一的引用(在逻辑上user_id与他相当)以及在id登录时获取当前用户的可能性.

从我的研究中,我发现有两种可能的策略:

1.共享架构

在此策略中,身份验证应用程序是其中一项服务.但是每个服务必须能够进行转换session_id=> user_id所以它必须简单易行.这就是为什么我想到Redis,它会存储密钥:值session_id:user_id.

2.防火墙架构

在此策略中,会话存储并不重要,因为它仅由身份验证应用程序处理.然后user_id可以转发到其他服务.我想到了Rails + Devise(+ Redis或mem-cached,或cookie存储等),但有很多可能性.唯一重要的是Service X永远不需要对用户进行身份验证.

这两种解决方案如何比较:

• 安全
• 稳健性
• 可扩展性
• 便于使用

或者你可能会建议我在这里没有提到的另一种解决方案？

我更喜欢解决方案#1,但没有找到太多的默认实现,这可以保证我正朝着正确的方向前进.

我希望我的问题不会被关闭.我真的不知道还能在哪里问它.

提前致谢

背景:我正在创建一个支持SSO的多个应用程序的云平台.我正在使用Keycloak进行身份验证,使用Netflix Zuul通过Keycloak Spring Security Adapter 进行授权(API Gateway).

每个微服务都需要一个Authorization标头,其中包含一个有效的JWT,它将从中获取用户名(sub)来处理请求.每个微服务到微服务调用应首先通过Netflix Zuul,传递Authorization标头以维持无状态验证.该策略允许每个微服务器知道谁是间接调用微服务的用户(子).

问题/问题1:如果从队列消息中调用微服务会发生什么？我的一个想法是在队列中存储与消息+ userInfo相关的信息,并创建一个专用的微服务来处理这种消息,这种特殊的微服务应该从队列中读取userInfo并处理消息.

更新1:根据另一个论坛的电子邮件回复,将JWT存储在队列中并不是一个好主意,因为它可以轻松挖掘.

问题/问题2:但是,如果之前的特殊微服务想要调用另一个期望在头中接收JWT的普通微服务会发生什么？这个特殊的微服务是否应该由他自己创建一个JWT模仿用户并能够调用常规的微服务？

我认为另一种解决方案是将原始JWT存储在队列中,但是,如果队列稍后调用特殊微服务会发生什么？就在JWT不再有效(它已过期)之后,被调用的微服务将拒绝该请求？

可能的解决方案:(根据JoãoAngelo的讨论更新,见下文)

我应该验证来自我的用户(授权代码流)和我的服务(客户端凭证授权)的请求,这两个请求都应该包含有效负载中的用户信息.当请求来自用户时,我需要验证有效负载用户信息是否与JWT声明匹配.当请求来自服务时,我只需要信任该服务(只要它在我的控制之下).

我非常感谢你的帮助.谢谢.