RBAC模型

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联。简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。这样,就构造成“用户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系。(如下图)



角色是什么?可以理解为一定数量的权限的集合,权限的载体。例如:一个论坛系统,“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等,这些是权限。要给某个用户授予这些权限,不需要直接将权限授予用户,可将“版主”这个角色赋予该用户。 

 

当用户的数量非常大时,要给系统每个用户逐一授权(授角色),是件非常烦琐的事情。这时,就需要给用户分组,每个用户组内有多个用户。除了可给用户授权外,还可以给用户组授权。这样一来,用户拥有的所有权限,就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。(下图为用户组、用户与角色三者的关联关系)

在应用系统中,权限表现成什么?对功能模块的操作,对上传文件的删改,菜单的访问,甚至页面上某个按钮、某个图片的可见性控制,都可属于权限的范畴。有些权限设计,会把功能操作作为一类,而把文件、菜单、页面元素等作为另一类,这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时,可把功能操作和资源统一管理,也就是都直接与权限表进行关联,这样可能更具便捷性和易扩展性。(见下图)



请留意权限表中有一列“权限类型”,我们根据它的取值来区分是哪一类权限,如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。

 

这样设计的好处有二。其一,不需要区分哪些是权限操作,哪些是资源,(实际上,有时候也不好区分,如菜单,把它理解为资源呢还是功能模块权限呢?)。其二,方便扩展,当系统要对新的东西进行权限控制时,我只需要建立一个新的关联表“权限XX关联表”,并确定这类权限的权限类型字符串。

 

这里要注意的是,权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。(文件、页面权限点、功能操作等同理)。也就是每添加一个菜单,就得同时往这三个表中各插入一条记录。这样,可以不需要权限菜单关联表,让权限表与菜单表直接关联,此时,须在权限表中新增一列用来保存菜单的ID,权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。

 

到这里,RBAC权限模型的扩展模型的完整设计图如下:



随着系统的日益庞大,为了方便管理,可引入角色组对角色进行分类管理,跟用户组不同,角色组不参与授权。例如:某电网系统的权限管理模块中,角色就是挂在区局下,而区局在这里可当作角色组,它不参于权限分配。另外,为方便上面各主表自身的管理与查找,可采用树型结构,如菜单树、功能树等,当然这些可不需要参于权限分配。

### RBAC模型概述 RBAC(Role-Based Access Control,基于角色的访问控制)是一种用于管理信息系统中用户权限的安全机制。它通过定义角色及其对应的权限来简化复杂的权限分配过程[^1]。 在RBAC模型中,“谁”可以对“什么”执行“如何”的操作是一个核心概念。“谁”指的是权限的拥有者或主体(通常是用户或角色),而“什么”则是指资源或对象(如文件、数据库表等)。具体来说: - **Who**: 权限的拥有者或主体,通常是指用户或者角色。 - **What**: 资源或对象,即受保护的目标实体。 - **How**: 主体能够对目标执行的操作类型,比如读取、写入、删除等。 #### RBAC的主要变种 RBAC模型有多个版本,分别针对不同的需求进行了扩展: 1. **RBAC0 (Core RBAC)**: 这是最简单的RBAC形式,仅提供基本的角色到用户的映射以及角色到权限的映射[^2]。 2. **RBAC1 (Hierarchical RBAC)**: 在RBAC0的基础上加入了角色之间的层次结构支持继承关系,允许子角色自动获得父角色的所有权限。 3. **RBAC2 (Constrained RBAC)**: 提供额外的功能以满足更严格的业务规则要求,例如互斥角色和基数约束。 4. **RBAC3 (Combined RBAC)**: 将RBAC1和RBAC2结合起来形成统一框架,既包含角色间的继承也包括各种约束条件。 ### 实现方式 要实现一个完整的RBAC系统,一般遵循以下几个方面考虑的设计原则和技术要点: 1. **数据建模** 需要创建几个关键的数据表用来存储相关信息: - 用户(User): 表示系统的实际使用者. - 角色(Role): 定义了一组特定职责的行为集合. - 权限(Permission/Privilege): 描述某个动作作用于某类资源的能力. 下面展示了一个简单的关系型数据库模式的例子: ```sql CREATE TABLE Users ( UserID INT PRIMARY KEY, UserName VARCHAR(50) NOT NULL UNIQUE ); CREATE TABLE Roles ( RoleID INT PRIMARY KEY, RoleName VARCHAR(50) NOT NULL UNIQUE ); CREATE TABLE Permissions ( PermissionID INT PRIMARY KEY, ResourceName VARCHAR(50), Action VARCHAR(50) ); CREATE TABLE UserRoles ( UserID INT REFERENCES Users(UserID), RoleID INT REFERENCES Roles(RoleID), PRIMARY KEY (UserID, RoleID) ); CREATE TABLE RolePermissions ( RoleID INT REFERENCES Roles(RoleID), PermissionID INT REFERENCES Permissions(PermissionID), PRIMARY KEY (RoleID, PermissionID) ); ``` 2. **逻辑处理流程** 当请求到达服务器端时,应按照如下顺序验证并授权该行为是否合法: - 获取当前登录用户的标识符; - 查询此用户关联的所有有效角色列表; - 对照这些角色所拥有的全部许可项逐一匹配待审核的动作与资源组合; 如果找到完全一致条目,则判定此次调用成功;反之失败返回错误提示信息给前端界面显示出来告知用户原因所在。 3. **动态调整能力** 应当具备灵活修改配置参数而不影响整体架构稳定性的特性。例如新增加一种新的功能模块时候只需要补充相应的记录进入permissions表格当中即可完成整个部署工作无需改动其他地方任何代码片段内容。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值