在涉及到有用户的系统里，权限管控可能是不可或缺的组成部分。
权限管理的本质实际上就是解决2个问题：授权、鉴权。授权即给用户分配权限，鉴权即询问用户是否有权限。
本文不讨论经典的权限管理模型，比如RBAC、ABAC和ACL，而是介绍一个简单且通用的权限管理系统，大家如果觉得有用，可以借鉴并使用，当然也欢迎参与进来。
GitHub开源地址: github.com/veops/acl
整体架构
从图中可以看出，ACL主要包括的概念：应用、用户、角色、资源、权限。
应用: 即接入到ACL里的系统。为什么要引入应用的概念，是因为ACL可以按接入的应用来进行权限隔离。
用户: 每个用户有唯一的用户角色，图中用户和角色的多对多，实际上是用户角色和其他角色之间的关系。
角色: 包括用户角色和虚拟角色，角色之间可以继承。
资源: 被管控的对象，比如页面、目录、操作、数据等等都可定义为资源
权限： 即对资源的操作，比如查看、修改、增加、删除等
因此，ACL的授权就是资源的操作权限被授予给角色；鉴权即询问角色是否有某个资源的某一操作权限？
下面从用户和角色、资源权限、应用、触发器、操作审计5个方面来对该系统的进行阐述
01 用户和角色
ACL里新建一个用户的时候，会自动创建一个对应的用户角色，授权和鉴权都是针对角色的，不直接针对用户。除了用户角色之外，其它角色叫虚拟角色。
角色按照作用域又可以划分为: 全局角色、应用角色，全局角色在所用应用里都可以被赋权，应用角色顾名思义只会出现在应用里，其他应用看不到该角色。
如上图所示，角色管理页面里的角色即为全局角色，每个应用下的角色管理页面里呈现的是全局角色+应用角色。图中可以看到角色有是否是管理员、继承2个重要属性。如果一个用户被赋予管理员角色，他就能在ACL里进行权限管理。角色继承是为了简化权限管理，继承的是父节点的所有权限。如下图所示：
在角色管理页面可以建立如图所示的继承关系，明显最底层角色拥有的权限是最大的。具体在实践的时候，一般虚拟角色可以是：团队、小组、部门等，上图的继承关系可以抽象成公司的组织架构，第一层可以是团队，第二层是部门，第三层是公司。
02 资源权限
资源即被管控的对象，权限就是对资源的操作，每个资源都有一个资源类型。如下图，
资源类型是按照不同应用对权限的需求来创建的，每一个资源类型会关联多个权限。资源类型的实例即资源。资源管理页面如下图所示，每个资源类型下管理的是资源列表，可以对资源进行授权: 即把该资源的某几个权限授权给某角色。
03 应用
有权限管理需求的系统在接入ACL之前，首先要在ACL的应用管理页面里创建一个应用。
AppId和SecretKey无需用户填写，创建完成之后，点击这个应用的编辑按钮可以看到该应用的AppId和SecretKey，它俩主要用来调用ACL的相关接口进行授权和鉴权。当然项目也给了接入示例: github.com/veops/acl/b…
04 触发器
触发器是为了方便授权而引入的。可能存在这样的场景: 某资源类型下的资源是动态改变的，但是这些资源需要授权给角色A，只需在触发器里增加一个规则，便可完成自动授权！否则，在增删资源的时候，业务逻辑需要给角色A做授权操作。
05 操作审计
权限、角色、资源、资源类型以及触发器的任意变更都会记录在系统里，便于审计。
总结
本文提出的是一个集中式的且比较通用的权限管理解决方案，基本上能覆盖绝大多数权限需求场景。这样在开发一个新的应用的时候，可以专注业务逻辑，不用每个应用单独实现一套权限管理逻辑。
