本文作者结合实际经验和大家聊聊基于RBAC模型的后台用户和权限是如何设计的。 一起来看看吧~
一、项目背景 1.1 需求来源
前段时间，笔者所在的公司接到了多个客户的后台权限和角色请求。 讨论发现现有的产品后台架构不能很好的满足用户的需求，所以为了满足这些客户的需求，为以后可能的业务拓展打下基础，我们决定对后台用户进行迭代现有产品的系统。
1.2 需求的拆解
通过筛选需求，我们发现用户需求其实有两类：
二、理论基础
说到后台用户管理系统，绕不开的概念就是权限，任何账号都会有自己的用例。 但在大多数情况下，我们会对部分账户的使用场景进行一些限制。 如果直接给账户加上这样的限制，会出现两个问题：
所以角色的诞生指日可待。 我们通过抽象权限集来创建角色，并对角色进行修改，从而达到控制拥有该角色的账户权限修改的目的。
权限可以分为两类：数据权限和功能权限：
2.1 RBAC-0模型
2.1.1 简介
RBAC-0模型的特点是用户和角色是多对多的关系。 同一个用户具有多个角色的属性。 我们使用组织的概念来构建组织结构，从而实现角色数据权限的分配。 这样UI界面，单个用户账号的所有权限就是他所在组织的权限的积累。
2.1.2 例子
在RBAC-0模型中，用户A负责组织X的业务，用户B负责组织Y的财务工作。正常情况下，A和B自然不能查看对方的数据，但如果有一天， B由于业务需要需要协助处理X机构的财务事务，那么我们可以通过在用户B类需求中加入X机构的“财务”角色来实现。 业务结束后，B在X组织下的权限也可以通过暂停/删除操作来管理。
2.2 RBAC-1模型
基于RBAC-0模型，对于角色继承的概念，子角色可以继承父角色的权限，但是子角色的权限必须小于父角色的权限。
2.3 RBAC-2模型
与RBAC-0体系相比角色权限设计，RBAC-2体系在用户与角色之间、角色与角色之间增加了一些规则。
2.4 RBAC-3模型
RBAC-3模型也称为统一模型，它在RBAC-0的基础上包含了RBAC-1和RBAC-2模型的所有特征。
3. 设计流程 3.1 新账号属性
添加账号是用户系统最基本的功能。 添加账号需要获取账号的哪些参数决定了整个用户系统的数据维度。
这里不得不提的是USER_ID、登录账号、昵称的概念。
USER_ID：对应账号在系统中的唯一标识，可能不会显示给用户，比如微信的open_id和union_id程序开发，一般是添加账号时系统生成的，不能修改；
登录账号：在某些系统中，登录账号和USER_ID不一致。 同一个USER_ID可能对应多个登录账号。 比如微信可以通过微信号、手机号、邮箱登录。 这里的不同登录方式对应这个登录账号。 ,一般由用户在添加账号时输入，不可修改；
昵称：昵称可由用户自由编辑，由用户输入，允许修改。
3.2 如何处理功能权限
功能权限是通过修改角色的权限树来实现的。 在权限树中，我们可以列出页面权限、菜单权限和按钮权限，通过过滤对应的权限完成角色功能权限的控制。
需要注意的一个问题是权限控制的最小粒度。 如果要实现对各个权限的控制，就相当于封装了各个权限对应的功能。 大页面和菜单权限是必须的，但是哪些按钮权限可以打包在一起（比如“启用”和“暂停”一般成对出现）角色权限设计，这些需要产品自己考虑。
3.3 如何处理数据权限
数据权限其实是角色权限的一个重要属性，但是由于数据范围太过灵活，如果给角色增加“数据权限”选项卡，如果账号下的数据量很大，用户编辑的操作数据权限会很麻烦。 因此，目前主流的后台设计都会采用“组织结构”来对应数据权限。
在系统中，我们使用【Add Organization】方法来处理数据权限。
3.4 老用户的兼容性
在重构用户系统时，老用户的账号兼容性是产品必须考虑的一部分。 兼容性问题也是从功能和数据两个维度验证新系统对老用户是否有影响。
四。 概括
文章内容主要讲述本次迭代中的实际使用场景。 本着他山之石可挖的思想，我在参考现有资料的基础上，结合自己系统的实际情况，对用户系统的设计进行了总结。 如有不足，请多多交流，共同进步。
