Question

我正在设计一个具有两个API端点的基于微服务的应用程序，其中一个用于用户访问。经JWT身份验证的用户可以属于不同的组织，这些组织依次进行组织。每个用户都可以具有针对每种组织类型定义的角色。组织和角色之间的结合定义了可以从用户（方法和资源）访问哪个API。总之，它可能会变成一团糟！

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

-JWT包含用户的角色ID列表 -API网关验证JWT并使用角色ID在表中查找，每个表都有一个权限列表（例如POST / users） -如果角色与请求匹配，则将请求转发给正确的服务；否则，网关会回应403

其他选择是将“身份验证服务”放入体系结构。网关简单地转发所有传递给正确服务的请求，每个服务（可能取决于公共库）将令牌发送给auth服务，并授予请求以满足请求。在这种情况下，身份验证服务是/ auth资源下所有请求的“正确服务”，可提供登录/注销，令牌刷新和新用户注册（例如，当您单击提供给登录邮件的链接时）

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

这是正确的方法吗？
是否有提供该功能的api网关实现
在这两种方法中我都看不到其他优点/缺点

谢谢你的回答！

Answer 1

我将与大家分享我围绕帖子主题所做的选择。我遵循的方式是

API网关知道与请求一起发送的身份验证数据（实际上是“授权标头”）并进行验证。 JWT随身携带所有必要的信息，因此api网关可以应用其策略下游服务未知的。

在我的体系结构中，有一些RBAC，没有任何东西可以放入jwt中，因此我们在网关上移动了访问控制逻辑。我们改编了一个自定义的nodejs库作为插件，但是我不得不承认这弄乱了我们的网关，我们发现authz配置缓慢且容易出错。在这一方面，我们要弥补与主要配置信息的集成不足。

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

但是，Api网关无法独自完成所有事情：需要联系我称为“身份提供商”的服务，那些将将“消费者”概念建模的实体封装到平台中：用户，设备，应用程序。我们的api网关基于JWT数据对身份执行GET，以验证身份是否存在以及一切正常。此外，令牌生成/刷新与api网关无关，但是有一个已封装的auth服务器（一个是独立服务器，另一个仍嵌入到整体中）。所有这些都会产生大量的负载，但是可以通过“ identites”缓存轻松缓解这种负载。请注意，当标识被更改时，或者至少要尽量少使用信息时，会使缓存无效，这样您就可以关心删除标识了

下一步，我们将要制造/购买一个更具结构化的身份验证服务器，该服务器将继续与网关集成，但可以独立扩展，并且更清晰，易于配置（可能使用某种UI）

作为云原生爱好者，我还查看了istio，其中除其他外还具有身份验证功能，但是我仍然需要了解是否适合我的方法，该方法需要进行一些自定义操作< / p>

API网关和ACL

1 个答案: