级联GraphQL访问控制

越来越多的数据库开始暴露 GraphQL 接口，从搞关系式数据库的 postgraphql 到弄图论数据库的 Neo4j-GraphQL Extension。

你只需要用 GraphQL Schema Defination Language 描述出你的业务模型，一个 GraphQL API 就从数据库上暴露了出来，接下来只需要在客户端写一些 query 就可以在很短的时间内搞定前后端交互……

等等，这样难道不像把 SQL 语句从前端发送到后端执行一样傻么？

我们还缺少一个鉴权层，缺少一个挡在数据库前的网关，至少执行以下两个步骤：

1. 确认用户身份，可信地把用户定位到图里的一个节点
2. 给客户端发来的 GraphQL 查询加上鉴权操作，判断用户节点是否拥有查看他想看的每个节点的权限

这两个步骤一定得在服务端完成，不然用户就可以构造出 AND 1=1 这样的伎俩来欺骗我们。

也就是说，我们需要一个能反向代理、并对 query 做一定修改的，级联的 GraphQL 网关。

权限管理模型

为了方便，我将参考 Palantir 经过实战检验的访问控制模型 [2] ，并以 Neo4J 作为存储数据的后端。

基本访问权限控制

每个确认身份的用户会归于一个或多个用户组，例如 Bob 同时处于 Group A 和 Group B。

而每个用户组会一对一地关联到一个访问控制条款（Access Control Item）上，也就是说 ACI 101 只描述了 Group A 的权限，ACI 102 只描述了 Group B 的权限 B。

最后我们把多个访问控制条款（ACI）总结为一个访问控制表（Access Control List），以便批量修改多个用户组对某一条信息的权限。

注意到访问控制条款描述了四种访问权限（d r w o）：

1. 可感知：搜索一个电话号码时能搜到它存在，但不知道是谁的；查看某个人档案时能知道他有一个属性是电话号码，但不知道是多少。你可以搜到一条建议「如果你想知道更多，请联系鹳狸猿 blabla……」
2. 可读：能搜到、能看到值
3. 可写：能搜到、能看到值、能修改值
4. 完全拥有：能搜到、能看到值、能修改值、能修改元信息（例如调整某个属性的某个数据来源记录对应的访问控制表）

对于一条信息，没有上述任意一种权限的用户就不可能以任何方式感知到知识的存在，也没法通过随机 ID（可能类似于 Facebook Relay 的 Base64 Global ID 实现）、时间信息等推理出一条信息的存在。

...

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: