前段时间分别用vue和react写了两个后台管理系统的模板vue-quasar-admin和3YAdmin。两个项目中都实现了基于RBAC的权限控制。因为本职工作是后端开发，比较清楚权限控制一个管理系统应该必须具备的核心功能，而且是可以做到通用的。打算写写关于管理系统前后端分离方面的文章，也是做一个知识的总结，其中会涉及到vue,react,node,.net core等方面的知识。

术语描述

• 用户(Subject)：发起操作的主体
• 对象(Object)：指操作所针对的客体对象，比如文章或评论
• 权限(Permission)：用来指代对某种对象的某一种操作，例如“添加文章的操作”
• 权限码：权限的代号，例如用“ARTICLE_ADD”来指代“添加文章的操作”权限

权限有时候也可以称为动作或者功能。比如“添加文章”，既可以认为它是一个动作，也可以认为它是一个功能。对象也可以称为资源。

常用的权限模型

• ACL(Access Control List)(访问控制列表)
• DAC(Discretionary Access Control)(自主访问控制)
• MAC(Mandatory Access Control)(强制访问控制)
• RBAC(Role-Based Access Control)(基于角色的访问控制)
• ABAC(Attribute-Based Access Control)(基于属性的访问控制)

ACL(Access Control List)(访问控制列表)

ACL是最早也是最基本的一种访问控制机制，它是用来描述用户和权限之间关系的数据列表。它的原理非常简单：每一项资源，都配有一个列表，这个列表记录的就是哪些用户可以对这项资源执行CRUD等操作。当试图访问这项资源时，会首先检查这个列表中是否有关于当前用户的访问权限，从而确定当前用户可否执行相应的操作。

例如一个文件对象的 ACL 为 Alice: read,write; Bob: read，这代表 Alice 对该文件既能读又能写，而 Bob 只能读取。

由于ACL的简单性，使得它几乎不需要任何基础设施就可以完成访问控制。但同时它的缺点也是很明显的，由于需要维护大量的访问权限列表，ACL在性能上有明显的缺陷。另外，对于拥有大量用户与众多资源的应用，管理访问控制列表本身就变成非常繁重的工作。

最开始的ACL定义中，用户直接和权限挂钩，数据存储的是用户与权限的关联关系。如果两个用户的权限是一样的，那么就需要分别存储这两个用户与权限的关联关系，也是上面所提到的ACL的缺陷。为了解决这些问题，便有了对ACL设计的改进，相同权限的用户放到同一个分组里，分组与权限挂钩，不再是用户直接与权限挂钩。以及后来出现的RBAC(基于角色的访问控制)，角色与分组也是差不多的概念，角色直接与权限挂钩，用户再与角色进行关联。

所以，现在一般说ACL,不再是用户直接和权限挂钩的一种权限控制模型，把它看做一个单纯的访问控制列表即可。列表里维护的可能是用户与权限的关系，也可以是用户组与权限的关系，也可以是角色与权限的关系，甚至是部门，职位等等于权限的关系。

ACL是权限体系中的业务规则。RBAC等权限模型要用到ACL才能工作，ACL服务于RBAC等权限模型，其它权限控制体系里的权限规则也叫ACL。

DAC(Discretionary Access Control)(自主访问控制)

系统会识别用户，然后根据被操作对象（Subject）的权限控制列表（ACL: Access Control List）或者权限控制矩阵（ACL: Access Control Matrix）的信息来决定用户的是否能对其进行哪些操作，例如读取或修改。
而拥有对象权限的用户，又可以将该对象的权限分配给其他用户，所以称之为“自主（Discretionary）”控制。

因为用户能自主地将自己拥有的权限授予其他用户，所以DAC模型可以任意传递权限，用户能间接获得本不具有的访问权限，因此DAC模型的安全性较低，不能给系统充分的数据保护。

DAC可以直接使用ACL的物理模型，区别在于，DAC模型中用户可以将自己具备的权限分配给其它用户(程序里的操作就是根据用户ID筛选出权限列表，根据列表为要分配权限的用户构造出新的权限列表并保存)

DAC是传统的UNIX访问控制模型，也是Windows文件系统的访问控制模型。

Windows的文件访问权限的设置中，除了用户，还有组。这个组与后面要说到的RABC模型的角色有什么区别呢？

https://stackoverflow.com/questions/7770728/group-vs-role-any-real-difference

我认为没必要去划分的太清楚，不管是组还是角色，都是为了更好的管理和分配权限在最原始的ACL模型上做的改进。如果有需要，甚至可以把权限分配到部门，职位上。

MAC(Mandatory Access Control)(强制访问控制)

MAC是为了弥补DAC权限控制过于分散的问题而诞生的。在MAC的设计中，每一个对象都有一些权限标识，每个用户同样也会有一些权限标识，而用户能否对该对象进行操作取决于双方的权限标识的关系，这个限制判断通常是由系统硬性限制的。访问时，系统先对用户的访问许可级别和资源对象的密级进行比较，再决定用户是否可以访问资源对象。用户不能改变自身和资源对象的安全级别，只有系统管理员或管理程序才能 控制资源对象和用户的级别。比如在影视作品中我们经常能看到特工在查询机密文件时，屏幕提示需要“无法访问，需要一级安全许可”，这个例子中，文件上就有“一级安全许可”的权限标识，而用户并不具有。

MAC非常适合机密机构或者其他等级观念强烈的行业，但对于类似商业服务系统，则因为不够灵活而不能适用。

MAC可以继续使用DAC的模型，但是要对用户进行等级划分，比如一级，二级，三级。。。，对对象资源也要做划分，比如机密，秘密和最高机密。用户访问的资源的时候，根据用户等级与资源访问级别来做判断，比如一级用户只能访问机密文件，如果访问的是最高机密文件，系统就会拒绝。这一系列规则是优先于DAC的，如果MAC与DAC混用，要先校验MAC再校验DAC。

RBAC(Role-Based Access Control)(基于角色的访问控制)

ACL的访问控制机制中，直接维护的是用户与功能的关系，这一系列的关系就是一个权限列表。当很多的用户具有相同功能权限的时候，就要进行繁琐的关联操作。RBAC就是在用户与权限之间引入了角色的概念。用户与角色之间做关联，权限列表维护的是角色与功能的关系。

RBAC是目前使用最普遍的权限控制模型。当某些用户具备相同的权限的时候，只需要为这些用户建一个角色，把相应的功能关联到这个角色上，生成角色的权限列表。当有新的用户需要相同权限的时候，把用户关联到这个角色上即可。而当用检查或校验用户的操作权限的时候，查询用户所属角色的权限列表即可。

当然，RBAC也不是完美的，比如想要为某个用户单独设置某个功能权限，可能需要为这个功能权限单独创建一个角色，然后把特定的用户关联到这个角色上。当想要移除某个用户的特定功能权限的时候，可能需要重新设置角色的功能权限，把特定功能权限从当前角色中移除