RBAC权限控制模型
简介
1、为什么要进行权限控制
如果没有权限控制,系统的功能完全不设防,全部暴露在所有用户面前。用户登录后可以使用系统中的所有功能。这在实际运行中是不能接收的。
所以权限控制系统的目标就是管理用户的行为,保护系统的功能
2、什么是权限控制
权限控制就是对权限进行限制
权限=权力+限制
3、如何进行权限控制
定义资源
资源就是系统中需要保护起来的功能。具体形式很多:URL地址、handler方法、service方法、页面元素等等,都可以定义为资源使用权限控制系统保护起来
创建权限
一个功能负载的项目会包含很多具体资源,成千上万都有可能。这么多资源逐个进行操作太麻烦了。为了简化操作,都可以将相关的几个资源封装到一起,打包成一个“权限”同时分配给有需要的人
创建角色
对于一个庞大系统来说,一方面需要保护的资源非常多,另一方面操作系统的 人也非常多。把资源打包为权限是对操作的简化,同样把用户划分为不同角色也是 对操作的简化。否则直接针对一个个用户进行管理就会很繁琐。
所以角色就是用户的分组、分类。先给角色分配权限,然后再把角色分配给用 户,用户以这个角色的身份操作系统就享有角色对应的权限了。
管理用户
系统中的用户其实是人操作系统时用来登录系统的账号、密码。
建立关联关系
权限→资源:单向多对多
Java 类之间单向:从权限实体类可以获取到资源对象的集合,但是通过资 源获取不到权限
数据库表之间多对多: 一个权限可以包含多个资源 一个资源可以被分配给多个不同权限
** 角色→权限**:单向多对多
Java 类之间单向:从角色实体类可以获取到权限对象的集合,但是通过权 限获取不到角色
数据库表之间多对多: 一个角色可以包含多个权限 一个权限可以被分配给多个不同角色
用户→角色:双向多对多
Java 类之间双向:可以通过用户获取它具备的角色,也可以看一个角色下 包含哪些用户
数据库表之间: 一个角色可以包含多个用户 一个用户可以身兼数职
多对多关联关系在数据库中的表示
没有中间表的情况
如果只能在一个外键列上存储关联关系数据,那么现在这个情况无法使用 SQL 语句 进行关联查询
有中间表
当有中间表的时候我们可以使用slq 语句将两个表关联起来
select t_studet.id,t_student.name from t_student left join t_inner on t_studen.id=t_inner.stuent_id left join t_subject on t_inner.subject_id=t_subject.id where t_subjct.id=1
中间表主键的生成方式
方式1:另设置字段作为主键
我们上面的例子就是另设置字段作为主键
方式2:使用联合主键
只要保证联合主键一对值不和其他值重负即可
RBAC权限模型
概念
鉴于权限控制的核心是用户通过角色与权限进行关联,所以前面描述的权限控制系 统可以提炼为一个模型:RBAC(Role-Based Access Control,基于角色的访问控制)。
在 RBAC 模型中,一个用户可以对应多个角色,一个角色拥有多个权限,权限具体 定义用户可以做哪些事情。
RBAC0~RBAC3
RBAC0
最基本的 RBAC 模型,RBAC 模型的核心部分,后面三种升级版 RBAC 模型也都 是建立在 RBAC0 的基础上。
RBAC1
在 RBAC0 的基础上增加了角色之间的继承关系。角色 A 继承角色 B 之后将具 备 B 的权限再增加自己独有的其他权限。
比如:付费会员角色继承普通会员角色, 那么付费会员除了普通会员的权限外还具备浏览付费内容的权限。
RBAC2
在 RBAC0 的基础上进一步增加了角色责任分离关系。责任分离关系包含静态 责任分离和动态责任分离两部分。
静态责任分离:给用户分配角色时生效
- 互斥角色:权限上相互制约的两个或多个角色就是互斥角色。用户只 能被分配到一组互斥角色中的一个角色。
例如:一个用户不能既有会计师角色又有审计师角色。 - 基数约束:
一个角色对应的访问权限数量应该是受限的
一个角色中用户的数量应该是受限的
一个用户拥有的角色数量应该是受限的 - 先决条件角色:用户想拥有 A 角色就必须先拥有 B 角色,从而保证 用户拥有 X 权限的前提是拥有 Y 权限。
例如:“金牌会员”角色只能授予拥有“银牌会员”角色的用户,不 能直接授予普通用户。
动态责任分离:用户登录系统时生效
- 一个用户身兼数职,在特定场景下激活特定角色
例如:
马云在阿里巴巴内部激活创始人角色
马云在某企业级论坛上激活演讲嘉宾角色
RBAC3
RBAC3 是在 RBAC0 的基础上同时添加 RBAC2 和 RBAC3 的约束,最全面、最复 杂。