RBAC简介
简介
其基本思想是，对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。这样做的好处是，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，这样将简化用户的权限管理，减少系统的开销。
为何使用RBAC权限控制
假设采用传统的权限设计思想给用户分配权限的设计如下：
权限表
| id | URL | 权限名称 |
|---|---|---|
| 1 | GET:/users/ | 显示用户列表 |
| 2 | POST:/users? | 添加用户 |
用户表
| id | 用户账号 | 用户信息 |
|---|---|---|
| 1 | user0 | 张三 |
| 2 | user1 | 李四 |
用户权限关系表
| id | username | permission |
|---|---|---|
| 1 | 张三 | 显示用户列表 |
| 2 | 张三 | 添加用户 |
| 3 | 李四 | 显示用户列表 |
通过上面的三张表我们可以看出每个用户具有什么权限，但是这样做还是太年轻了。在系统设计中，一个管理员具有多种权限，那么当权限的数量很多，每一个用户分配权限的时候都需要往表中插入很多的数据，当用户的数量非常多的时候，那么插入的数据将会是NaN.当然年轻人时间多是没有问题滴。
聪明的你肯定会开始寻找一些其他的解决办法
RBAC设计实例
设计思想：
- 一个用户可以有多个角色
- 一个角色可以有多个人
- 一个角色可以有多个权限
- 一个权限可以分配给多个角色
接下来我们以竞赛报名网站为参考进行设计：
- 学生报名竞赛
- 组织创建竞赛、更新竞赛、删除竞赛
- 管理员能管理组织和竞赛
角色表
| id | name | 备注 |
|---|---|---|
| 1 | 管理员 | |
| 2 | 组织 | |
| 2 | 学生 |
用户表
| id | name | 用户信息 |
|---|---|---|
| 1 | 张三 | 男 |
| 2 | 李四 | 女 |
| 3 | 王二 | 女 |
权限表
| id | url | 备注 |
|---|---|---|
| 1 | GET:/competitions/ | 显示所有竞赛列表 |
| 2 | POST:/competitions? | 添加竞赛 |
| 3 | DELETE:/competitions? | 删除竞赛 |
| 4 | PUT:/competitions? | 更新竞赛 |
角色权限关联表
| id | 角色名字 | 权限名字 |
|---|---|---|
| 1 | 学生 | 显示所有竞赛列表 |
| 2 | 组织 | 添加竞赛 |
| 3 | 组织 | 删除竞赛 |
| 4 | 组织 | 更新竞赛 |
| 5 | 组织 | 显示所有竞赛列表 |
| 6 | 管理员 | 删除竞赛 |
| 7 | 管理员 | 显示所有竞赛列表 |
用户角色表
| id | 用户名字 | 角色名字 |
|---|---|---|
| 1 | 张三 | 学生 |
| 2 | 李四 | 组织 |
| 3 | 王二 | 管理员 |
通过阅读以上表信息我们可以发现，当需要给某个用户赋予权限时，只需要给对应的用户赋予相应的角色。每次只需要插入一条数据，相比与用户权限的管理方式，数据量小。其次当我们需要给所有的学生添加一个添加竞赛的权限时，我们只需要往角色权限表中添加一行数据就能实现，而不需要给所有用户逐一添加。
以上是对RBAC的初步概念理解和基本使用接下来我们对一些基本的RBAC框架进行分析
Django权限机制概述
Django用user，group和permission完成了权限机制，这里的group作用和角色类似。这个权限机制将某个Model(映射数据库中的一张表，例如User就是数据库中的User表，字段和类属性一一对应)的permission权限赋给对应的group或者user。例如我们创建一个Competition的Model
class Competition(models.Model):
Competition_name = models.CharField(max_length=50)
Competition_createtime = models.CharField(max_length=50)
Competition_user = models.CharField(max_length=100)
...
当我们创建一个对应的模型时，其自带四个默认权限：添加、删除、修改和查看。
假设我们有一个名为foo应用程序和一个名为Competition的模型，可以使用：
user.has_perm('foo.add_Competition')
user.has_perm('foo.change_Competition')
user.has_perm('foo.delete_Competition')
user.has_perm('foo.view_Competition')
测试其基础权限。
这种机制和以上的RBAC基本使用只能解决一些简单的应用需求，而大部分应用场景下，需要更细分的权限机制。以竞赛报名系统为例子，对于组织而言，其具有创建竞赛和删除竞赛、更新竞赛的权限，但是Django的自带认证系统和基本的RBAC思想都是全局权限。组织本只具有修改，删除，更新自己发布的竞赛信息权限，但这种方式使得要么他可以修改所有的竞赛信息，要么连自己的都不能修改。
更加细化的权限机制
在我们的例子中需要引入另外一种更细的权限机制：对象权限。在我们的例子中，我们需要对Competition模型创建的具体对象进行权限划分，需要规定只有创建该竞赛的组织能对该实例对象进行增删改查，而其他的组织不行。
Django中包含了object permission，需要引入Django-guardian，Django-guardian实现了对象级别的权限控制。具体请参考该博主对该框架的详解
