功能、资源权限管理的设计

导读:本篇文章讲解 功能、资源权限管理的设计,希望对大家有帮助,欢迎收藏,转发!站点地址:www.bmabk.com

一、目的

管理系统用户的功能菜单权限,物理资源(文件、数据)权限。

二、RBAC模型设计

RBAC简介

BAC模型(Role-Based Access Control:基于角色的访问控制)模型是一种权限实现模型,是系统权限设计中的一套方法论。

RBAC认为权限授权的过程可以抽象地概括为:Who是否可以对What进行How的访问操作,并对这个逻辑表达式进行判断是否为True的求解过程,也即是将权限问题转换为Who、What、How的问题,Who、What、How构成了访问权限三元组。

RBAC模型的核心对象为:用户、角色、权限

资源管理简介

系统资源可分为逻辑资源和物理资源。逻辑资源如软件系统的菜单、页面、按钮等等;物理资源如视频文件、音频文件、pdf文件等等。

其中逻辑资源可以通过权限来控制,物理资源可通过在角色下设置资源列表,通过角色关联资源列表实现,也可直接将用户和资源列表关联实现。

权限管理模型设计

所有的权限管理最终都要落到用户身上。

功能权限E-R设计

  • RBAC0模型为基础建立核心业务实体:单位(公司/部委/组织机构)、部门(科室)、用户、角色、权限
  • 使用关联实体为核心业务实体建立映射关系:用户角色、角色权限等
  • 为方便数据查询和业务拓展,增加单位权限、单位角色映射关系。此两项非必须。
  • 可按照RBAC1模型的设计思路,增加角色组,用户关联角色组、角色组关联角色,角色关联权限。从而实现更细粒度的权限管理。
  • 可按照RBAC1模型的思想,将部门和用户的映射关系修改为m:n,将能够实现一个用户归属多个组织的权限管理。如分公司的董事长同时兼任集团公司部门领导的情况。其中隐含了单位和部门关系为多对多,部门和用户关系为多对多。当用户登录的时候,让用户自己选择需要在哪个组织下工作。鉴于这种情况的项目相对而言为少数,大部分项目没有那么复杂的组织架构,可以对外提供两套解决方案。

功能、资源权限管理的设计

资源权限E-R设计

业务弱关联性设计

建立如下资源和业务实体的映射关系:

  • 资源本身作为一个业务实体,为资源划分类型
  • 资源和单位建立映射关系,用户隶属于单位
  • 资源和部门建立映射关系,用户隶属于部门
  • 资源和角色建立映射关系,用户关联角色
  • 资源和行政区划建立映射关系,用户关联行政区划或部门关联行政区划或单位关联行政区划
  • 拓展:资源和XXX业务实体建立映射关系,用户关联XXX业务实体

优点:资源和业务实体为弱关联性,可封装成微服务组件对外赋能
缺点:关系模式更加复杂,开发、运维成本高
功能、资源权限管理的设计

业务强关联性设计

基于组织架构、职权(角色)、业务归属、区域、坐标等的业务实体建立如下映射关系:

  • 数据权限的管理最简单的维度就是基于功能权限的管理
  • 根据业务数据归属分别建立用户和数据的映射关系
  • 根据业务数据所属业务闸口、区域(行政区域,地缘,自定义划区)和业务实体建立映射关系,业务实体最终落到用户上
  • 根据业务数据治理出来的坐标体系建立映射管理
  • 其他维度的数据权限管理

优点:方便和业务集成、迁移顺滑
缺点:和业务强绑定
功能、资源权限管理的设计

三、缓存设计

功能、资源权限管理的设计

可能出现的问题:
1:用户权限信息庞大,往redis中存储大数据块
2:用户权限信息庞大,Mysql数据库查询效率低

四、认证服务设计

认证服务负责用户登录状态的维护,对请求方签发令牌;管理权限信息。
基于具体的业务形态,认证服务可划分为两类:内部系统用户认证和权限管理;自建开放平台用户认证和权限管理。
//TODO 后续抽时间设计

五、引用

RBAC模型简介:https://www.cnblogs.com/Naylor/p/15250940.html

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/14893.html

(0)
小半的头像小半

相关推荐

极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!