权限设计

[timzaak]

业务权限

整体的权限设计参考：https://github.com/lizepeng/app.io 并在此基础上，通过代码中的 WithAuth 来做登录权限。 然后 Permission 来做角色权限。这个地方设计还不够优雅，在重做中，主要考虑如何和 GraphQL 集成。

认证 OAuth 2.0

中文资料 ： 理解OAuth 2.0

oauth2.0-scala 项目， 所有基础的的流程都走通了。但是还剩下业务权限定义。业务权限直接按照上面的搞。

OAuth 2.0 可以混合在一起用。

微服务认证

微服务之间的权限认证 + 路由问题。权限认证和路由要综合在一起思考，这样会简单一些，按照目前的 Istio 的设计，是作为一个组件，由 Envoy 来代理处理认证路由过程， zipkin 负责调用链路记录。具体业务微服务由 Envoy 包裹起来，只需要关注业务逻辑即可。

数据权限

数据权限比较麻烦，各个地方用的不一样，例如全局搜索条件限定，数据资源按照 row 粒度对 Person／Group 进行授权。

这期间还涉及如何缓存问题。

另外，数据权限会在什么时候使用呢，是业务权限的补充？ 还是说更为宽泛的权限？

参考资料

认证鉴权与API权限控制在微服务架构中的设计与实现（一） OAuth 2和JWT - 如何设计安全的API？ Authentication: JWT usage vs session

[timzaak]

https://thecopenhagenbook.com/ 一本完整讲述如何做鉴权设计的书。

[timzaak]

Cedar 是 aws 开源的权限框架。 最基本语法单元为 permit\forbid principal action resource when ，算子为： == != in 等。还对 resource 类型做预置，十分契合AWS云平台这种类型项目。 它的用法:

1. 存储人员 or 角色的Policy structure，并加载进缓存。
2. 存储人员及其关联角色信息至缓存。
3. 请求来时，依据人员ID从缓存读取该人员以及其角色的Policy structure。
4. 填入 Cedar 参数，获取是否放行结果。

以上用法导致 PolicySet 反复构建。若 PolicySet 一次性全部构建，就涉及鉴权服务数据更新问题。目前没找到 PolicySet 动态更新的Rust Demo，大概率是要包一层 DashMap or Arc<RWLock> 来解决更新问题。

本想着把它 ➕ pingora + PG 做个鉴权中间件，但当前市场上此类竞品是 API Gateway，权限只是附带，更重要的是防攻击功能。 另外权限的复杂度，各类型的项目完全不同，有的简单只需要区分admin、viewer即可，有的复杂如 aws 平台。此外还需考虑开发者做架构的水平，实际工作中的大部分项目可以是一个单体打天下。

与之类似的是Casbin，不过它提供流行Web框架插件，可无缝集成进去，更适合小型项目（提供数据库Adapter）。