权限管理的“前世今生”

19 评论 15348 浏览 163 收藏 12 分钟

编辑导语:“权限管理”在日常生活中十分常见,它规定了用户各自的角色和可使用的职能。那么,在B端产品中,“权限管理”应该如何设计?本篇文章里,作者针对权限管理系统的发展和设计策略做了解读,一起来看一下吧。

什么是权限管理?百度百科解释道:权限管理,一般指根据系统设置的安全规则或者安全策略 ,用户可以访问而且只能访问自己被授权的资源,不多不少。

何为“不多不少”?简单来讲,就是“用户”可以“做什么”,以及可以“做到什么程度”,都是通过权限管理来控制。

一、“前世”的权限缩影

在我们的生活当中,大到国家、政府,小到企业、家庭,到处都透露着“权限”的缩影。

以企业为例,不同的员工,所对应的岗位职责(也就是权限)也不同:

  1. 人力资源部经理张三负责公司的员工招聘工作,岗位职责是招人及员工管理;
  2. 而李四作为人力资源部的一名人事助理,其岗位职责则是员工信息的档案管理。

以上举例,局限于岗位职责。还有一些更加丰富、更加细腻的权限管理。比如:

  1. 张三是北京分公司的人力资源部经理,他只能够管理北京分公司员工和北京分公司下属的子公司(海淀子公司、朝阳子公司等)的员工;
  2. 王五是海淀子公司的人力资源部经理,他也只能够管理海淀子公司的员工。

这些岗位职责和资源(也称为数据)直接相关,又称为数据级权限管理。

二、“今生”的权限写照

1、现实与权限管理的映射关系

在互联网行业中,权限管理系统中的角色一般跟企业的组织架构是一致的:企业组织架构中的员工在什么岗位要做什么事情,跟权限管理系统中的用户是什么角色被允许进行什么操作,是一种对应关系。

所以企业架构中的员工、岗位、职责和资源 ,分别对应了权限管理系统中的用户、角色、权限和数据。

2、权限管理的分类

从控制力度来看,可以将权限管理分为两大类:

  1. 功能级权限管理;
  2. 数据级权限管理。

从控制方向来看,也可以将权限管理分为两大类:

  1. 从系统获取数据,比如查询订单、查询客户资料;
  2. 向系统提交数据,比如删除订单、修改客户资料。

系统层面的权限管理,主要还是从控制力度上来进行设计。

三、如何进行权限系统设计

权限系统主要由三大部分构成:用户管理、角色管理、权限管理。

1、用户管理设计

账号作为一个用户登录系统的唯一身份标识,其主要通过用户管理进行维护,一般包含有列表页面、详情页面、新增页面。

可以先设想下用户管理大概需要用到哪些字段?梳理完的信息结构图如下:

注:这里以最小可行性的字段设计为例,不同的企业所需要的字段要素会有所增减。

  • 用户编号:作为用户的唯一标识,一般由系统自动生成,由低到高递增;
  • 用户名:用户用于登录的账号,一般支持字母、数字和下划线,需区分唯一性;
  • 密码:账号登录密码,支持字母、数字和特殊字符,需区分大小写;
  • 角色:数据来源于“角色管理”中已维护的角色,可支持多选。

“角色”为什么要支持多选?咱们下面再讲。

为什么这里不设计一个详情页面?因为字段较少,列表已经能显示下所有的字段要素,所以没必要再新增一个详情页面。只有当列表页显示不下所有字段要素的时候,才有必要设计一个详情页来展示所有的用户信息。

现在信息结构图有了,接下来就可以开始设计原型,设计完的页面如下:

(原型:用户管理)

(原型:新增用户)

2、角色管理设计

系统中用户的权限是通过角色来控制,角色可以理解为具备一定权限的用户组,也叫权限的集合,划分角色的好处是可以大大降低用户权限分配的重复性工作量。

“角色管理”的信息结构图如下:

  • 角色编号:角色的唯一标识,一般由系统自动生成,由低到高递增;
  • 角色名称:主要用于识别,可限制不可出现相同的角色名称;
  • 上级:选择所属上级角色,用于搭建组织架构。

根据信息结构图所设计的页面如下:

(原型:角色管理)

(原型:新增角色)

做到这里,“角色管理”还称不上结束,因为还差一个最关键的“权限”。

3、权限管理设计

上文中已经讲过,“权限”分为“功能权限”和“数据权限”。

“功能权限”可粗可细,粗可以到菜单级别,细则可达到功能按钮级别。

“数据权限”有两种处理方式:

  1. 一种是自动继承组织架构关系,这种不涉及页面配置,由程序根据用户的从属关系自动关联。比如:销售部经理可以查看整个部门的销售数据,而销售部的普通员工则只能看到自己的销售数据;
  2. 另一种则是由人工自行配置,划分所需要查看的数据权限。

