前段时间分别用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