本文由作者 Dennis_发布于社区

近期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
  • 支持选择只读、读写
  • 前端页面的逻辑，不要忘记反选哦，很多时候我们的需求就是除了某某之外，其他都能看
↘好文推荐：
所有人问「贴吧之父」俞军
产品经理逻辑学通识
干货 | 产品经理要了解的技术类知识
👇欢迎关注：
点个“在看”吧
继续阅读
阅读原文
关键词
用户
资源
菜单
架构
权限管理