今天与大家分享一次能力开放平台的授权设计过程，该设计已经成功实现并交予项目使用。软件设计的过程和炼丹的过程十分相似， 目的都是去伪存真， 把需要满足的所有场景展现在脑海中，不断找他们之间的关系，提炼抽象，最终得到最简单的模型，再用模型去满足所有场景的需求。

能力开放平台中所有的资源都是通过API对外提供服务的。我们主要针对API做授权控制。

我们罗列一下可能出现的控制场景：

接口访问控制。具有权限的用户可以访问该接口。接口入参参数授权。入参的格式是接口能力需要并定义的，所以只会对入参的值做权限限制，如某些人对入参中某个字段只能输入固定的值，入参参数满足某个条件时才具有该接口的访问权限。接口返回参数授权。出参中对访问者中某些字段做模糊，不可见的控制。同一个接口，不同的人可能处理逻辑都不一样，例如用户是省级管理者，可以查询全省的数据，如果是市级管理者，管理员，同一个组的人，服务创建者....，返回的结构一样，业务数据不一样。针对平台中数据元素，数据对象。对不同的用户可以拒绝访问，某些字段需要模糊化或不可见。还有一些特殊数据的控制。如菜单数据。

经过总结提炼，设计如下图

能力开放接口授权控制

1。服务控制

配置角色和接口名称的关系，角色有对应接口名称，就觉有该接口的访问权限。

提供根据用户ID，通过角色和配置信息判断是否具有访问该接口的权限。

配置角色和接口入参的关系，是一个表达式配置，根据上下文和入参做布尔表达式计算。

提供根据入参信息做布尔运算的接口，如果有配置信息，且运算结果为false，则不能访问该接口。

配置角色和返回参数的关系，是一个返回参数的结构，如果要模糊某个字段，需要在这个字段加在模糊函数，如果是隐藏某个字段，需要在这个字段加上删除函数。

提供真实出参和配置结构的转换接口，供把实际参数根据配置结构转换，并执行对应的函数。

用户访问某个接口验证通过后，会标记一下通过的方式：管理员/授权组/自有/服务授权，被访问的接口逻辑如果有对这些授权方式不同的逻辑的，需要接口内部自行实现。

2。数据控制

服务控制可以控制所有的接口访问限制，但是控制粒度太细，配置繁琐。常常会对访问的数据对象做限制，毕竟接口的一半功能是提供数据。在平台内维护数据字段字典和数据对象。

配置数据对象和角色的关系，角色拥有数据对象的关系，就可以访问这个数据对象。

配置数据对象中的某些字段和角色的关系，这些字段需要模糊处理或隐藏。

在数据操作层，根据角色和配置信息，对操作前检查，是否有访问对象的权限，对操作返回的数据结果做处理，哪些字段需要做模糊或删除处理。

2。特殊控制

某些特殊数据（没有在数据对象中的数据）的控制，如菜单结构数据。

异常信息，不同的角色获取到的异常信息不一样，如开发者获取到堆栈信息，操作员获取到系统错误信息，用户获取到联系信息。

用户的这些授权配置信息，在用户登录的时候一次性加载到集中式缓存中。

请求访问某个接口前会先判断用户通过校验的类型，主要可以分为：是否管理员、是否某个群授权、是否访问的是自己创建的服务、是否服务授权、是否特殊权限。校验通过后在上下文环境中打上标记。

总结：这一套授权控制考虑到了服务，入参，逻辑，出参，访问的数据，代码中的数据。自认是一套比较周全的控制模型，并可以从服务，数据，服务中的数据三个方向做功能扩展。除非出现了不在这三个方向的控制元素，那就无法控制了。

大家也帮忙审查一下是否有哪个场景不能控制到呢？ 谢谢！