权限系统基础知识笔记
自我简介：4年导游，10年程序员，最近6年一直深耕低代码领域，分享低代码和AI领域见解。
一直想实现一套相对完善的权限控制系统。在实践过程中总结了一些权限相关的基础知识。准备基于 go-micro + Casbin + And-Design-Pro 实现 RBAC 模型的权限管理.
仓库地址：Accbase
在项目中经常有的场景是不同的用户的权限不同。
常有如下场景：
- 不同的用户在页面中可以看到的元素和操作不同
- 不同的用户对页面的访问权限不同
权限是什么？
权限管理是后台系统经常会涉及的模块，主要是对不同的用户访问资源进行权限的控制，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，账号过期，隐私数据泄露等问题。
功能划分
权限管理系统总体分为：授权与认证。
授权：指将权限授予角色或用户。认证：指用户访问资源的某些操作时，根据授权，判断是否允许用户的访问。
基础概念
权限模型
- RBAC模型,基于角色的访问控制（Role-Based Access Control)。抽象为
Who（权限的拥有者或主体 Group，Role）对What(Which)（权限针对的对象或资源）进行How（具体的权限）的操作。通过角色关联用户，角色关联权限的方式间接赋予用户权限，构成“用户-角色-权限-资源”的授权模型。 - ABAC模型,基于属性的访问控制(Attribute-Based Access Control)。四个核心元素分别为:用户、资源、环境和操作。用户是请求访问系统资源的实体,可以是个人、程序或设备。资源是需要保护的系统实体，如文件、数据库、应用程序等。环境包括访问发生时的上下文信息，如时间、地点、安全级别等。操作是用户请求对资源执行的行为，如读取、写入、删除等。
权限名词
资源 (Resources)：资源就是想要的到的最终物质。菜单、页面、按钮、API、数据等均为资源。用户 (User)：是发起操作的主体,按类型分可分为2B和2C用户,可以是后台管理系统的用户等。角色（Role）：是中间量，连接了用户和权限的关系,每个角色可以关联多个权限,同时一个用户关联多个角色,那么这个用户就有了多个角色的多个权限。使得授权操作便捷易拓展。角色不能随意删除或禁用。角色支持继承和互斥（如用户不能同时具备申请和审批人的角色）权限 （Permissions）：是用户可以访问的资源。- 页面权限：即用户登录系统可以看到的页面,由菜单来控制,菜单包括一级菜单和二级菜单,只要用户有一级和二级菜单的权限,那么用户就可以访问页面。
- 操作权限：即页面的功能按钮,包括查看,新增,修改,删除,审核等,用户点击删除按钮时,后台会校验用户角色下的所有权限是否包含该删除权限。
- 数据权限：即不同用户在同一页面看到的数据是不同的,比如财务部只能看到其部门下的用户数据,比如杭州分公司用户登录系统只能看到杭州的数据。（解决方案一般是把数据和具体的组织架构关联起来,举个例子,在给用户授权的时候,用户选择某个角色同时绑定组织如财务部或者合肥分公司,那么该用户就有了该角色下财务部或合肥分公司下的的数据权限）
用户组 (Group)：当平台用户基数增大，角色类型增多时，管理员直接给用户组分配角色,用户组里的每个用户即可拥有该角色，而不用操作每个用户完成授权。组织（Organization）：可以把组织与角色进行关联,用户加入组织后,就会自动获得该组织的全部角色,无须管理员手动授予,同时用户在调岗时,只需调整组织,角色即可批量调整。组织的另外一个作用是控制数据权限,把角色关联到组织,那么该角色只能看到该组织下的数据权限。组织是一个集合。职位（Post）：每个组织部门下都会有多个职位，每个职位的权限是不同的。职位是针对人的个体。菜单（Menu）：用户登录系统可以看到的页面，可以有多层级。策略：是模型中定义访问规则的语句，描述了在什么条件下可以执行哪些操作。策略通常由安全管理员定义，并可以随时更新以适应组织的变化。
关联关系
- 用户和角色是多对一/多的关系
- 角色和权限是多对多的关系
授权流程
手动授权：给用户添加角色,给角色添加用户。给用户添加角色就是在用户管理页面,点击某个用户去授予角色,可以一次为用户添加多个角色;给角色添加用户就是在角色管理页面,点击某个角色,选择多个用户,实现了给批量用户授予角色的目的。审批授权：即用户申请某个职位角色,那么用户通过OA流程申请该角色,然后由上级审批,该用户即可拥有该角色,不需要系统管理员手动授予。
权限系统需求
- 系统拥有一个超级管理员，拥有系统所有权限
- 不同的用户在页面中可以看到的元素和操作不同
- 不同的用户对页面的访问权限不同
- 操作包括：增删改查审核等
- 用户拥有多个角色，那么用户的权限是这些角色权限的合集
- 授权操作时选中即生效，无需提交
- 用户(User)（帐号）可以拥有多个角色(Role)，角色可以被分配给多个用户
- 每个用户组的管理员都具有创建角色的能力，并且自己管理这自己的角色
- 每个用户组的管理员都有添加用户，授予用户权限的能力
- 用户仅仅是纯粹的用户，用来记录用户相关信息，如用户名、密码等，权限是被分离出去了的。用户（User）要拥有对某种资源的权限，必须通过角色（Role）去关联。
- 角色是使用权限的基本单位，拥有一定数量的权限，通过角色赋予用户权限
- 权限指用户根据角色获得对程序某些功能的操作，例如对文件的读、写、修改和删除功能
- 账号有效期
- 注意区分角色和职位
- 给组织的总部分配账号。组织的管理员，然后自己维护下级数据
数据表
- 用户表（帐号）（UserInfo）（将用户的最基本的信息进行管理(在正常的业务系统中可进行扩展用户信息)，比如姓名、有效期等）
- 角色表（RoleInfo）（对角色基本信息进行管理。用户可以自定义成各种各样的角色）
- 菜单表（MenuInfo）
- 用户角色表（UserRole）（在用户与角色之间建立起关联，给用户授予哪些角色权限(同一用户可以有多个角色)，也可以按角色添加用户，比如将“员工”角色授予公司所有人，而不用按用户一个一个地授权）
- 角色菜单表（RoleMenu）
- 角色权限表 （RolePromissions） （将角色与系统中的权限点关联起来，也就是完成授权的动作）
- 操作表 （Action）（用来存放用户自定义的各种功能操作，比如新增、修改、删除等）
- 页面元素表 (Element)
AI时代，对各行业的冲击力只会越来越大，随着AI大模型的竞赛，越来越多强悍的AI模型都会涌现，像软件开发行业的很多工作都会被取代。软件将不再是程序员的专属产物，会由AI创建很多的软件产品。
4年导游，10年程序员，深耕低代码领域6年，持续分享低代码和AI领域领域有价值的思考和沉淀，欢迎关注：winyh5
后续会推出：【挑战365天做 100 套常见的互联网系统】系列文章，让大家可以真实感受到低代码快速落地项目的可行性