微服务应该是用户吗?


13

我们正在尝试确定授权微服务体系结构中用户的最佳方法,同时确保微服务的权限受到限制。我们的体系结构使用中央授权服务来处理JWT令牌的发行。

我们有以下要求:

  1. 应该限制​​用户执行某些角色。例如,用户只能创建/修改/读取他拥有的内容。

  2. 微服务应仅限于其所需的权限。例如,应该明确禁止只需要从另一个服务读取数据的微服务将数据写入该服务。

例如,假设我们有一个系统,用户可以在其中将图片上传到图像存储服务。我们有一个标记服务,可以自动标记带有位置的图片。用户只能CRUD他们自己的照片。标记服务可以从图像存储服务读取任何图像,但是不能修改/删除。

使用JWT令牌实现上述目标的好方法是什么?我们讨论过的一些解决方案是:

  1. 图像存储服务公开了2个API,一个在外部可用(给用户CRUD访问),另一个在内部可用(给内部只读访问)。似乎不灵活-如果另一项内部服务需要对所有图像进行读/写访问(例如,自动删除显式图像的访问),该怎么办?

  2. 我们在用户的JWT中设置了两个权限,一个权限是CRUD_OwnImages,另一个权限是READ_ForAnalysis。标记服务可以查看用户是否具有READ_ForAnalysis权限,如果有,则发出适当的请求。我们还有另一个微服务,用于检查用户是否具有CRUD_OwnImages以便对用户自己的映像执行CRUD操作。这使每个微服务都有责任确保用户受限于他需要的操作。图像存储无法用这种方法来限制每个微服务,因此它可能容易出错和出错。

  3. 我们给标签微服务自己的用户,并以READ_ForAnalysis作为权限。然后,当加标签服务从图像存储请求图像时,将授予它们访问这些图像的权限,但禁止对其进行修改。用户的用户仅具有CRUD_OwnImages权限,因此他只能从前端检索和访问其图像。如果另一个服务需要对所有数据使用CRUD,则可以给它CRUD_AllData或类似的名称。我们喜欢这种方法,因为每个服务现在都负责其自己的数据(而不是在多个服务之间重复该逻辑),但是如果该服务同时需要用户权限和微服务权限怎么办?我们可以安全地发送两个JWT令牌(用户的和微服务的)吗?有没有一种方法可以安全地组合权限并通过发送?例如

如果更下游(需要2或3个微服务)需要用户信息,则会使问题更加严重。我们是否只是假设将单个微服务限制在它们自己需要的动作上,而不是将其明确化,这取决于单个微服务?


1
您是这些微服务的唯一开发者,还是其他公司/组织/部门(即具有安全边界的任何产品)也针对您的系统编写微服务?
罗伯特·哈维

1
很可能还会有其他服务使系统崩溃,我们希望针对这种情况进行设计。
AWR

Answers:


6

通常,应将尽可能多的操作绑定到真实的人工用户。它迫使人们正确地进行身份验证,它要求一个统一的授权策略,这是提供一致的审计跟踪的重要组成部分。

通常,您会在三种情况下使用微服务:

1.用户进来,上传照片,并且需要对其进行标记。大。照片服务可以仅通过JWT传递到标签服务(反之亦然,具体取决于您的依赖方向),如果用户缺乏执行子操作的权限,则您可以采取适当的措施(也许上传没有标签的照片) ,也许会返回错误,也许还有其他东西)。

2.用户进来上传照片,并且需要对其进行标记...但不是现在。凉。您现在可以照常处理照片了。稍后,当发生标记(事件/消息处理,CQRS样式命令处理,某些定期的作业处理等)时,标记服务将模拟用户(最有可能通过使用共享机密从auth请求自定义JWT),然后执行代表原始请求者的子操作(具有其所有权限和限制)。这种方法在异步操作中经常遇到问题,如果事情进展不顺利,很难向用户提供错误信息,但是如果您将此模式用于跨服务操作,那么您已经解决了。

3.某些子系统需要在用户上下文之外执行操作。也许您需要每天做一些工作来存档旧图像。也许您的标签需要合并...在这种情况下,您可能确实希望这些参与者中的每个参与者都拥有自己的伪用户,这些伪用户的权限有限,并且审计跟踪具有唯一的ID。

使用哪种方法取决于您的方案,需求和风险承受能力。当然,这些只是广泛的笔画概括的不完整集合。

但是总的来说,如果可能的话,微服务本身不应该是用户。


1
您的第一和最后一段不是矛盾的吗?
罗伯特·哈维

1
没有?操作应与用户绑定。微服务本身不是用户...我会澄清。
Telastyn

1
我遇到了一个建议的问题的解决方案:为每个微服务定义一个范围,在其访问令牌中指定可以访问的端点。还将用户的JWT ID令牌作为其他标头传递。这样,我们可以限制微服务和用户(深度防御)。manning.com/books/microservices-in-net-core的
2014年

场景3是一个有趣的场景,部分导致我们决定用户应该是微服务。但是看起来这可能是一个例外,而不是规则。
AWR
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.