【项目】RBAC模型与权限设计

RBAC模型与权限设计

一.RBAC模型

1. 什么是RBAC

RBAC（全称：Role-Based Access Control）基于角色的权限访问控制，作为传统访问控制（自主访问，强制访问）的有前景的代替受到广泛的关注。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。
访问控制是针对越权使用资源的防御措施，目的是为了限制访问主体（如用户等） 对访问客体（如数据库资源等）的访问权限。企业环境中的访问控制策略大部分都采用基于角色的访问控制（RBAC）模型，是目前公认的解决大型企业的统一资源访问控制的有效方法

2. 基于RBAC的设计思路

基于角色的访问控制基本原理是在用户和访问权限之间加入角色这一层，实现用户和权限的分离，用户只有通过激活角色才能获得访问权限。通过角色对权限分组，大大简化了用户权限分配表，间接地实现了对用户的分组，提高了权限的分配效率。且加入角色层后，访问控制机制更接近真实世界中的职业分配，便于权限管理。

在RBAC模型中，角色是系统根据管理中相对稳定的职权和责任来划分，每种角色可以完成一定的职能。
用户通过饰演不同的角色获得角色所拥有的权限，一旦某个用户成为某角色的成员，则此用户可以完成该角色所具有的职能。
通过将权限指定给角色而不是用户，在权限分派上提供了极大的灵活性和极细的权限指定粒度。

3. 表结构分析
   

一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。
在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。

二. 有些项目中的权限设计

1. 需求分析

在应用系统中，权限是以什么样的形式展现出来的？对菜单的访问，页面上按钮的可见性，后端接口的控制，都要进行充分考虑
* 前端
前端菜单：根据是否有请求菜单权限进行动态加载
按钮：根据是否具有此权限点进行显示/隐藏的控制
* 后端
前端发送请求到后端接口，有必要对接口的访问进行权限的验证

2. 权限设计

针对这样的需求，在有些设计中可以将菜单，按钮，后端API请求等作为资源，这样就构成了基于RBAC的另一种授权模型（用户-角色-权限-资源）。

针对此种权限模型，其中权限究竟是属于菜单，按钮，还是API的权限呢？那就需要在设计数据库权限表的时候添加类型加以区分（如权限类型 1为菜单 2为功能 3为API）。

3. 表结构分析
   

这里要注意的是，权限表与权限菜单表、页面元素表与API接口表都是一对一的关系
与传统的RBAC模型对比不难发现此种设计的好处：
* 不需要区分哪些是操作，哪些是资源
* 方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的资源表，并确定这类权限的权限类型标识即可。