开源项目ZXX-CAS系统从零到一|第四篇：A-RBAC权限服务设计与实现

Posted 2021-04-30 码农周星星

“ ZXX-CAS如何设计基于应用的权限相关功能，RBAC是什么？A-RBAC又是什么？如何快速使用写代码的方式画UML图呢？”

上节内容主要解决了集成Mybtais-plus以及自动生成工具：

这一节内容，我们主要介绍RBAC与A-RBAC以及UML画图工具的使用

1、RBAC与A-RBAC

2、IDEA集成plantUML

3、基于应用角色的访问控制设计

    

01

—

RBAC与A-RBAC

RBAC（Role-Based Access Control，基于角色的访问控制），下面摘取网络上找到的关于RBAC的定义：

在20世纪90年代期间，大量的专家学者和专门研究单位对RBAC的概念进行了深入研究，先后提出了许多类型的RBAC模型，其中以美国George Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有系统性，得到普遍的公认。

RBAC认为权限的过程可以抽象概括为：判断【Who】是否可以对【What】进行【How】的访问操作（Operator）。

RBAC96是一个模型族，其中包括RBAC0~RBAC3四个概念性模型。

1、RBAC0定义了完全支持RBAC概念的任何系统的最低需求。 

2、RBAC1中增加了角色分级的概念，一个角色可以从另一个角色继承许可权3、 RBAC2中增加了一些限制，强调在RBAC的不同组件中在配置方面的一些限制。

4、RBAC3称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内。

这里我们采用最经典的权限系统五表模式进行系统权限的设计（属于RBAC0模式），分别是用户表（cas_user）、角色表(cas_role)、权限表(cas_permission)、用户角色关联表(cas_user_role)、权限角色关联表（cas_role_permission），如果是普通权限系统我们基本使用没有问题了，但是ZXX-CAS系统是解决多个系统应用接入的统一系统，所以我们需要在上述RBAC五表模式上增加一个应用维度，这个维度增加之后就简称为A-RBAC（Application-Role-Based Access Control，基于应用角色的访问控制），并需要新增应用表（cas_app）以及用户应用关联表（cas_user_app）。

02

—

IDEA集成plantUML

plantUML支持写代码的方式去绘制各种UML图，比如说类图、活动图、时序图、组件图、状态图等等，因为是写代码的方式去维护，所以可以很好的再次编辑和存储，可以直接在项目中创建一个uml包，存储系统相关的UML图。

IDEA集成方法：以Mac版本为例，打开如下图所示的界面，搜索PlantUML即可安装，安装之后重启idea即可。

重启之后打开idea，打开file会出现UML相关的功能，我们创建一个类图，但是发现右侧无法正常显示实际生成的类图效果，这个时候我们还需要安装一个 插件：graphviz

这里我们主要演示mac版本下的安装：

#终端执行该命令即可brew install graphviz

成功安装之后我们就可以使用PlantUML愉快的画类图以及时序图啦。

#也可以直接访问官方网址，在线画http://www.plantuml.com/

03

—

基于应用角色的访问控制设计

我们先简单来画一个基于应用角色访问控制的权限类图：

类图源码：

@startuml
User "0..*" --- "1..*" App(User,App) .. UserApp
User "0..*" - "1..*" Role(User, Role) .. UserRole
Role "0..*" - "1..*" Permission(Role, Permission) .. RolePermission@enduml

通过上述代码的编写就可以自动生成如上图所示的类图。本项目采用最简单基础的RBAC模型进行设计与开发，减少逻辑复杂度，后期如果大家有个性化的需求，比如增加组织机构、角色继承、数据权限等逻辑可以自行根据需求增加。

因为需要配置应用维度，所以在设计角色表与权限表时，需要增加一个app_id字段作为区分不同应用下的角色与权限。根据类图分析实际需要的字段，进行表结构的设计，表结构设计完成则使用第三章的自动生成工具生成并完善对应的代码逻辑，即可完成整个基础的CRUD功能。

表结构设计的时候需要注意什么问题呢？

命名规范：

1、库名、表名、字段名必须采用全小写命名法，并且多个单词之间采用下划线（_）进行分割，不建议使用mysql官方保留字作为字段名。本系统相关的表默认以cas_为前缀，后面拼接对应的模块进行命名。比如：cas_user、cas_user_role等

2、所有的表字段与表都需要增加注释。有多个类型的值，需要详细说明每个值指代的含义。

3、索引命名为唯一索引为uniq_+字段，普通索引为idx_+字段。例如：idx_name等。

基础规范：

1、默认配置INNODB存储引擎，采用MySql5.6版本（不强制，至少为5.6版本）。

2、对于需要支持特殊字符串的字段设置字符集为utf8mb4，比如姓名、昵称、简介等字段。

3、对于创建时间与更新时间，本系统约定使用毫秒级时间戳，定义为bigint(13），方便前端解析以及传输查询。

4、所有非空的字段都需要添加默认值，如果是int则默认值为0，不得使用0作为某个字段的查询值。如果是vachar则默认为(EMPTY STRING)。

5、不得在数据库中存储图片的二进制文件等。

6、本系统约定采用雪花算法或者数据库自增字段作为表主键字段。

索引规范：

1、每个表都必须有主键，且本系统约定主键为雪花算法生成的ID或者自增主键，默认索引方法选择Btree类型。

2、单表不建议索引超过太多，只需要在经常使用查询的地方设置索引即可，比如用户表使用name、phone、email等字段作为索引。

3、避免隐式转换导致索引失效，比如查询用户手机号，手机号字段为vachar，语句为select * from cas_user where phone =13598989898;这个则不会触发索引。

4、mysql索引最左匹配规则，因为默认索引方法为Btree，所以写where条件时，必须以左边第一个条件为查询条件，比如建立多行索引（a,b），则正常sql为：select * from cas_user where a>0 and b<10;如果帮b放在前面则不会触发索引，具体原因感兴趣的小伙伴可以深入研究，后面我这边开始深入研究mysql时，会给大家详细的介绍。

通过前面四章节的介绍，基本已经涵盖从需求到基础CRUD的功能了，接下来就需要研究一下前台后台交互的校验功能的设计与开发。敬请期待哟~喵