# RBAC模型 （Role-Based Access Control）
RBAC 是一种较新且广为使用的访问控制机制。其不同于“强制访问控制”以及“自由选定访问控制”直接赋予使用者权限，而是将权限赋予角色。

基本概念
* 用户(user): 通常指人(广义的概念)，还包括机器人、计算机、集群等
* 角色(role): 一定数量的权限的集合，权限的载体，如: 公司的工作职位，网上论坛的版主
* 权限(permission): 对一个或多个客体的访问或操作，如: 对功能模块的操作，对上传文件的删改，甚至页面上菜单、某个按钮的可见性控制等
需求分析
* 支持角色、权限、资源的增删改查
* 支持单个用户与角色绑定
* 支持用户组与角色绑定
* 支持单个权限与角色绑定
* 支持权限组与角色绑定
* 不同职责的员工和不同类型的用户，对资源有不同的操作权限
* 具有良好的扩展性，满足各种规模的公司架构和用户量级
*

数据库 ER 图
* 用户相关表(绿色): user, user_group
* 角色表(紫色): role
* 权限相关表(棕色): permission, operation, resource, permission_group
* 中间表(灰色): user_role, user_group_user, user_group_role, permission_role, permission_group_role, permission_group_permission

权限验证
* 用户有权访问或操作资源: {{用户包含的所有角色} ∪ {用户所属组包含的所有角色}} ∩ {{权限对应的所有角色} U {权限所属组对应的所有角色}} ≠ {空集}

注意事项
* 角色、权限和资源的划分
* 角色权限映射关系
* 当用户数量非常多时，可以考虑引入用户组，简化用户授权的复杂性
* 当系统权限非常复杂时，可以考虑引入权限组，简化角色的权限分配

流程图

1. 人员属于某个角色，首先给他分配角色，例如：总监、经理、主管、助理等；

2. 人员赋予角色后，则给他分配权限，不同的角色，规定有不同的权限。比如：总监级别，能够增删改查，无所不能；而经理级别，只能增改查，如果需要删除，则需要总监审批；主管只有增加和查看，修改需要向经理申请，让经理审批。

3. 不同的权限，实际上是对应数据库中的某张表，也就是Django中的某个model。

实现过程
1. 人员登录后，先验证用户是否OK；

2. 验证用户OK后，则根据人员属于什么角色，进行权限获取，并写入session中；

3. 用户登录成功，进入index页面，则根据用户session中的权限，展示不同的页面，正所谓：千人千面；

4. 用户根据不同的页面，进行不同的操作。