权限系统设计优化简析

产品设计中往往会遇到在复杂产品结构中，用户使用权限的设定及后期维护问题，尤其是作为toB产品来说，牵扯运维、后台管理、复杂的组织架构、多户类型等情况下，网站权限逻辑复杂。无论是在产品开发还是后期维护过程中若没有提前规划好用户权限的分布能力，后期修改成本会非常之高。因此，一个完善的权限系统是非常必要的。
而什么是权限设计系统呢？简单来说就是：用户与用户可在此平台上的行为能力的关联关系。目前关于权限系统的设计主要是基于角色而进行的设计即为RBAC。RBAC(Role- Based access control,基于角色的访问控制)是一种以用户、角色作为主要关联点的系统权限控制系统，包含用户、角色、权限三大组成部分。这个系统可以简单理解为一个用户拥有若干角色，每一个角色拥有若干权限。并且需要注意的是：用户与角色之间、角色与权限之间一般是多对多的关系。这种系统作为一种通用的权限设计系统，对用户权限的规划具有指导意义但是却不能完美解决真实系统中的许多问题,例如大批量用户的角色分配、多权限资源的管理问题等等。
前段时间参与的一个SaaS化产品开发与管理平台，因为介入了大量的用户与角色，而每个用户又都对应着不同的管理能力，这些能力与角色在真实工作中甚至有可能是重复或者交叉的，这些复杂的业务逻辑及角色变化急需一个简洁的权限系统进行梳理。因此，查阅了相关资料后，得出了一个基于RBAC的优化权限系统。
在这个系统中，我将权限规划为以下基本元素：
用户、群组、组织机构、角色、权限、资源、操作。

用户：每一个在此平台上进行创建的用户账号即默认为一个真实存在的用户，同时为保证账号信息的准确性与独立性，减少同一用户的注册多个账号造成的资源浪费，可在用户注册过程中作出一定的检测限制，例如本次使用工号作为唯一识别码，用户可利用工号创建一个账号，用户信息由员工信息系统接口调用而来无需担心姓名等信息的变换问题也避免了账号重复。
群组：群组的产生主要是为了解决大量用户的角色重复问题，需要注意的是用户与群组既可以是从属关系也可以是并列关系，即一个用户可以被多个群组包含的同时作为独立用户存在。
组织机构：若存在用户群组出现从属关系的情况下，适当引入组织机构概念。组织机构的建立可以按照现有真实存在的组织架构铺设，也可以完全新建。但是无论哪种方式都需要提前规划好权限的递增或递减规则，保证组织层级与权限在逻辑上一致。

以上分类都是针对人进行的分类

角色：角色是用户或群组在产品中担任的职务能力,本质是【权限的集合】。有的权限系统，一个用户只能有一个身份，但现实中一个独立个体可能身兼数职所以一对一的模式会带来后期能力扩展的限制。在此次权限系统中，一个用户可以对应多个角色，一个角色也包含多种权限。目前规划角色包含:平台管理员、DSV管理员、项目经理、测试经理、环境管理员、开发、测试等角色，后期针对这些角色分配不同的权限能力。
权限：可以简单理解为能够做某件事情的能力，在此权限系统中,我将权限分为「批量权限】,「单一资源权限】。批量权限是针对角色或用户、群组而进行的统一配置权限，而单一权限是针对某一特定用户而进行的单独配置。对于一个用户来讲，用户的权限集=用户的「批量权限」+用户的「单一资源权限」+用户的所有「角色的权限」。
另外用户创建的资源时，可以获得对应「单一资源权限」的权限。
资源：资源指代用户在该平台中能够获得的支撑，常见的资源可以包含API接口、代码组件、资料文档等等，甚至网页表单中一个输入框都可以算作一种资源，对这些资源的读取、编辑、提交等行为也需视为一种权限能力。
操作：操作行为指用户在平台中对资源进行变动的一切行为，包括但不限于新建、编辑、创建项且、引入人员等，这些操作将会对平台数据产生影响，继而资源组成。
以上分类都是针对物进行的分类

权限系统各因素关系如下图所示：

小结：
网站权限系统的设计就要非常谨慎,既要考虑当前设计方案的严谨性,又要考虑后期的可扩展性。
在进行网站设计之前，便需要依照产品定位构思权限系统，且此时构思完系统框架后，还需要对界面展示、信息结构等交互细节做出梳理。
对于业务逻辑不复杂，且后期不会出现大量业务扩展的产品，其实不需要设计此类权限系统，代码写死可能是最简单的方法。即权限系统是按需供给，无需刻意为之。
若后期系统继续扩大，当前系统角色过于复杂时，可适当引入超级管理员角色持有所有权限，作为最高层级来进行系统管理。但需要注意，超级管理员人数应尽量精简。