权限管理一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源。通俗解释就是，谁是否具有对某资源实施某个动作（增/删/改/查）的权限。

目前比较成熟的技术模型就是RBAC技术模型（Role Based Access Control），主要通过用户、角色、资源三方面进行权限的分配。具体来说，就是赋予用户某个角色，角色能访问及操作不同范围的资源。通过建立角色系统，将用户和资源进行分离，来保证权限分配的实施。这一模型被广泛运用于各个系统，较易掌握，其技术模型如下图：

用户定义：从系统层面来说，就是登录并使用系统的账号。

用户来源：本系统新增、批量导入、第三方接口同步。

用户分类：

    系统管理员：超级管理员、企业用户管理员（租户）、渠道用户管理员。

    用户：企业用户、供应商用户、渠道伙伴用户。

用户组：本质上是用户的集合。是基于用户的共有属性归纳出的组，目的是减少用户授权的工作量。这里的属性，可能是公司、部门、岗位、公司职级等等。

角色是权限的集合，基于业务需求创建。在用户和权限之间起到桥梁连接的作用，方便大用户量下的权限分配效率，简化了用户与权限的管理。

按照角色类型划分：

普通角色：面向成员公司业务人员，可定义权限数据，也可继承通用根角色的权限数据，普通角色需指定相关的组织级别（销售组织、工厂等）。

复合角色：面向工作岗位，是业务角色的集合。体现角色的包含关系。

通用根角色：是某类工作职能的权限集合，如采购员、销售员等，主要用于企业抽象及固化岗位职权，便于日常权限管理及用户授权，同时可快速派生出业务角色，体现角色的继承派生关系。

按照所属对象划分：

超级管理员角色：SYS_ALL，用于定义系统全部权限,系统预置角色。

企业管理员角色：企业管理员在创建其下的角色时，只能选择该租户所购范围的功能，功能范围可配置。

外部渠道伙伴管理员角色：可创建维护对应渠道伙伴自己的用户及角色，减少企业管理员的权限维护工作量。

角色及授权：

一个用户可以拥有多个角色，一个角色拥有多个权限对象的权限，用户的权限是多个角色权限的并集。

从访问的资源角度来说，权限资源管理主要包括如下两类：功能权限管理、数据权限管理。

功能权限设计实现方案：

功能权限的设计及校验逻辑相对比较标准和统一：查看该当前登录用户的角色是否包含该功能的权限。如果有，则表示有权访问，否则表示无权访问。本次设计的方向和思路主要是聚焦于资源的统一管理及自定义，以及资源管理平台工具的实现。

数据权限设计实现方案：

数据权限管理领域，一直没有统一的技术，大体有如下几种方式：

程序编码：硬编码将权限逻辑与业务代码耦合在一起。此办法缺乏灵活性，难维护且扩展性差，缺点较明显。

人员组织架构树：通过人员所在的组织架构树层级来实现数据权限的控制，此办法实现简单、单一的组织树还可以，但是满足的权限控制场景有限，无法实现非组织类型限制的数据权限管理要求，比如，只能查看国内/某类型的销售订单，无法查看国外/其它类型的销售订单。

数据规则：通过各种表字段、表达式和字段的值等查询条件规则来实现特定范围的数据获取。此办法可以满足绝大部分需求场景，但是大量的查询数据库表势必会影响系统的性能。

不管是功能权限资源还是数据权限资源，都称之为权限资源对象。从系统产品角度，我们将权限资源对象划分为两种类型：标准资源对象，自定义资源对象。

标准权限资源对象：

系统预置部分最常用的权限资源对象，可以满足绝大部分的权限控制需求。未来系统产品可根据实际交付项目需求经验不断迭代累积完善。主要包括如下几类：

功能菜单类：此资源对象主要用于承载和控制功能菜单级权限。

功能按钮类：此资源对象主要用于承载和控制功能按钮级权限。

业务对象类：系统预置相应权限资源对象，常对应数据库中的表，如产品档案、生产任务单等。通过其包含的权限字段参数值来实现数据权限的控制。

API等其它类：系统可扩展其它类对象，满足更多对象的权限控制需求。

自定义权限对象：

交付项目自定义的权限对象，用于满足项目二开功能程序的权限检查与控制，并且可增删改查。

简化和统一权限校验逻辑，降低权限检查的复杂度，提高性能，同时减少交付项目的权限二开工作量。

简化和统一权限检查逻辑

不管是菜单类权限、按钮类权限，还是数据权限，只需要校验用户所具备的权限资源对象下字段参数的值和所要访问的资源对象的值是否一致即可。根据返回的结果值，来判定具体权限情况。