API 网关和 ACL
Posted
技术标签:
【中文标题】API 网关和 ACL【英文标题】:API Gateway and ACL 【发布时间】:2019-01-31 07:18:05 【问题描述】:我正在设计一个基于微服务的应用程序,它有两个 API 端点,其中一个用于用户访问。通过 JWT 进行身份验证的用户可以属于不同的组织,这些组织又按层次结构进行组织。每个用户都可以有一些角色,这些角色是为每种组织类型定义的;组织和角色之间的组合定义了可以从用户(方法和资源)访问的 API。总之,它可能会变得一团糟!
有几个库提供 ACL 功能,但我想知道将它们放在哪里:第一个解决方案似乎是 API 网关,它应该为每个请求调用一个组件。
-JWT 包含用户的角色 ID 列表 -API 网关验证 JWT 并使用角色 ID 在表中查找每个角色都有权限列表(例如,可以 POST /users) - 如果角色与请求匹配,则将后者转发到正确的服务;否则,网关以 403 响应
另一种选择是将“身份验证服务”放入架构中。网关只是将所有请求转发到正确的服务,每个服务(可能依赖于公共库)将令牌发送到身份验证服务并请求授权以满足请求。在这种情况下,auth 服务是 /auth 资源下所有请求的“正确服务”,提供登录/注销、令牌刷新和新用户注册(例如当您单击登录邮件中提供的链接时)
第一个解决方案提供了一个“胖网关”,它有一个微小的逻辑层,但强制所有服务仅响应安全调用,分解所有身份验证/orization 逻辑并且不添加服务之间的依赖关系,但
p>-
这是正确的做法吗?
是否有提供该功能的 api 网关实现
这两种方法还有一些我看不到的其他优点/缺点
谢谢你的回答!!!
【问题讨论】:
您可能对 PolicyServer 的概念感兴趣:leastprivilege.com/2018/01/17/announcing-policyserver 另请查看演示视频:vimeo.com/223982185 谢谢!我看一眼! 您确定了解决方案@sscnapoli1926 吗?我现在正在思考完全相同的事情 @osteel ,现在,我们决定将 auth-service 排除在外:由于我们观察到与 api 网关的耦合,我们计划将其转换为插件以添加到我们的网关,使用 express-gateway (express-gateway.io) 实现。当工作完成时,我会在这里分享印象和结果! @sscnapoli1926 感谢您回复我并分享您的方法。我可以看到将授权提取到自己的组件中的吸引力,因此微服务不需要处理它。就我而言,我倾向于第三种方法,即确实将身份验证留给网关,但让每个微服务负责自己的授权规则。 【参考方案1】:我回来分享我对围绕帖子主题做出的选择的看法。我遵循的方式是
API Gateway 知道与请求一起发送的身份验证数据( “授权标头”在实践中)并进行验证。 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 网关问题,但有一个连接的身份验证服务器(一个是独立的,另一个仍然嵌入到整体中)。所有这些都会产生大量负载,但可以通过“identites”缓存轻松缓解。请注意在身份发生突变时使缓存无效,或者至少尝试使用尽可能少的信息,这样您就可以只关心身份删除
我们接下来的步骤将是制造/购买一个更结构化的身份验证服务器,该服务器将继续与网关集成,但能够独立扩展并且更清晰和易于配置,可能带有某种 UI
作为云原生粉丝,我也在关注istio,它具有身份验证功能等,但我仍然需要了解是否适合我的方法,需要能够进行一些定制
【讨论】:
以上是关于API 网关和 ACL的主要内容,如果未能解决你的问题,请参考以下文章
Kong Gateway - 11 基于网关服务的ACL访问控制列表 黑名单