分类目录归档：RBAC权限管理

RBAC权限管理

RBAC打造通用WEB权限

留下评论

 

RBAC不用给用户单个分配权限，只用指向对应的角色就会有对应的权限，而且分配权限和收回权限都很方便

5个关系对应5张表

五张表设计

复制代码
 1 CREATE TABLE `user` (
 2   `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
 3   `name` varchar(20) NOT NULL DEFAULT '' COMMENT '姓名',
 4   `email` varchar(30) NOT NULL DEFAULT '' COMMENT '邮箱',
 5   `is_admin` tinyint(1) NOT NULL DEFAULT '0' COMMENT '是否是超级管理员 1表示是 0 表示不是',
 6   `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态 1：有效 0：无效',
 7   `updated_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '最后一次更新时间',
 8   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
 9   PRIMARY KEY (`id`),
10   KEY `idx_email` (`email`)
11 ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT='用户表';
12 
13 CREATE TABLE `role` (
14   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
15   `name` varchar(50) NOT NULL DEFAULT '' COMMENT '角色名称',
16   `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态 1：有效 0：无效',
17   `updated_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '最后一次更新时间',
18   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
19   PRIMARY KEY (`id`)
20 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='角色表';
21 
22 CREATE TABLE `user_role` (
23   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
24   `uid` int(11) NOT NULL DEFAULT '0' COMMENT '用户id',
25   `role_id` int(11) NOT NULL DEFAULT '0' COMMENT '角色ID',
26   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
27   PRIMARY KEY (`id`),
28   KEY `idx_uid` (`uid`)
29 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户角色表';
30 
31 CREATE TABLE `access` (
32   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
33   `title` varchar(50) NOT NULL DEFAULT '' COMMENT '权限名称',
34   `urls` varchar(1000) NOT NULL DEFAULT '' COMMENT 'json 数组',
35   `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态 1：有效 0：无效',
36   `updated_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '最后一次更新时间',
37   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
38   PRIMARY KEY (`id`)
39 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='权限详情表';
40 
41 CREATE TABLE `role_access` (
42   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
43   `role_id` int(11) NOT NULL DEFAULT '0' COMMENT '角色id',
44   `access_id` int(11) NOT NULL DEFAULT '0' COMMENT '权限id',
45   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
46   PRIMARY KEY (`id`),
47   KEY `idx_role_id` (`role_id`)
48 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='角色权限表';
49 
50 CREATE TABLE `app_access_log` (
51   `id` int(11) NOT NULL AUTO_INCREMENT,
52   `uid` bigint(20) NOT NULL DEFAULT '0' COMMENT '品牌UID',
53   `target_url` varchar(255) NOT NULL DEFAULT '' COMMENT '访问的url',
54   `query_params` longtext NOT NULL COMMENT 'get和post参数',
55   `ua` varchar(255) NOT NULL DEFAULT '' COMMENT '访问ua',
56   `ip` varchar(32) NOT NULL DEFAULT '' COMMENT '访问ip',
57   `note` varchar(1000) NOT NULL DEFAULT '' COMMENT 'json格式备注字段',
58   `created_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
59   PRIMARY KEY (`id`),
60   KEY `idx_uid` (`uid`)
61 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户操作记录表';
62 
63 
64 INSERT INTO `user` (`id`, `name`, `email`, `is_admin`, `status`, `updated_time`, `created_time`)
65 VALUES(1, '超级管理员', 'apanly@163.com', 1, 1, '2016-11-15 13:36:30', '2016-11-15 13:36:30');
复制代码

用户与角色关联起来，角色与权限关联起来，通过判断角色来管理权限（哪些页面不能访问）

 

判断权限逻辑：根据用户ID取出用户角色==》如果是超级管理员则不需要做权限判断，否则根据角色取出所属权限==》根据权限取出可访问链接列表==》判断当前操作是否在列表中==》无权限则返回提示页面；

 

本内容整理自慕课网视频教程——《RBAC打造通用web管理权限》

RBAC权限管理

RBAC权限管理模型：基本模型及角色模型解析及举例

留下评论

我们在做任何一款产品的时候，或多或少都会涉及到用户和权限的问题。譬如，做企业类软件，不同部门、不同职位的人的权限是不同的；做论坛类产品的时候，版主和访客权限也是不一样的；再例如一款产品的收费用户和免费用户权限也是迥然不同的。

但在设计产品的用户和权限的关系的时候，很多产品经理可能按照感觉来，在并不清楚用户和权限是否存在优秀的理论模型的时候，就按照自我推理搭建了产品的用户和权限模型。而这种基于感觉和推理的模型肯定是有诸多问题的，譬如写死了关系导致权限不够灵活、考虑不周导致权限覆盖能力弱等等。

正如牛顿所言，站在巨人的肩膀上才能看的更远。我们不妨去参照已有的比较成熟的权限模型，如：RBAC（Role-Based Access Control）——基于角色的访问控制。我搜集了网上很多关于RBAC的资料，大多与如何用数据表实现RBCA相关，并不容易理解。所以，我会以产品经理的角度去解析RBAC模型，并分别举例如何运用这套已得到验证的成熟模型。

一、RBAC模型是什么?

RBAC是一套成熟的权限模型。在传统权限模型中，我们直接把权限赋予用户。而在RBAC中，增加了“角色”的概念，我们首先把权限赋予角色，再把角色赋予用户。这样，由于增加了角色，授权会更加灵活方便。在RBAC中，根据权限的复杂程度，又可分为RBAC0、RBAC1、RBAC2、RBAC3。其中，RBAC0是基础，RBAC1、RBAC2、RBAC3都是以RBAC0为基础的升级。我们可以根据自家产品权限的复杂程度，选取适合的权限模型。

1

二、基本模型RBAC0

解析：

RBAC0是基础，很多产品只需基于RBAC0就可以搭建权限模型了。在这个模型中，我们把权限赋予角色，再把角色赋予用户。用户和角色，角色和权限都是多对多的关系。用户拥有的权限等于他所有的角色持有权限之和。

2

举例：

譬如我们做一款企业管理产品，如果按传统权限模型，给每一个用户赋予权限则会非常麻烦，并且做不到批量修改用户权限。这时候，可以抽象出几个角色，譬如销售经理、财务经理、市场经理等，然后把权限分配给这些角色，再把角色赋予用户。这样无论是分配权限还是以后的修改权限，只需要修改用户和角色的关系，或角色和权限的关系即可，更加灵活方便。此外，如果一个用户有多个角色，譬如王先生既负责销售部也负责市场部，那么可以给王先生赋予两个角色，即销售经理+市场经理，这样他就拥有这两个角色的所有权限。

三、角色分层模型RBAC1

解析：

RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念。简单理解就是，给角色可以分成几个等级，每个等级权限不同，从而实现更细粒度的权限管理。

3

举例：

基于之前RBAC0的例子，我们又发现一个公司的销售经理可能是分几个等级的，譬如除了销售经理，还有销售副经理，而销售副经理只有销售经理的部分权限。这时候，我们就可以采用RBAC1的分级模型，把销售经理这个角色分成多个等级，给销售副经理赋予较低的等级即可。

四、角色限制模型RBAC2

解析：

RBAC2同样建立在RBAC0基础之上，仅是对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。具体限制如下图：

4

举例：

还是基于之前RBAC0的例子，我们又发现有些角色之间是需要互斥的，譬如给一个用户分配了销售经理的角色，就不能给他再赋予财务经理的角色了，否则他即可以录入合同又能自己审核合同；再譬如，有些公司对角色的升级十分看重，一个销售员要想升级到销售经理，必须先升级到销售主管，这时候就要采用先决条件限制了。

五、统一模型RBAC3

解析：

RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分层，也包括可以增加各种限制。

5

举例：

这个就不举例了，统一模型RBAC3可以解决上面三个例子的所有问题。当然，只有在系统对权限要求非常复杂时，才考虑使用此权限模型。

六、基于RBAC的延展——用户组

解析：

基于RBAC模型，还可以适当延展，使其更适合我们的产品。譬如增加用户组概念，直接给用户组分配角色，再把用户加入用户组。这样用户除了拥有自身的权限外，还拥有了所属用户组的所有权限。

6

举例：

譬如，我们可以把一个部门看成一个用户组，如销售部，财务部，再给这个部门直接赋予角色，使部门拥有部门权限，这样这个部门的所有用户都有了部门权限。用户组概念可以更方便的给群体用户授权，且不影响用户本来就拥有的角色权限。

七、最后的话

无论是本次的权限模型，还是其他产品相关实现方案，很多都已经被前人所总结提炼，我们应深度掌握这些成熟的知识和经验，而不是绞尽脑汁自我推理。还是文章开头那句话，站在巨人的肩膀上我们可以看得更远，而不是再造一个轮子。

RBAC权限管理

RBAC权限管理

留下评论

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

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

 

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

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


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

 

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

 

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

 

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


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