那么,“角色管理”的信息结构图,加上“权限”后显示如下:

(橙色为新增“权限”部分)

在企业中,一个员工可以身兼多个岗位,一个岗位也可能有多个员工,所以员工和岗位是多对多的关系,由此可以得出“用户”和“角色”之间也是多对多的关系。一个“角色”可以分配多个“权限”,同样一个“权限”可以分配给多个“角色”使用,故“角色”和“权限”之间也是多对多的关系。

如果一个用户拥有多个角色,那这个用户的权限则取的是这多个角色权限的并集。

“角色管理”的页面加上“权限”后如下:

(原型:角色管理)

(原型:配置数据权限)

(原型:配置功能权限)

另外,页面上的功能权限展示,建议与系统模块、菜单页面的顺序来排列好,便于用户理解。

到此,权限系统差不多就设计完了,后续系统在不断的更新迭代时,权限系统也需要做对应的调整。大到功能模块的增、删,小到功能命名的变更,权限系统都需要做到同步变更,以求一一对应。

四、总结

权限管理对于B端产品来说必不可少,权限管理具体应该做到什么程度,跟企业运营息息相关。在设计权限系统时,一定要结合企业发展,提前做好规划,才能满足业务需求。

 

作者:WOWdesign,研究设计价值最大化,涉及用户体验、品牌体验、空间体验。

本文由 @WOWdesign 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Pexels,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 请问数据权限要怎么具体设计呢?可以展开讲讲吗

    来自江苏 回复
  2. 有遇到同一个用户对不同的数据范围有不同的功能权限的吗?好像说是完全数据驱动

    来自河南 回复
    1. 通过角色管理功能权限,通过组织架构管理数据权限;数据权限管理的常用方式:1、 数据权限可以通过组织架构的上下级来继承; 2、除了继承,支持自定义:按 全部数据、本部门及下级部门数据、本部门数据、本人数据等; 3、在自定义数据权限基础上更进阶的设计,是数据权限的多维度配置,比如一个销售订单,有销售员、销售部门、销售区域等部门维度,也有产品1、产品2等类型维度,多维度数据可以交叉,然后去交集就是最终的数据权限。

      来自北京 回复
  3. 文章权限设计-页面上线功能权限展示,这种比较适用于单个系统的权限管理配置。但权限管理系统基本可以抽象通用化,一般公司都维护一套权限管理系统,定义好与各个业务系统接口调用即可。如果多个系统共用,功能权限展示可以定义成树状结构,每个系统独自定义菜单、子菜单和功能即可,通用性会更强~

    来自北京 回复
    1. 这种需要公司各个系统用户群一致吧?如果不同系统服务不同客户就不行了。

      来自上海 回复
  4. 请问一下,对于列表数据的增删改查是属于数据权限还是功能权限呢?😭

    回复
    1. 功能权限

      来自浙江 回复
  5. 用户可以跟部门挂钩

    来自福建 回复
  6. 但是关于数据权限我有一个问题,配置数据权限时是选择角色,但是角色是活的可以随意配置的,这些角色各自能看到哪些数据该如何规定呢?

    来自北京 回复
    1. 给角色配权限就能满足,比如财务这个角色只给他开放财务相关的权限

      来自广东 回复
    2. 那如何定义哪些数据属于财务方面的数据呢,是系统设计的时候定义好的吗还是系统可以配置的?

      来自江苏 回复
    3. 作者的意思大概是:给当前角色配置数据权限,如当前角色下还有若干个子角色,选择自定义配置时选择可以拥有哪几个子角色的数据权限!我是这样理解的,不知道对不对😭

      回复
  7. 太棒了!条理清晰,还有原型展示,多谢作者分享!

    来自北京 回复
  8. 角色有上级 这个有点问题。个人感觉是把角色与岗位等同了,不太妥当

    回复
    1. 很多企业管理软件都有这个设计,可能是方便使用

      来自江苏 回复
    2. 角色把岗位等同,会导致角色数量变多,比如销售部门:一组销售组长、二组销售组长; 用作者的方法,需要设置两个角色。实际上两个组长的功能权限是相同的,都叫“销售组长”,不同的是数据权限,一组可以看一组负责的客户数据,二组组长可以看到二组负责的客户数据。
      对于数据权限,应该是挂到用户上;通过用户的部门、上级来维护一套组织架构,实现数据权限的继承。实现自定义数据权限,就是直接把某个用户的数据给到 另外一个用户

      来自北京 回复
  9. 对权限管理系统的发展和设计策略分析得很清晰,喜欢这种有思维导图的文章。

    来自广东 回复
  10. 角色管理为什么要有上级角色

    来自江苏 回复
  11. 什么时候权限管理的设计能够真正做到维护用户隐私呢,感觉互联网时代个人隐私越来越难得到保障了。

    来自湖北 回复