OA办公软件篇（二）—权限管理
权限管理的背景
权限管理的作用
迭代历程
关键名词释义
权限管理模型
具体实现
写在最后
权限管理的背景
在OA办公软件篇（一）—组织架构一文中，我们说到组织架构是软件系统的权限体系的重要搭建依据，软件根据不同员工在组织中的位置给予不同的权限，比如说普通员工对于软件只有查看和使用的权限，普通管理员对于软件有查看和修改的权限，超级管理员则拥有最大权限等。这一篇文章就将移动端和管理端结合结合起来讲讲权限体系搭建的一些方式和使用效果做一个讲解。
百度百科上面关于权限管理的解释为：“权限管理一般指根据系统设置的安全规则和安全策略，用户可以访问而且只能访问自己被授权的资源，不多不少。权限管理几乎出现在任何有用户和密码的系统。”由此可见，权限管理实质上就是一系列规则和策略，帮助系统很好的规范用户“行为”，系统不让做、不让看的用户就无法操作和获知。
权限管理与“用户身份认证”、“密码加密”、“系统管理”等概念不同，不要混淆了。用户身份认证解决的是“你是谁”的问题；密码加密隶属于用户身份认证领域；系统管理一般是系统的一个模块，该模块会包含权限管理子模块，但系统管理的权限管理，只是一个操作界面，让管理人员能够设置角色等安全策略。
权限管理的作用
古人云：“无规矩不成方圆”，权限管理就是规矩的一种，它限制人们做事情的范围，保证大家之间不会产生冲突，使得系统能够有序运行。
对于企业而言，对员工进行权限控制和管理的根本目的还是在于使公司能够有效和高效的运转，具体体现在以下三点：
（1）能够保证员工各司其职，每个人所负责的内容不一样，互不干扰，从而提升工作效率。
（2）每个人负责的工作范围具体而明确，责任到人，权责分明，出了问题有据可查。
（3）不同的人负责的工作重要程度不同，如机密事项只能少数人知晓，能够保障隐私，从而规避风险。
迭代历程
一般咱们做权限管理系统，基本上只会涉及到一个端的权限管理问题，原因为通常只有后台管理端涉及的页面和管理项操作需要进行权限管理，移动端则不涉及到太多权限管理的问题，比如医疗产品，移动端用户使用用户名和密码做身份验证，正常使用就好了，不需要再给用户分层分权限。
OA产品则比较特殊，在整个产品运行体系中，各个端都会涉及到权限管理系统，这个原因究其根底还是因为OA系统的用户层级分明，架构庞杂，如果是行业专用OA则会更加复杂（我目前所在OA产品就是医药行业专用OA）。移动端的用户需要根据用户权限决定其能否进行流程审批、功能使用等。
1. 先说一下移动端
在上一篇文章《OA办公软件篇（一）—组织架构https://www.cnblogs.com/zshsblogs/p/15991723.html》中，我们探讨了普通员工和管理人员究竟是采用两个独立移动端来实现还是使用一个来实现的问题，这里面充分反映出来在移动端权限管理这一块，该产品进行了怎样的迭代过程。
第一个阶段：OA产品用两个端实现，以身份代替权限，将普通员工和管理人员按照两个端模式严格进行功能区分，不同账号、不同端口登录使用不同的身份验证方式，同一端内的功能使用则仅按照规则内置的方式进行简单的“权限控制”。
第二个阶段：两个端合为一个端，重新梳理和定义不同角色在同一功能下的表现形式，重塑权限体系。
第一个阶段和第二个阶段相比，权限管理不成体系，功能权限无法明确有效的控制，造成的后果就是管理不清晰，无法“权责分明”，比如管理端的日志抄送配置功能所有管理端用户都可以进行操作，出错后无法追溯；隐私性比较差，比如业务数据和客户信息所有管理端成员都能够无差别的看到。
这里就不得不说，千万不要为了一时的利益就枉顾产品设计和迭代的基本原则，为了完成任务而完成任务的结果就是，后来的产品经理和研发拿着一堆食之无味弃之可惜的产品功能反复权衡，既不想付出过多的人力和时间大幅度整改，又不得不在一盘散渣的基底上来回摩擦，最后不得已走上重构的路。
2. 再说一下后台管理端
在我目前所在的这个OA产品中，受研发资源的影响，后台管理端一直没有规划设计和开发过，所以整个后台管理系统都是由我从0到1设计、研发并投入使用的。后台管理端在这里起到的作用是便于行政和管理人员的使用，比如日常考勤数据导出、审批统计等。后台管理端未走弯路，一气呵成。
关键名词释义
先来看几个权限管理相关的名词解释。
（1）权限管理系统定义
权限管理系统是权限管理的具象表现形式，主要进行角色管理、用户管理、赋权、用户追溯等工作。
（2）角色
角色代表某一类人，不特指某一个人，角色最好采用职位或者抽取人群共性进行命名，比如市场部员工角色、销售部主管角色，便于理解和使用。
（3）权限
权限分为：页面权限、操作权限和数据权限。页面权限控制能够看到哪个页面，操作权限控制能够操作页面上的哪些功能按钮等，数据权限则控制你能够看到哪些数据。
权限管理模型
大部分涉及到权限管理的产品都会涉及到一种模型：RBAC（Role-Based Access Control）模型，基于角色的权限访问控制，它将who、what、how进行了关联，解释了谁（who）对什么（what）做了怎么样操作（how）的问题。RBAC包含四个子模型，分别是RBAC0、RBAC1、RBAC2和RBAC3，他们的核心思想都是相同的，只是存在部分差异。
RBAC0是基础，其它三个子模型都是由他演化而来，在他的基础上各自进行变形。RBAC0最显著的特点就是人不直接与权限相关联，而是通过角色这一中间介质，获取系统的权限。在这个模型中，角色与权限之间属于多对多的关系，用户所拥有的权限等于他所拥有的所有角色下的权限的总和。RBAC0中的用户、角色和权限的关系如下图所示：
RBAC1是在RBAC0的基础上，增加了角色分层和角色继承的能力，一个角色拥有不同的等级，不同的等级拥有不同的权限。通过角色分级，可以实现更精细化的管理。角色和权限的关系如下图所示：
RBAC2是在RBAC0的基础上增加了一些对角色和权限的限制。分别是角色互斥限制：当系统中有多个角色的时候，用户只能拥有/激活他们中的一个角色；角色基数限制：限制用户只能拥有或者激活一定数量的角色，限制角色只能被赋予一定数量的权限；先决条件限制：当用户想要拥有一个角色的时候，必须拥有另一个角色才可以，或者当角色想要拥有一个权限的时候，必须要拥有另一个权限才可以。
RBAC3是RBAC1和RBAC2的合集，同时拥有这两个模型的所有特点，他们的关系如图所示：
具体实现
在这里我们不再一一介绍移动端的实现过程，仅用管理端为例说明权限管理的实现过程。
在进行权限管理系统设计之前，首先需要根据实际情况明确使用的是哪一个模型，都有哪些限制等。我这里根据当前OA的使用和拓展情况采用RBAC0进行实现，同时采取了角色互斥的限制。
（1）角色管理
角色管理是权限管理的第一步，主要分为角色创建、角色删除、角色权限分配三个功能点，如下图所示：
（这里因为医药OA多公司使用的特性，因此角色也会分为总公司角色和普通公司的角色）
后台管理端权限分配这里仅涉及页面权限分配，数据权限直接使用的是默认规则，而操作权限则是因为不太必要所以没有进行处理。
（2）用户管理
用户管理这里涉及到两种模式，一种是直接从组织架构中获取用户进行权限控制，如下图所示：
一种是非组织架构用户需要新增管理，如下图所示：
一般情况下，组织中的顶端（董事长、总经理）及部分特殊岗位拥有超级管理员的权限，组织中的管理者（中层管理人员、普通管理人员等）拥有普通管理员的权限，组织中的一般员工为一般用户权限。除了按照组织进行默认的软件权限的划分，支持手动的权限划分和管理也是软件的一项重要的功能。当然，权限体系的划分逻辑不仅限于此，重要的是权限体系的扩展性！
为用户设置角色，如下图所示：
（3）行为追溯
为了进行用户行为追溯，将用户行为日志进行记录。
（4）管理端对移动端的相关管理
根据部门对移动端功能权限和数据权限进行管理，一个部门相当于一个角色。
写在最后
理解清楚RBAC模型，权限管理并不难。通常我们都是用现成的管理后台，这一部分的设计往往被产品经理忽略，但实际上，只要涉及到产品的从0到1，权限管理就是必须要考虑的重点事项，因此一定要懂。而对于技术来说，也只有理解清楚权限管理的核心逻辑，才能够做出BUG少、逻辑清晰、扩展性比较强的权限管理系统。
