2017-04-13 96 views
0

在我的架构中,我有几个需要相互通信的内部服务。我还有一个身份访问管理服务,用于存储有关用户,角色和(粗粒度)权限的信息。微服务/ SOA中服务间通信的首选方法

组件(不是全部):

  • 服务A
  • 服务B
  • IAM服务

,而不是通过IP白名单让服务A和B完全访问对方,我希望他们以由IAM服务管理的用户身份运行。所以这些服务需要一种查询对方角色和权限的方式。我已经考虑了以下方法:

我为服务将在其下运行的用户创建不透明的API密钥。我将它们存储在每个服务上。当服务A调用服务B时,​​它传递它的API密钥。然后服务B在处理请求之前调用IAM服务来验证密钥并获取有关服务A角色的信息。服务B缓存来自IAM服务的响应以减少讨厌。

我见过涉及API网关的解决方案,但是这里假定流量来自网络之外。我不想将内部流量重定向到外部,只是为了将不透明的令牌转换为有价值的JWT。

+0

什么问题? –

回答

1

不透明按值令牌真正用于以下用途:

  • 减少令牌的大小到最低限度(客户端效率)
  • 隐藏什么声称用户,因为他们不需要的细节要知道
  • 对每个请求强制要求的查找(所以你可以撤销/变更瞬间令牌)

你是一个内部网络,从而有效载荷大小不是一样大的我的而且你可能不关心向其他服务泄露索赔。如果你的声明不经常改变,那么可能不需要不透明的令牌。这意味着您的服务只需要请求维护一个按值标记来访问内部资源。

这不算太坏。

如果您确实需要按每个请求的值进行转换,或者您想简化消费者的auth循环,那么代理方法是最好的。这会拦截对你的服务的请求,并用一个按值标记替换by-ref标记(或者也许是apikey)。这样做的好处是,您可以更详细地控制按价值代币的使用情况,而您的客户不需要关心您的内部安全基础架构。

这种方法增加了更多的开销以换取更多的控制。从您的内部服务中调用此服务也很好。

我在博客上写了一些关于the authentication proxy的模式。