说明
该文章是属于OverallAuth2.0系列文章，每周更新一篇该系列文章（从0到1完成系统开发）。
该系统文章，我会尽量说的非常详细，做到不管新手、老手都能看懂。
说明：OverallAuth2.0 是一个简单、易懂、功能强大的权限+可视化流程管理系统。
友情提醒：本篇文章是属于系列文章，看该文章前，建议先看之前文章，可以更好理解项目结构。
qq群：801913255，进群有什么不懂的尽管问，群主都会耐心解答。
关注我，学不会你来打我
注意：该文章是理论篇，后面会有开发的全过程。有兴趣的朋友，请关注我吧(*^▽^*)。
01 系统权限的划分
通常来说，一个系统权限的划分，主要分位2大类：功能级权限和数据级权限。那么它们是如何分类的，我们看下图。
02 权限的设计模式有哪些
了解了一个系统的权限划分后，那么我们要如何去规划，设计这些权限。尽量减少系统权限的维护成本和权限的耦合度。是开发人员一直面临的严峻问题。
据我的了解，目前比较流行的权限设计模式有以下四种。
通过上图，我们可以了解到权限的设计模式分为那四种，那么接下来我们就用《小说》的形式，分别讲一下这四种模式的使用场景及实现过程。
03 ACL基于用户的权限设计
乘风是一家创业公司的开发人员，由于是创业公司，规模不大，研发人员也只有可怜的3人，平时面临的研发任务非常紧张。某天的傍晚，乘风狠狠地伸了个懒腰，环顾四周空荡荡的座位。正准备收拾东西回家的时候，老板叫住了他。小乘，怎么财务的小红能看到运营的数据，可以让不同的人查看不同的数据嘛。乘风的老板也不怎么懂技术，需求就说了一句：让不同的人员看到不同的数据。乘风自信的回答道：可以的老板。第二天，乘风就根据老板的需求基于ACL整理出了一套权限管理的方案。
以上就是乘风基于ACL设计的权限。可以看出菜单和人员直接挂钩，可以简单有效的做到每个员工访问不同的菜单，从而实现老板的需求。
04 RABC基于角色的权限设计
4.1角色权限
随着时间的推移，公司也处于快速发展阶段，终于在2年后的某一天。公司老板找到已经是研发组长的乘风说道：小乘啊，今天早上运营给我说，他们现在每天花在分配人员权限上的时间过多，每次有人员变动、人员加入都需要重新调整权限，而且不能成批量操作，大大降低了他们的工作效率。你看有什么办法解决这个问题没有。
乘风一听，毫不犹豫的说道。有的老板，明天我给你出一个方案。
老板一听很高兴，拍了拍乘风的肩膀离开了，他非常欣赏乘风这种办事风格，干净利落，总能解决问题。
乘风的自信来源于他一复一日的学习和专研。他明白用RABC就能完美解决老板的需求。于是他在第二天就做出了如下方案设计
上述2张图它的授权结果是一样的，但是很明显基于RABC的授权方式更加灵活。原因在于乘风在人员和权限之间抽象出一个角色层，这样不仅能减少系统之间的耦合，还能大大降低运营人员的运维时间。
为什么这么说，举一个简单的例子：当【权限4】这块权限不想让任何人使用，那么在RABC中，我只需要把它从【角色3】中移除即可。反观ACL就比较麻烦，需要先后移除人员1和人员3的权限。试想一下这是3个员工，如果是10个100个，得有多麻烦。
很快乘风的方案得到了老板的肯定，并且给他升职加薪。
4.2 角色等级权限
这种设计模式很快就实现并用于系统之中，也确实大大解决了很多实际性问题。然而好景不长，公司在接下来的时间中，发展的越来越快，规模越来越大。这种设计方式也出现了和ACL同样的问题。当用户权限分的很细的时候，几乎每个用户都对应一个角色。似乎又回到了几年前ACL设计模式的样子。
于是乘风通过不断地对系统的分析和对技术的专研，希望能从其中得到有效的解决办法。
可能是日有所思，夜有所梦。在某一天的晚上，乘风在睡梦中得到了解决办法。他梦见。。。把之前设定的角色制定了等级。也就是说高等级的角色会继承低等级角色的所有权限。
得到答案的乘风，也不困了，来不及穿衣服裤子。就这样穿着一条大裤衩打开电脑，画出了如下设计方案。
你没看错，其实就是和组织机构类似，那么我们如何实现呢？请看下图
可以看到【角色1-2】它是继承了【角色1-2-1】的所有权限。根据这一原理，我们不用在为【角色1-2】单独在赋予权限3和权限4。
啊嚏，乘风摸了摸鼻子。一个喷嚏让他在意识到自己全身上下就只剩一条大裤衩。看着设计方案乘风淡淡的说了一句。
难道我真的是天才？随后就进入梦乡。
05 ABAC基于属性的权限设计
岁月悠悠，人生如梦，转眼间又过去了几年。乘风也不再年轻，不是当前刚进公司的小白，但也正是如此。他仿佛失去了当年对技术的向往和专研热情，因为他总觉得自己的技术已经处于很高的水平。直到有一天，老板又找到了他。
小乘，老板推开乘风的办公室，见乘风正在泡茶，眉头稍稍一皱，但随后很快就消失。
老板，乘风没有发现老板的异常，起身道
小乘，昨天我去财务部视察的时候发现，财务部的小李居然能看到我们公司所有员工的工资。按道理说除了财务经理有权限查看之外，财务部下面的人应该都不具备查看员工工资的权限。
还有人事部的小张，他怎么能随意查看公司领导层的人事资料，甚至能随意修改，这不是胡闹嘛？
你是研发部的负责人，你应该考虑考虑，系统的数据安全，那写人能看什么数据，能修改什么数据，要做到可调控。
接下来的时间中，乘风老板和他聊了很多。大多数都是围绕数据安全的问题展开。
对了，你的茶具还挺全，整的不错。走到门口的老板，忽然转身对乘风说道。
老板最后的话，让乘风陷入了深深的沉思之中。
回忆过去自己，从一开始的积极提升能力到如今的懈怠、自满，内心有一种说不出的感觉。
今天老板的话，让他意识到很多。总结后的乘风，下定决心要找回自己，然后根据老板简述的需求，总结如下
1：不同的人需要查看不同的数据，做到可调控。
2：不同的人对数据有不同的操作权限，做到可调控。
这些问题的出现，让乘风很是头疼，不知从何下手。于是他仿佛回到过去的自己，努力查阅资料，提升技能。
终于得到了一个有效的解决办法。那就是ABAC基于属性的权限设计也就是说ABAC可以通过动态计算一个或者一组属性来进行权限控制。
那么ABAC属性大致分位哪些？
得到答案的乘风，马上着手设计ABAC基于属性的权限设计。很快就完成权限系统的迭代。
随着了解的越多，乘风也开始总结自身存在的问题。之前哪点对自己技术的自信，现在看来就是自负和自满。技术没有顶峰，只有不断的求知、探索。
06 RABC+ABAC的权限设计
这个不必多说，就是字面的意思。我们的OverallAuth2.0就使用RABC+ABAC的权限设计。
以上就是本篇文章的全部内容，感谢耐心观看
后端WebApi 预览地址：http://139.155.137.144:8880/swagger/index.html
前端vue 预览地址：http://139.155.137.144:8881
关注公众号：发送【权限】，获取前后端代码
有兴趣的朋友，请关注我微信公众号吧(*^▽^*)。
关注我：一个全栈多端的宝藏博主，定时分享技术文章，不定时分享开源项目。关注我，带你认识不一样的程序世界
