权限管理怎么做(用户权限管理说的模型解析)

近期PMCAFF有好几个帖子都在问权限如何管理,给大家分享下吧。

1. 角色权限管理

说起用户权限管理,绕不开 RBAC模型,

直接上图:

权限管理怎么做(用户权限管理说的模型解析)

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限(系统资源)进行关联

简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。这样,就构造成“用户-角色-权限(系统资源)”的授权模型。在这种模型中,用户与角色之间,角色与权限(系统资源)之间,一般是多对多的关系

我们可管理的权限(系统资源)分为功能权限、数据权限:

功能权限,管理API和页面元素的可控与否、可见与否

数据权限,管理数据表Key-Value的可控与否、可见与否

上述模型主要体现的是对系统资源的权限管理,接下来说说对人的复杂权限管理:

对人的权限管理需求往往是权限继承、权限隔离等,涉及:

  • 公司体系结构(Company Architecture),例如集团公司的管理,涉及总部和子公司、股权往来公司、业务往来公司等

  • 组织架构(Organization),例如部门和子部门、部门领导和员工等

  • 域(Domain),例如中国域和欧洲域

  • 多业态(Multiple formats),按照不同业态对角色进行分类,例如系统类角色、营销渠道类角色等

如何实现呢?(实现方式很多,这里仅简单举例)

  • 在RBAC模型中引入用户组的概念,为用户赋予用户组,为用户组赋予角色,可考虑将用户组按需关联至公司体系结构层、组织架构层、域层

  • 在RBAC模型中引入角色类型的概念,可考虑将其按需关联至多业态层

  • 引入角色上下级继承等

RBAC模型是目前最常用的用户权限模型,但也有弊端,对权限管理粒度太细了,不一定所有业务场景都需要如此复杂的权限模型,酌情选用,也可以酌情调整模型

2. 功能权限的管理

前文说到,功能权限的管理,本质上是在管理系统资源,是在管理一个系统某个页面中的 API和页面元素,比方说一个按钮

我们有两种做法,

  • 一种是写死,即页面下有哪些API和元素,前端工程师直接写死

  • 一种是配置,即允许用户自行可视化的配置这些元素

如需配置,即可引入菜单管理

菜单用来干嘛?

  • 于系统来说,菜单是我们用来管理系统资源(按钮、页面图片、API等)的载体,通过对菜单和依附菜单的系统资源做权限管控,可以实现细粒度的用户权限管理。因此,菜单管理本身属于RBAC权限管理的一部分

  • 于用户来说,菜单最基础的作用是导航,通过菜单,用户可以快速了解系统的功能模块划分、层级结构,也可以快速切换

菜单管理如何实现?

直接上图:

权限管理怎么做(用户权限管理说的模型解析)

菜单的管理:

  • 菜单名称

  • 菜单编码,即菜单的唯一标识

  • 菜单图标

  • 所属应用,即该菜单属于哪个系统

  • 父级菜单,即配置多级菜单

  • 菜单状态,即停启用

  • 跳转方式,即站内跳转和站外跳转,影响跳转路径的配置

  • 跳转路径,即菜单的URL

  • 打开方式,即跳转后的页面打开方式,在当前页打开,还是新页面

菜单内资源的管理:

  • 资源名称,即该资源的名称,例如「新增用户」

  • 资源路径,即该资源的调用路径,例如「新增用户」的路径是Add User API的地址

  • 资源类型,即API,或页面元素

    • 页面元素,例如一个前端绿色小按钮静态图片

  • 资源关联,例如配置了一个Add User API,又配置了一个绿色的新增用户按钮图片,将其关联起来

这样,我们就可以实现系统资源的可视化配置

3. 数据权限的管理

我们对于数据权限的管理需求,无非是某些数据某个人能看,而另一个不能看之类的。前文正好也讲到,实质上是在做数据表的Key-Value读写权限管理

这里就不上图了,

实现思路也不复杂,可考虑在角色引入

  • 支持选择数据表

  • 支持选择数据表下的Key

  • 支持选择数据表下的Key的Value

  • 支持选择只读、读写

  • 前端页面的逻辑,不要忘记反选哦,很多时候我们的需求就是除了某某之外,其他都能看

派优网部分新闻资讯、展示的图片素材等内容均为用户自发上传(部分报媒/平媒内容转载自网络合作媒体),仅供学习交流。用户通过本站上传、发布任何内容的知识产权归属用户或原始著作权人所有。如有侵犯您的版权,请联系我们一经核实,立即删除。并对发布账号进行封禁。
(0)
派大星的头像派大星

相关推荐

返回顶部