gpt4 book ai didi

architecture - 授权服务如何在基于角色的微服务架构中实现所有权检查

转载 作者:行者123 更新时间:2023-12-03 17:37:05 26 4
gpt4 key购买 nike

假设我在博客应用上有三种类型的用户

  • 作者 (可以修改自己的帖子,不能修改别人的)
  • 管理员 (可以修改所有帖子)
  • 读者 (不能修改任何帖子)

  • 为了管理这个系统,我想要三个主要服务:
  • 一个 API 网关 ,它公开客户端将使用的所有 API,根据需要组合服务。
  • A 帖子管理服务 提供博客帖子的 CRUD 操作(包括谁拥有什么帖子的数据)
  • 授权服务 存储角色和权限,公开一个 API,该 API 接受角色数组(请求用户拥有的角色)和权限数组(访问 API 所需的权限)并确定这些输入的角色覆盖所有输入的权限。

  • 现在我正在努力解决的是资源的所有权(以及应该检查所有权的位置)。

    如果不与其他服务通信,授权服务如何确定用户是否应该能够访问他们拥有的东西,而无需知道如何确定用户是否拥有给定的资源。

    我想出了几个不同的解决方案来解决这个问题,尽管我对其中的任何一个都不满意。
  • API 网关将查询管理帖子的不同服务,以确定请求用户是否拥有他们尝试访问的帖子,这意味着授权逻辑发生在授权服务之外。
  • 管理博客文章的服务将根据所有权处理授权,这也意味着授权逻辑发生在授权服务之外,以及未经授权的请求最初被标记为授权的事实(因为它们仍将通过授权服务)
  • 授权服务可以知道如何检查所有权,API 必须能够被告知它是否应该检查所有权以及权限。这会增加授权服务的复杂性并增加跨服务通信,我希望尽可能将其归于 API 网关,因为它应该是主要的服务组合器。

  • 寻找有关替代方法的想法或深入了解此问题的最佳解决方案可能是什么。

    最佳答案

    由于它是外部化的,授权服务应该尽可能地“愚蠢”。有时,基于业务逻辑和数据的“授权”会变得非常复杂。我认为业务逻辑属于负责管理它的服务。此外,API 网关可能需要向客户端提供所有权状态(来自管理这些博客文章的服务?),以便客户端可以知道要公开什么。所以保持授权简单,并封装更复杂的业务检查,看看可以在服务本身内完成什么。

    另一种方法是加强授权服务以采用另一个参数,在这种情况下,所有权状态。 API 网关或其他服务检查授权(博客帖子管理器?)可以先从了解所有权业务的服务中获取所有权状态,然后使用提供角色和所有权状态的授权服务。权限规则将(可选)基于角色和真/假指标。授权服务不知道真/假是什么意思,只是为角色“读者”+指标=真和角色“管理员”+指标=假授予“编辑帖子”权限角色“管理员”+指标=真等。

    关于architecture - 授权服务如何在基于角色的微服务架构中实现所有权检查,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/46453981/

    26 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com