architecture - API 网关和 ACL

Question

我正在设计一个基于微服务的应用程序，它有两个 API 端点，其中一个用于用户访问。使用 JWT 进行身份验证的用户可以属于不同的组织，这些组织又按层次组织。每个用户都可以有一些角色，这些角色是为每个组织类型定义的；组织和角色之间的组合定义了可以从用户(方法和资源)访问哪些 API。总之，它可能会变得一团糟!

有几个库提供了 ACL 功能，但我想知道把它们放在哪里:第一个解决方案似乎是 API 网关，它应该为每个请求调用一个组件。

- JWT 包含用户的角色 ID 列表-API 网关验证 JWT 并使用角色 ID 在每个角色都有权限列表的表中查找(例如可以 POST/users)-如果角色与请求匹配，则后者被转发到正确的服务；否则，网关响应 403

其他选项是将“auth-service”放入架构中。网关只是将所有请求转发到正确的服务，每个服务(可能依赖于一个公共(public)库)将 token 发送到 auth 服务并请求授权以满足请求。在这种情况下，auth 服务是/auth 资源下所有请求的“正确服务”，提供登录/注销、 token 刷新和新用户注册(例如当您单击登录邮件中提供的链接时)

第一个解决方案提供了一个“胖网关”，它在逻辑上有一个很小的层，但强制所有服务只响应安全调用，分解所有身份验证/组织逻辑，而不是在服务之间添加依赖性，但是

1. 这样做是否正确？
2. 是否有提供该功能的 api 网关实现
3. 这两种方法还有一些我没有看到的其他优点/缺点

谢谢你的回答!!!

Answer 1

我回来分享我对围绕帖子主题做出的选择的看法。我遵循的方式是

API Gateway is aware of auth data sent along with requests (the "Authorization header" in practice) and does verifications. JWTs carry all necessary information, so the api gateway can apply its policies that are unknown to downstream services.

在我的架构中有一些 RBAC，没有什么可以放在 jwt 中，所以我们在网关上移动了访问控制逻辑。我们采用了一个自定义的 nodejs 库作为插件，但我不得不承认这弄乱了我们的网关，我们发现 authz 配置缓慢且容易出错。在这一方面，我们正在为缺乏与主要配置信息的集成而付出代价。它会很有用，比如

routes:
  - route1:
      path: /foos/:fooid/bar
      downstreamService: http://foo.cluster
      authz:
        readerRole:
          - GET
        writerRole:
          - POST
        all:
          - OPTIONS

但是，Api 网关不能独自完成所有事情:需要联系我称之为“身份提供者”的服务，这些服务将“消费者”概念模型化的实体封装到平台中:用户、设备、应用程序。我们的api网关根据JWT数据对identity进行GET，验证identity是否存在，是否一切正常。此外， token 生成/刷新不是 api 网关关注的问题，但有一个认证服务器(一个是独立的，另一个仍然嵌入到单体中)是连接的。所有这些都会产生大量负载，但可以通过“identites”缓存轻松缓解。请注意在身份发生变化时使缓存无效，或者至少尝试使用尽可能少的信息，这样您就可以只关心身份删除

我们的下一步将是制造/购买一个更结构化的身份验证服务器，它将继续与网关集成，但能够独立扩展并且更清晰和易于配置，可能带有某种 UI

作为云原生爱好者，我也在看istio除其他外，它具有身份验证功能，但我仍然需要了解是否适合我需要能够进行一些自定义的方法