（一）基本概念
1.定义
RBAC（Role-Based Access Control），也就是所谓的**“基于角色的访问控制权限”**。
2.优势
在RBAC中，用户不再直接与权限相连，而是通过“角色”这一属性来间接的被赋予权限，用户通过成为适当的角色来的到这些角色固有的权限，这样处理就解耦了用户与权限的关系。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。
3.示例
这一思想在生活中很常见，如果我们这样定义：士兵就是在战场上冲锋作战的人，班长就是在战场上冲锋作战，还要管理班级，传达命令的人，连长就是负责对接营长，制定计划，下达命令的人。
那么如果王五是士兵，赵六也是士兵，那么他们两个就都可以在战场上冲锋作战，而李四则是班长，他除去冲锋作战，还要传达命令、管理班级。而张三是连长，他作为高级官员是负责对接营长，制定计划，下达命令。
那么此时我们就已经定义了用户，角色，权限这三个属性。
假如我们说没有采取这种思想，那我们会这么说：王五是在战场上冲锋作战的，赵六也是战场上冲锋作战的，李四是战场上冲锋作战，还要传达命令、管理班级的，张三是负责制定计划，下达命令和管理连队的。
在人很少的情况下这样还勉强可以，但如果有一千个士兵一百个班长一万个连长呢？这样对应计算机来讲，就有着十分大的耦合性。如果做成关系型数据库，就会有很大的数据冗余。
但是如果我们给每一个特定权限都赋予一个角色用以承载，这个问题就解决了。
只要给在战场上冲锋作战的人一个“士兵”角色，那么我们就只要说张三李四都是士兵就可以了。因为这时“士兵”这一角色就承载着对应的权限：作战冲锋。
为了便于理解，我们看一张图：
（二）RBAC模型
1.基本的RBAC模型
现在对RBAC模型的分类大概有五种：
- 基本模型RBAC0
- 角色分层模型RBAC1
- 角色限制模型RBAC2
- 统一模型RBAC3
- 基于RBAC的延展——用户组
这一篇主要讲RABC0模型，剩余的如果以后有时间也会写出来。
2.RBAC0模型
我们在前面讲了士兵班长的例子，你可能会想：
难道班长就不能制定作战计划、下达命令了？连长就不能传达命令、管理班级了？难道班长就不是一个士兵吗？
如果你有了这样的观念，那就说明你对RBAC0模型已经开始逐渐地掌握了。
是的，作为一个班长，他也有着制定作战计划，下达命令的权限（在这里为了便于理解我们不讨论下达的是连队的命令还是班级的命令，只抽象出“制定计划，下达命令”权限），连长也可以冲锋陷阵，这就引出了我们RBAC0模型的又一大特征——多对多。
更改过后的图如下：
我们可以看到，战士这个角色可以对应多个人，班长这个角色有有多个权限，而作战冲锋又可以被多个角色实现。用户拥有的权限等于他所有的角色持有权限之和。
那么我们以李四这个人为例，可以看到：
李四是一名班长又是一名战士，他有制定计划，下达命令，传达命令，管理班级，作战冲锋的权限！
所以概述型的RBAC0模型就可以总结如下：
（三）关系型数据库的实现
1.设计数据库
下面开始设计数据库：我们需要一张用户表(person)，一张角色表(role)，一张权限表(permission)，还需要两张中间表分别是用户-角色表(person_role)，角色-权限表(role_permission)。
可能有人会问：我们为什么还要中间表？很简单：实现表的多对多关系。
1.数据库实现
我们在这里赋予每个角色一个权限等级，设置等级高的角色可以拥有等级低的一切权限，而等级低的角色则不允许拥有等级高角色的权限
（1）person
（2）role
（3）person_role
（4）permission
（5）role_permission
2.SQL测试
测试语句如下：
SELECT person.id,person.姓名,person.性别,person.籍贯,role.角色名,role.权限等级,permission.权限名
FROM person
INNER JOIN person_role ON person.id = person_role.person_id
INNER JOIN role ON person_role.role_id = role.id
INNER JOIN role_permission ON role.id = role_permission.role_id
INNER JOIN permission ON role_permission.permission_id = permission.id
WHERE person.id = 1
测试效果如图：
