做To B的系统总是遇到权限管理的问题。权限管理不是业务功能，但它确实整个系统的基础，决定着各功能是否可用、系统是否满足企业客户的管理需求。而ToB的SaaS系统由于需要面对众多企业客户的不同组织架构与管理需求的使用场景，对权限管理的可配置性要求更高。那么到底如何梳理并设计一套既能灵活配置，又能满足企业的严格权限管理需求的ToB SaaS系统的权限管理机制呢？
什么是权限
系统中的权限一般包含两种：功能权限与数据权限。再进一步细分，功能权限包括页面权限与操作（按钮）权限，数据权限分为字段权限与数据范围。
- 页面权限：页面的访问权限，如客服部的人员应该不能查看运营部的页面；
- 操作权限：拥有不同权限的人可以看到并点击不同的按钮进行操作，即使在同一页面上。如某一页面上有查看、修改两个按钮，用户A可能只能看到并点击查看按钮，而用户B可以看到只能看到查看与修改两个按钮，并且两个按钮均可操作。
- 数据范围：同一页面下，不同用户看到不同的实体的相关数据。如在客服部主管和运营部主管在员工信息的页面上，客服部主管只能看到属于客服部的员工的信息，运营部主管只能看到运营部员工的信息。
- 字段权限：同一页面下，不同用户看到同一实体的不同字段的数据。如员工信息页面上，普通HR只能看到员工的基础信息，但是无法看到员工的身份证号码、薪资，HR主管则可以看到其身份证号码、薪资等敏感信息。
权限管理的设计思路
毫无疑问，目前最为流行的权限管理模型是RBAC(Role-Based Access Control)。
但是，如何设计并使用角色？哪些权限归为一个角色？设计并使用哪些角色？是否系统固化角色及其权限？针对不同的系统，不同的业务需求有不同的设计方案。
首先，我们把ToB的SaaS系统划分为两类：专用型 与 通用型。专用型SaaS指的是该SaaS主要提供专业的某些工具，如Salesforce的CRM 提供客户关系管理的工具，腾讯会议提供远程会议的服务；通用型指的是面向企业客户覆盖跨部门的业务或覆盖大部分甚至全部业务的SaaS服务。
对于专业性较强，功能覆盖集中的专用型SaaS系统来说，可以基于功能点或者基于用户的场景抽象出典型的角色进行内置，这样做能够极大地减少用户在初始化及配置权限时的工作量及复杂度，但有四个前提是：
- 产品经理在产品设计时梳理出来的角色真的能够覆盖所有的业务场景；
- 角色的粒度足够细，以便在实际使用中避免出现下面的情况：角色A包括了两个功能权限：权限A和权限B，而由于业务及管理的需求，管理员希望把权限A赋予用户A，同时用户A不具有权限B，把权限B赋予用户B，同时用户B不具有权限A；
- 梳理出的角色能够经得起企业客户组织结构调整及业务变化的考验，即企业的组织架构的变化以及业务的发展不会导致对角色的需求发生变化；
- 针对SaaS系统而言，内置的角色能够适应各企业客户的业务需求。
对于通用性的ToB SaaS系统与业务流程关联度不高的专用性ToB SaaS系统来说，由于该系统面向企业的各个部门，与部门业务往往紧密相关，而企业的业务发展或管理思路的变化可能导致企业客户的组织架构会变化，岗位职责也可能会有调整，通过梳理出一套覆盖所有业务场景的合适的角色并保证角色能够适应未来企业客户的业务与管理需求，几乎是不现实的。
所以，一般情况下，通用性的ToB SaaS系统或与企业管理流程紧密相关的专用性ToB SaaS系统，笔者认为基本的系统管理角色内置，业务角色可配置应该是更现实的选择。具体做法如下：
- 内置创建对SaaS系统中的后台管理员及租户管理员的角色；
- 对于业务类角色，系统支持对角色进行创建、修改及删除，并灵活的配置页面权限、操作权限、数据范围及字段权限。（某些系统中，可能不需要配置字段权限，具体看业务需求及场景）
- 如果用户数量巨大，可以引入用户组，即把具有相同权限属性的用户归为一个用户组，把角色关联到用户组，即关联到了用户组的每一个用户。
- 租户管理员或租户初始化人员根据企业的组织架构与员工的岗位职责，创建角色并分配相关的权限。为了提高易用性，可以基于典型的用户组织架构及岗位职责，创建一套默认的角色及权限; 租户应用初始化时，租户管理员或初始化人员在此基础上，结合本企业的具体需求，对角色进行增删或对角色对应的权限进行修改即可。
具体的创建默认角色与权限的逻辑可以参考上图。其中，不同部门的相同岗位使用一个角色 还是 不同部门的不同岗位使用不同的角色，可以根据潜在企业客户的组织机构及岗位的标准化程度来确定：如果面向的客户企业的不同部门之间的相同岗位的职责与权限差别比较大，那么应该根据部门&岗位创建角色；如果不同部门的相同岗位的职责与权限比较类似，那么可以直接根据岗位创建角色（即不同部门的相同岗位具有相同的角色）。另外，如果选择后者，具体的数据范围权限可以根据角色所属部门来确定，从而降低数据权限配置带来的使用上的复杂度。
注意：为了保证业务模块与权限管理模块的松耦合，业务模块的代码中无论如何都不应该出现角色名字或角色ID。
具体实现
系统的涉及到权限的地方可以分为两个部分：权限管理模块本身 和 业务功能。两者之间应该保持松耦合的原则，只通过权限ID或名称进行关联。
下面是权限管理模块的数据库表设计。
开源项目Shiro（https://shiro.apache.org/）提供了一套Java安全框架（身份认证、授权、加密、会话管理）。基于Shiro JWT SpringBoot，可以方便地实现对系统功能权限及数据权限的灵活配置与管理。
结束语
权限管理虽然无法直接满足用户的业务需求，但是不好的权限管理设计却足以摧毁整个ToB SaaS系统，让系统变得无法满足企业的管理与业务需求。因此，一个良好而优雅的权限管理模块的设计是整个系统的基础。基于RBAC模型，并且做到权限管理模块与业务功能模块松耦合，对整个系统至关重要。
