如何从0到1建立后台权限管理系统

后台权限功能的框架是什么样的？如何从0到1进行设计？

本文将分为三个部分进行介绍：权限模型都有哪些、如何设计权限管理系统、商业化的产品是如何设计的。

一、权限模型都有哪些

    权限模型主要有这四类：自主访问控制（DAC: Discretionary Access Control）、强制访问控制（MAC: Mandatory Access Control）、基于角色的访问控制（RBAC: Role-Based Access Control)、基于属性的权限验证（ABAC: Attribute-Based Access Control）。

    当前使用最普遍的是RBAC模型，即用户-角色-权限。该模型可以满足大部分的业务场景，较为细化复杂的权限，也可结合ABAC模型来实现。

二、如何设计权限

2.1 了解概念

    系统会有若干个功能，但是不同模块功能会对应企业中不同的管理者，那么权限不尽相同。为了灵活分配给不同用户不同权限，衍生出了用户-角色-权限模型，一个角色封装多个权限操作，可直接将该角色分配给用户：

用户-角色-权限模型

    若大量用户使用同一个角色，则每次分配，仍会有很多重复劳动，所以衍生出了「用户组」的概念，将用户绑定到一个组上，可为这个组赋予一个角色，组下的用户均有这个角色：

引入「用户组」概念

    同理，角色之间有很多相同的权限，每个维护角色时都要勾选大量的权限，因此可以增加「权限组」的概念，将通用的权限打包成组，分配给角色。

引入「权限组」概念

    在设计系统时，可具体问题具体分析，较简单的系统，无需设计的太过复杂，越复杂越灵活，同时越灵活也越复杂；要考虑实际业务场景、培训成本等各个因素。在设计表结构的时候，可以预留出组的概念，产品设计层面0到1，无需设计过于复杂。

    用户，即账号的概念，登录系统要有账号，账号关联着角色，决定可以看到什么、操作什么；每个账号可看到的数据范围也各有不同，因此可以根据不用行业的字段属性，去为账号配置数据范围，也就是基于属性的权限验证（ABAC: Attribute-Based Access Control）。

    权限可以再细分为字段权限和菜单功能权限，不同账号进入系统时，看到的菜单、菜单中的功能都有所不同，进入同一个页面时，页面中的字段是否展示，也各不相同。

    因此，我们在设计权限体系时，可以参考该思考方式去设计。

2.2 5步搭建权限管理

    5步搭建权限管理：创建账号、创建角色、字段权限设计、菜单功能权限设计、数据范围设计。本文将以人事系统为例，进行权限搭建说明。

2.2.1 创建账号

    孤立的系统，可单独设计注册逻辑、后台添加账号逻辑进行账号的创建；人事系统作为员工入离职的核心，因此可在入职成功时，系统自动为其创建一个单点登录账号；离职时，自动失效账号。

    如果需要引用用户组的概念，则可根据一些特定的规则，例如部门、岗位等，自动加入某用户组。也可设计页面为其手动维护到用户组中。

2.2.2 创建角色

    创建角色时，可设置该角色属于哪个角色组，没有角色组概念则可忽略；是否可向下赋权，即该角色是否可设置子角色并分配权限，一般非集团企业，可不进行此设计。

    一般情况下，创建角色只要维护角色名称和描述即可。较为复杂的，可引入角色组或向下赋权的概念，例如集团企业。

2.2.3 字段权限设计

    在角色下，可为不同系统模块分配字段权限；例如，在员工管理模块，可编辑基本信息、工作信息、学历信息，在个人档案模块仅可只读基础信息（具体如何设计系统表结构、字段等，本文不做详细说明，后面有机会会在别的文章进行说明）。

2.2.4 菜单功能权限设计

    账号是否有菜单功能权限，即是否配置了相关的接口权限；在产品设计时，需要梳理好各个页面功能的颗粒度，这样研发同学在拆分接口的时候，才能更好的规划。

    一般权限配置都是由系统管理员来完成，所以保证逻辑通畅、页面较清晰即可；商业化的产品，一般会将菜单功能梳理出来列举好，让用户学会自己勾选配置，通常层级为：目录模块-菜单-功能。如果是内部系统定制化开发，则可不必拘泥于形式，能配置即可，例如下图，先在后台把菜单与功能的接口配置好，再在角色中勾选这些接口，组合成角色-权限。

配置菜单功能页面

2.2.5 数据范围设计

    当多个人拥有相同的菜单和功能，但管理的数据范围有所不同时；例如：A和B同样是HRBP，管理着团队的入离职等情况，但A负责的是产品部，B负责的是企业内所有组长等。此时就需要为不同人划分不同的数据范围，由于人事系统主要的划分属性来源于员工属性，因此在设计员工表的时候，可根据业务划分成不同对象（或者说是表），对象下拥有不同的字段（或者说是员工属性），再根据字段的不同类型，将逻辑判断区分出来；例如，日期格式字段，逻辑判断可为＞/≥/＜/≤/介于/≠/＝等；字典值字段，逻辑判断可为属于/不属于/为空/不为空等。

    如果是其他行业，则可根据具体场景划分出不同属性；这个就是基于属性的权限验证（ABAC: Attribute-Based Access Control）。

配置账号的数据范围

    当每个人都有数据范围时，在做数据共享类似功能时，例如员工档案数据分享时，可仅分享数据统计的逻辑、数据来源，而能看到哪些字段和数据范围则取决于账号本身的权限。

三、商业化产品分析

    一般针对中小型企业的商业化产品的权限都不会做的过于复杂，但是万变不离其宗，无论页面如何设置，其本质没有什么变化。以钉钉举例，钉钉在设置管理范围时，仅支持按组织架构划分，由于钉钉人事模块是后发展起来的，一开始并没有过多的内置各种属性字段，因此管理范围也只能做成根据组织架构划分。但是日常基本够用了。

    当「智能人事」中权限选择细分时，可以看到在单独这个业务下，钉钉也是划分了不同的人事模块，并且不同模块可单独配置字段权限，虽然现在只有员工档案一个模块。但是可以看到架构基本还是这一套，后面也支持各种扩展。