前言

前段时间打算使用React重构现有的Angular项目，梳理了一下项目中的权限管理逻辑。由于现有的权限管控不够细（甚至可以说没有权限管控），所以我从网上了解了下主流的五种权限模型。

主流的权限模型

主要分为以下5种：

ACL，访问控制列表

ACL是最早的、最基本的一种访问控制机制，是基于客体进行控制的模型。为了解决相同权限的用户挨个配置的问题，后来也采用了用户组的方式。

原理：每个客体都有一个行为列表，列表中记录的是具有该行为的主体。

例如：用户A要对一篇文章进行编辑时，ACL会先检查一下文章编辑功能的控制列表中有没有用户A，有就可以标记，无则不能编辑。

缺点：当主体的数量较多时，配置和维护工作就会成本大、易出错。

DAC，自主访问控制

DAC是ACL的一种扩展。

原理：在ACL模型基础上，允许主体将自己拥有的权限自由地授予其他主体，权限可以任意传递。常见于文件系统。

缺点：对权限控制比较分散，无法将一组权限统一的授予一群指定用户。主体权限太大，无意间就可能泄漏信息。

MAC，强制访问控制

MAC模型中主要的是双向验证机制。常见于机密机构或其他等级观念强烈的行业。

原理：主体有一个权限标识，客体也有一个权限标识。主体能否操作该客体取决于双方的权限标识的关系。

例如：员工等级分为经理>组长>组员，文件保密等级分为绝密>机密>秘密，不同的员工等级只能访问不同保密等级的文件，如：组员只能访问秘密文件；组长只能访问机密、秘密文件。当某一用户访问某一文件时，系统会验证账号的员工等级和文件的保密等级，当员工等级和文件的保密等级相对应时才可以访问。

缺点：控制太严格，实现工作量大，缺乏灵活性。

ABAC，基于属性的访问控制

ABAC在新增资源时容易维护，有更加细粒度控制和根据上下文动态执行。

原理：通过动态计算一个或一组属性来判断是否满足某种条件来进行授权判断。

缺点：规则复杂，不易看出主体与客体间的关系，模型实现非常难。

RBAC，基于角色的访问控制

RBAC核心在于用户只与角色关联，角色代表一系列权限的集合。用户通过成为角色的成员从而得到对应角色的权限。

RBAC的3个组成部分：

RBAC的安全原则：

优点：

便于授权管理便于角色划分便于赋予最小权限原则便于职责分离便于客体分类

缺点：没有提供操作顺序的控制机制，很难适应那些对操作顺序有严格要求的系统

RBAC的拓展RABC0模型

用户和角色是多对多关系，角色和权限也是如此。如图：

RBAC1模型

RBAC1基于RBAC0模型，引入了角色间的继承关系，角色有了上下级的区别。

如果采用RBAC0模型，可能需要为经理、组长、组员分别创建一个角色（角色之间权限无继承性），极可能出现由于权限配置错误，组员拥有经理都没有的权限。

RBAC1模型很好的解决了这个问题，创建完经理角色并配置好权限后，组长、组员继承经理角色的权限，并且支持调整权限。

RBAC2模型

RBAC2基于RBAC0模型，对角色增加了更多约束条件，比如：互斥、数量限制。确保权限系统的目标：权责明确，系统使用安全、保密。

RBAC3模型

同样基于RBAC0模型，但综合了RBAC1和RBAC2的所有特点。

最后说下公司项目中权限管控的问题

我们的系统中有用户、员工、租户、角色、应用5种概念：

用一张图表达一下吧：

虽然我们可以在应用中根据角色进行一些简单的权限管控（比如：只有超级管理员才能够访问系统设置页面），但实际上角色与应用前台无关。无法给角色配置权限点实现对应用的权限管控，角色的意义、作用没能得到体现。

参考RBAC模型角色与权限绑定，在应用中根据角色权限进行权限管控，所以我认为正确的权限模型应该是这样：