权限类型和权限分配分析

一、核心要素
权限系统核心要素为:账号、用户、角色、用户组、权限等,各要素实体关系如下:
在这里插入图片描述

各要素主要属性及与属性中的实体对应关系:

在这里插入图片描述

二、权限类型及权限分配方式
与权限相关的实体对象之间的关系如下图:
在这里插入图片描述

权限类型总共归结为页面权限、操作权限、数据权限三类,区分一个权限是页面权限还是操作权限的标准为判断该权限下是否还需要再分配操作权限和数据权限,如果需要则为页面权限,否则为操作权限。

系统权限分配可按角色授权或按用户授权(一般不采用此方式授权,用户数量较少时或不能明确用户角色时可采用此方式授权)。

  1. 页面权限授权
    页面权限授权包含可查看页面授权以及页面可见字段授权,大多数情况下不需要页面可见字段授权的配置,系统默认所有字段可见,或者通过反向选择不可见字段的方式进行配置。

  2. 操作权限授权
    分配页面的操作权限,如增、删、查、改、导入、导出等操作权限。

  3. 数据权限授权
    数据权限分配可查看的数据权限和可操作的数据权限,大多数情况下只需要配置可查看的数据权限,可操作的数据权限需要对一些操作按钮分配可操作的数据范围,权限分配方式相同。
    数据权限分配方式可归结为以下几种:
    (1) 本人
    数据权限选择【本人】,用户只能查看本人所创建的数据。
    (2) 本部门
    部门成员创建的数据:数据权限选择【本部门-部门成员创建的数据】,用户可查看本人所属部门下的所有成员创建的数据;
    有业务归属的数据:数据权限选择【本部门—有业务归属的数据】,用户可查看本人所属部门所拥有的业务数据范围,(如高校课程信息分别归属不同的学院,则每个学院下的成员则只能查看归属自己学院的课程相关的业务数据,如课程排考数据)。
    (3)本组织(如xxx项目组)
    部门成员创建的数据:数据权限选择【本组织-部门成员创建的数据】,用户可查看本人所属组织下的所有成员创建的数据(如“xxx项目组“的成员只能查看自己所属的项目组的成员所创建的数据);
    有业务归属的数据:数据权限选择【本部门—有业务归属的数据】,用户可查看本人所属组织所拥有的业务数据范围。
    (4) 全部
    数据权限选择【全部】,用户可查看所有数据。
    (5) 自定义
    选择人员:数据权限选择【自定义-选择人员】,选择多个人员姓名,用户可查看所选择的成员创建的数据;
    选择部门:
    1)部门成员创建的数据:数据权限选择【自定义-选择部门—部门成员创建的数据】,选择多个部门名称,用户可查看所选择的部门下所有成员创建的数据;
    2)有业务归属的数据:数据权限选择【自定义—选择部门—有业务归属的数据】,用户可查看所选择的部门拥有的业务数据;
    选择组织:
    1)组织成员创建的数据:数据权限选择【自定义-选择组织-部门成员创建的数据】,选择多个组织名称,用户可查看所选择的组织下的所有成员创建的数据;
    2)有业务归属的数据:数据权限选择【自定义—选择组织—有业务归属的数据】,选择多个组织名称,用户可查看所选择的组织拥有的业务数据;
    选择业务数据:数据权限选择【自定义-选择业务数据】,选择多个业务数据,用户可查看所选择的业务数据(如用户只可查看三门课程的数据排考数据,则配置权限时选择可查看的三门课程的名称即可)。

  4. 系统内置权限
    权限可以在权限管理中心配置,一些根据业务需求能够提前确定页面权限、操作权限、数据权限的角色或用户可提前在系统内置权限,无需权限的配置功能,从而减少开发工作量:
    (1) 某角色的所有权限都固定不变
    如课程教学平台的学生角色,在平台的权限是固定的,则系统可为学生角色内置页面权限、操作权限、数据权限,无需在权限配置页对该角色进行权限配置。
    (2)某角色的某类数据权限固定
    如“对于高校所有学院下的院长都可以查看本学院所开设的课程“ 该数据权限可通过系统内置。
    为系统内置角色【院长】按照“本部门—有业务归属的数据“的权限规则内置好数据权限,业务字段即为“课程”,业务数据与部门的关系为课程与学院的关系,此关系在课程信息表中已做维护。
    (3)所有用户的某类数据权限固定
    如“对于所有成员只能查看自己所属项目组的数据”,该数据权限可通过系统内置。为系统所有用户按照“本组织—组织成员创建的数据“的权限规则内置好数据权限。

  • 2
    点赞
  • 18
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
RBAC(Role-Based Access Control)是一种权限管理模型,它是建立在角色的基础上,将用户分配给角色,再根据角色的权限授予对应的资源访问权限。这种模型可以有效地管理大规模应用系统中的权限问题。下面是基于RBAC的权限管理系统的设计分析: 1.确定系统需求:首先要确定系统的具体需求和功能,包括用户界面、权限设置和管理、角色管理、资源管理等方面。同时需要明确系统的主要目标是什么,以便在设计时保持一致性。 2.确定角色:根据系统需求,确定所需要的角色类型和数量,包括系统管理员、普通用户等。在设计时应该合理分配权限,避免角色间权限重叠或漏洞。 3.确定资源:确定系统中的资源,包括数据、程序、文档等,依据资源的重要性和保密性进行分类,在角色分配时考虑资源所属角色的权限。 4.权限授予:根据角色的不同,授予对应的资源访问权限,包括读取、修改、删除等。在授予权限时要严格按照角色的权限定义进行操作,避免数据泄漏和滥用。 5.权限审核:对所有权限的修改和删除操作进行记录和审查,定期对权限进行审核,保证系统的安全性和稳定性。 6.权限维护:系统上线后,需要对权限进行维护和更新,包括新增角色、修改权限、删除角色等操作,同时定期对系统进行安全检查和修复漏洞。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

翠玲的菜园子

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值