我的问题是如何在不破坏应用程序逻辑的情况下正确进行服务间授权。
示例1:您建立了基于令牌的身份验证系统,该系统涉及通过API网关和调用链中的所有微服务转发身份验证令牌。每个微服务都基于已认证的用户身份执行自己的授权逻辑。
问题1:如何确保授权规则在服务之间不会相互冲突?例如:服务1有一个端点:“ placeOrder”,它依次调用服务2的“ transferFunds”和服务3的“ getProductDetails”。现在,给定的用户身份仅被授权使用服务1的“ placeOrder”功能,并且在0信任环境中,用户无法访问命名的服务2和3端点,但是仍然需要调用这些端点来完成初始请求。服务1。
现在,处理此问题的一种方法是在服务1中进行临时特权升级以允许调用。但这在某些情况下似乎无法达到目的,因为链中的每个后续调用都突然成为技术用户,他们可以执行任何操作并且知道链中将间接调用哪些其他服务。 我想知道是否有更好的解决方案可以避免负面影响,同时保持服务之间的0信任。
答案 0 :(得分:1)
假定placeOrder端点调用transferFunds和getProductDetails,我建议两种权限,DirectInvoke和SystemInvoke。 DirectInvoke仅需要用户的身份验证令牌,SystemInvoke需要用户身份和源上游服务生成的身份验证令牌。
您将必须为需要调用的任何下游服务提供SystemInvoke的授权。当您找出依赖关系图时,这当然会产生错误,但是希望您可以很快地做到这一点。或者,您可以为所有用户授予SystemInvoke的授权,但明确撤消您认为他们不应该访问的服务。