RBAC、控制权限设计、权限表设计 基于角色权限控制和基于资源权限控制的区别优劣

简介: RBAC、控制权限设计、权限表设计 基于角色权限控制和基于资源权限控制的区别优劣

微信截图_20220524175421.png

简单介绍一下权限表设计,也是自己去了解的一个东西。


大家一起加油哦😀😀


一、介绍


现阶段我们知道的大概就是两种权限设计


  1. 一种是基于角色的权限设计


  1. 另一种是基于资源的权限设计


接下来我给大家讲一讲这两种权限的区别,以及那种更好。


在后面也会给出数据库里表的设计的具体代码。


二、基于角色的权限设计


RBAC基于角色的访问控制(Role-Based Access Control)是按角色进行授权。例如:

比如:主体的角色为总经理可以查 询企业运营报表,查询员工工资信息等,访问控制流程如下:


微信截图_20220524175554.png


根据上图中的判断逻辑,授权代码可表示如下:


if(主体.hasRole("总经理角色id")){
  查询工资
}


如果上图中查询工资所需要的角色变化为总经理和部门经理,此时就需要修改判断逻辑为“判断用户的角色是否是 总经理或部门经理”,修改代码如下:


if(主体.hasRole("总经理角色id") || 主体.hasRole("部门经理角色id")){
  查询工资
}


根据上边的例子发现,当需要修改角色的权限时就需要修改授权的相关代码,系统可扩展性差。


我们敲代码都知道的 公司中最忌修改源码 因为牵一发而动全身。


所以不是非常必要 就不要随便修改原来的代码。


接下来 我们看一下基于资源的权限控制的设计是什么样子吧。


三、基于资源的权限设计


RBAC基于资源的访问控制(Resource-Based Access Control)是按资源(或权限)进行授权,比如:用户必须 具有查询工资权限才可以查询员工工资信息等,访问控制流程如下:


微信截图_20220524175726.png


根据上图中的判断,授权代码可以表示为:


if(主体.hasPermission("查询工资权限标识")){ 
  查询工资
}


优点:系统设计时定义好查询工资的权限标识,即使查询工资所需要的角色变化为总经理和部门经理也不需要修改 授权代码,系统可扩展性强。


四、主体、资源、权限关系图


微信截图_20220524175847.png


主体、资源、权限相关的数据模型



主体(用户id、账号、密码、...)


主体(用户)和角色关系(用户id、角色id、...)


角色(角色id、角色名称、...)


角色和权限关系(角色id、权限id、...)


权限(权限id、权限标识、权限名称、资源名称、资源访问地址、...)


数据模型关系图:


微信截图_20220524180001.png


具体表模型SQL:


user表:


DROP TABLE IF EXISTS `user_db`;
CREATE TABLE `user_db`  (
  `id` bigint(20) NOT NULL,
  `username` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `password` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `fullname` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `mobile` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = latin1 COLLATE = latin1_swedish_ci ROW_FORMAT = Dynamic;
INSERT INTO `user_db` VALUES (1, 'admin', '123456', '张三', '123');


t_role表:


DROP TABLE IF EXISTS `t_role`;
CREATE TABLE `t_role`  (
  `id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `role_name` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `description` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `create_time` datetime(0) NULL DEFAULT NULL,
  `update_time` datetime(0) NULL DEFAULT NULL,
  `status` char(1) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE INDEX `unique_role_name`(`role_name`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;
-- ----------------------------
-- Records of t_role
-- ----------------------------
INSERT INTO `t_role` VALUES ('1', '管理员', NULL, NULL, NULL, '');


t_user_role表:


DROP TABLE IF EXISTS `t_user_role`;
CREATE TABLE `t_user_role`  (
  `user_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `role_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `create_time` datetime(0) NULL DEFAULT NULL,
  `creator` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  PRIMARY KEY (`user_id`, `role_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;
-- ----------------------------
-- Records of t_user_role
-- ----------------------------
INSERT INTO `t_user_role` VALUES ('1', '1', NULL, NULL);


t_permission表:


DROP TABLE IF EXISTS `t_permission`;
CREATE TABLE `t_permission`  (
  `id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `code` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '权限标识符',
  `description` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '描述',
  `url` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '请求地址',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;
-- ----------------------------
-- Records of t_permission
-- ----------------------------
INSERT INTO `t_permission` VALUES ('1', 'p1', '测试资源\r\n1', '/r/r1');
INSERT INTO `t_permission` VALUES ('2', 'p2', '测试资源2', '/r/r2');


t_role_permission表:


DROP TABLE IF EXISTS `t_role_permission`;
CREATE TABLE `t_role_permission`  (
  `role_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `permission_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  PRIMARY KEY (`role_id`, `permission_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;
-- ----------------------------
-- Records of t_role_permission
-- ----------------------------
INSERT INTO `t_role_permission` VALUES ('1', '1');
INSERT INTO `t_role_permission` VALUES ('2', '2');


自言自语


今天又完成一篇 ✌

看完这一篇 大家应该也会对权限的设计有了一些浅浅的理解吧。

一起加油哦。


相关实践学习
云安全基础课 - 访问控制概述
课程大纲 课程目标和内容介绍视频时长 访问控制概述视频时长 身份标识和认证技术视频时长 授权机制视频时长 访问控制的常见攻击视频时长
目录
相关文章
|
1月前
|
安全 Java 数据库
设计一个简单的权限系统
在Java中构建简单权限系统涉及定义Role和Permission实体,创建User实体关联角色,设计权限分配机制,实现权限检查方法及界面交互。示例代码包括实体类、权限分配服务、安全服务和主函数。实际应用可能需要更复杂的权限控制、动态管理、数据库集成和用户界面。Spring Security等框架可提供全面的安全管理解决方案。【5月更文挑战第3天】
|
1月前
|
数据安全/隐私保护
基于RBAC0模型的简单权限系统设计角色
基于RBAC0模型的简单权限系统设计角色
|
1月前
|
Kubernetes API 数据安全/隐私保护
k8s学习-基于角色的权限控制RBAC(概念,模版,创建,删除等)
k8s学习-基于角色的权限控制RBAC(概念,模版,创建,删除等)
71 0
|
安全 JavaScript Java
复杂场景下的权限系统该怎么玩?ABAC权限模型帮你搞定它
复杂场景下的权限系统该怎么玩?ABAC权限模型帮你搞定它
|
消息中间件 JSON 安全
如何设计权限系统?
如何设计权限系统?
|
数据安全/隐私保护
15-企业权限管理-方法级别权限控制
15-企业权限管理-方法级别权限控制
15-企业权限管理-方法级别权限控制
|
数据安全/隐私保护
13-企业权限管理-用户关联角色操作
13-企业权限管理-用户关联角色操作
13-企业权限管理-用户关联角色操作
|
数据安全/隐私保护
14-企业权限管理-角色关联权限操作
14-企业权限管理-角色关联权限操作
|
Java 数据安全/隐私保护 Spring
【自己设计权限控制】【网站的权限控制】【限制用户访问级别高的接口】
【自己设计权限控制】【网站的权限控制】【限制用户访问级别高的接口】
|
SQL 存储 数据库
数据权限这样设计,你觉得如何?
在项目实际开发中我们不光要控制一个用户能访问哪些资源,还需要控制用户只能访问资源中的某部分数据。 控制一个用户能访问哪些资源我们有很成熟的权限管理模型即RBAC,但是控制用户只能访问某部分资源(即我们常说的数据权限)使用RBAC模型是不够的,本文我们尝试在RBAC模型的基础上融入数据权限的管理控制。
2897 1