saas平台由于其本身“按需购买”的特性，在设计规划权限时，需要考虑统一配置权限如何规避企业没有购买的应用，以及如有部分应用存在数据权限不同的问题。现在，本文简单总结一下当前saas模式下权限的几种设计方式。
作为一个B端平台型产品，系统的权限设计是其中一个非常重要的组成部分，没有权限管理的系统仿佛一个没有门的房子，任何人都可以随意查看甚至调整，对系统的安全性存在非常大的隐患，而saas模式下由于应用基本独立，随时可能被企业拆分使用。
这里权限的统一与拆分问题也十分重要，本文简单总结一下当前saas模式下权限的几种设计方式。
一、权限管理的重要性
权限管理一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源，权限管理基本是任何一个系统的标配模块。它的作用不仅在于保护系统数据安全性、防止留下系统漏洞，更能在庞大的系统下进行模块和数据配置，让不同的角色进入系统看到不同的模块和数据，最大程度地提高系统的易用性。
大部分系统中权限管理是作为一个独立的管理入口，统一设置所有的业务的权限。而saas平台由于其本身“按需购买”的特性，在设计规划权限时，需要考虑统一配置权限如何规避企业没有购买的应用，以及如有部分应用存在数据权限不同的问题。
二、抽象权限组成
权限到底是名词属性还是动词属性，还是名词、动词属性均包含，这对于权限的含义很重要。如果是名词属性的话，那么它应该是有具体的指代物；如果是动词，则应该具有行为表示。
权限的名词属性：api接口、页面、功能点。
权限的动词属性：可操作、不可操作。
那么我们现在来看，其实权限是名词、动词属性，它一定是表达了两层含义。即控制的对象、操作。
向上引申可将权限划分为3个组成部分：
页面权限：用户可以看到那些页面；
操作权限：用户可以在页面内进行那些操作，增删改查等；
数据权限：用户可以看到那些数据或内容；
三、常见的权限控制模型
（1）自主访问控制（DAC：Discretionary Access Control）
系统会识别用户，然后根据被操作对象（object）的权限控制列表（ACL：Access Control List）或者权限控制矩阵（ACL：Access Control Matrix）的信息来决定用户的是否能对其进行哪些操作，例如读取或修改。而拥有对象权限的用户，又可以将该对象的权限分配给其他用户，所以称之为“自主（Discretionary）”控制。
DAC最大缺陷就是所有用户的权限不能统一管理，用户和用户的权限比较分散，后期调整只能单个进行调整，不易维护。
（2）强制访问控制（MAC：Mandatory Access Control）
在MAC的设计中，每一个对象都都有一些权限标识，每个用户同样也会有一些权限标识，而用户能否对该对象进行操作取决于双方的权限标识的关系，这个限制判断通常是由系统硬性限制且无法回避的。强制访问控制多应用于对安全性要求比较高的系统，如多级安全军事系统；
（3）基于角色的访问控制（RBAC：Role-Based Access Control)
RBAC是我们当前使用范围最广的一种权限设计模型，模型基础就是用户和角色，角色和权限做多对多的对应。标准的RBAC模型包括四个部件模型，分别为基本模型RABC0、角色分级模型RABC1、角色限制模型RABC2、统一模型RABC3。
RBAC0（基本模型）定义了完全支持RBAC概念的任何系统的最低需求。RBAC0的模型中包括用户（U）、角色（R）和许可权（P）等3类实体集合，RABC0是权限管理的核心部分，其他的版本都是建立在0的基础上。
RBAC1（角色分级模型）基于RBAC0模型，引入角色间的继承关系，即角色上有了上下级的区别，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种模型合适于角色之间的层次明确，包含明确。
RBAC2（角色限制模型）引入了角色间的约束关系，主要约束规则包括：角色间的互斥关系，在处理用户和这些角色之间的关系时，包括静态分离和动态分离，静态分离指互斥的角色不能同时赋予同一个用户；动态分离指用户不能同时操作两个互斥的角色进行登录。
RBAC3（统一模型）同时包含了1和2的特性。
如图所示，每个用户关联一个或多个角色，每个角色关联一个或多个权限，从而可以实现了非常灵活的权限管理。角色可以根据实际业务需求灵活创建，这样就省去了每新增一个用户就要关联一遍所有权限的麻烦。
简单来说RBAC就是：用户关联角色，角色关联权限。并且在产品和数据设计层面，有更好的扩展性，可控制到任意的粒度。
（4）基于属性的权限验证（ABAC：Attribute-Based Access Control）
ABAC则是通过动态计算一个或一组属性，来是否满足某种条件来进行授权判断（可以编写简单的逻辑）。属性通常来说分为四类：用户属性（如用户年龄），环境属性（如当前时间），操作属性（如读取）和对象属性（如一篇文章，又称资源属性），所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。该设计过于复杂，暂未参透。
对于SAAS平台这样庞大复杂的平台来说，权限系统设计得越全面、精细、后期的系统扩展性就越高，所以这里采用RBAC权限模型，RBAC权限模型是现有比在这方面比较成熟的权限设计模型，应用这个模型能解决常规的系统权限配置问题，其基本原理也能适用于平台权限设计。
RBAC对权限抽象概括：判断【Who是否可以对What进行How的访问操作（Operator）】
RBAC支持三个著名的安全原则：最小权限原则，责任分离原则和数据抽象原则。
最小权限原则之所以被RBAC所支持，是因为RBAC可以将其角色配置成其完成任务所需要的最小的权限集。
责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现，比如要求一个计帐员和财务管理员共参与同一过帐。
数据抽象可以通过权限的抽象来体现，如财务操作用借款、存款等抽象权限，而不用操作系统提供的典型的读、写、执行权限。然而这些原则必须通过RBAC各部件的详细配置才能得以体现。
——来自百度百科
以某物业公司内部信息平台为例，该物业公司平台分为客户档案、房产档案、收费系统、客服工单等多应用结构，其中物业公司组织架构为多层级，基本样式如下如。
组织架构
应用入口
功能页面
以上我们可以将：
组织架构=数据权限
应用入口以及应用菜单=页面权限
功能操作点=操作权限
1. 基本模型：RBAC0
这里的角色主要是指在组织内承担特定的业务活动，并和别的业务角色进行交互的业务角色。业务角色的抽取主要有两种方式：一种是直接和岗位对应，另外一种是根据流程的本质和需要定义角色。
确定各角色的用例图，如下图（简单示例）：
根据业务复杂度、用户特点进行原型草图设计，在进行权限分配时，可以从增加角色维度以及增加用户维度。如下图：
新建角色维度
新建用户维度
使用此模型时，我们需要注意的问题有：
用户和角色为多对一的关系，如果需要用到多对多的关系，将涉及到角色关系的处理，此模型并不适用。
权限一定是动态可配置的，不是静态的，这点一定要在着手开发前进行说明，一般情况，权限的数据结构为树形，合理的数据结构，便于前端根据实际需求进行解析；
人员在选择角色获取到对应的权限数据后，最好可以提供一个二次编辑界面，权限会更加灵活。
2. 角色分级模型：RBAC1
RBAC1基于RBAC0模型，引入角色间的继承关系，即角色上有了上下级的区别，角色分级模型适用于平台业务功能较多，单个角色设置操作过于繁琐，引用角色分级，可让角色之间存在继承或被继承的关系，比如客服主管可直拥有下级所有员工拥有的权限。
建立角色管理，确定角色跟用户之间的关系。（要求角色间有明显的层级关系，所以在没有其他需求的情况下，这里根据业务部门和岗位进行角色的抽取）
建立角色层级关系和继承关系。
角色层级关系
一般继承关系
受限继承关系
给角色赋予权限（应用入口权限——应用页面权限、应用页面中操作功能权限、数据查看权限。）权限赋予同RBAC0。
增加一个角色管理。如下图：
通过角色管理即可以将下级角色的权限直接赋值给上级权限，但由于低级角色的权限全部被高级角色继承，就会导致没有自己角色的私有权限；也可以为人员提供一个二次编辑权限界面，但是一旦编辑后，若后续所属角色权限发生变化，会直接覆盖原有编辑后的权限。
3. 角色限制模型：RBAC2
RBAC2，它是RBAC的约束模型，RBAC2也是建立的RBAC0的基础之上的，在RBAC0基础上假如了约束的概念，主要引入了静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。
SSD是用户和角色的指派阶段加入的，主要是对用户和角色有如下约束:
基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的；
DSD是会话和角色之间的约束，可以动态的约束用户拥有的角色，如一个用户可以拥有两个角色，但是运行时只能激活一个角色。
用户在配置角色或角色下新建添加用户时，需要根据用户已有的角色身份进行判断。示例：用户A配置角色为客服组长，则可继续添加角色为客服主管，若客服主管已被分配给他人，则也不能分配给用户A（遵从最大拥有数原则）。若同时将保安主管分派至用户A，则操作时，需要选择操作角色。
4. 统一模型：RBAC3
统一模型是包括了继承和分离两种情况的更为复杂的模型，即既要定义角色间的的继承关系，也要维护好角色间的责任分离关系。
在这里就不做过多的赘述（两张图供大家参考），因为只要维护好了角色间的约束关系，其他规则类的处理方式同RABC1和RABC2。
角色管理
权限配置
五、总结
不同的角色身份查看的角色数据时不相同的，比如物业分公司中深圳区域分公司的管理人员可能就无法管理长沙区域分公司，在给角色分配数据权限时就可以将长沙区域分公司去除。
除数据权限外，我们还会遇到字段权限，比如：分公司C和分公司D都能看到上海区域分公司的客户情况，但是C看不到客户联系方式，D则能看到联系方式。如果有需要对字段权限进行控制，则可以在设置角色的数据权限或者功能权限时，进行控制。
题前有提到针对saas模式，可能存在一个角色在管理A跟B应用时可操作的数据权限时不一样的，可以在数据权限中增加一个高级设置权限，为不同的角色针对不用的应用进行分配数据操作。
2. 用户操作体验
平台类或者TO B内部产品，虽然不像C端为了留住用户追求极致用户体验，但是也需要确保在交互以及文字理解上面不会让用户产生疑惑情绪，培训成本也是开发成本的一环，尤其针对权限一块可能涉及业务功能复杂，如果在文字描述以及操作上在加大操作难度，可能无法估量的后果。
3. 默认账号以及默认权限的设置
对于ToB类或者平台类的产品，正常来讲都会有一个默认的超级管理员的角色以及角色对应的账号，否则系统内第一个角色谁来添加？
默认权限的设置则根据需要进行设置，如果是不必要进行控制的权限，当然是可以设置为默认权限的。
综上所述，根据以上的设计模式以及解决方案，已经能实现大部分企业90%的问题了，实际上很多企业并不需要做到这么小粒度的权限控制。
