第二篇 如何设计一个RBAC权限系统

导语
  在我们的企业应用开发中，系统安全问题一直是一个绕不开的话题，而权限控制又与系统的安全有着密切的关联。从用户登录到按钮权限控制，都涉及到了安全与权限控制。

  在实际的企业级应用开发过程中一个比较常用的权限控制模型就是RBAC权限控制模型。RBAC权限控制模型也是迄今为止最为普遍的一种权限控制模型，基于角色的访问控制（Role-Based Access Control）

RBAC 最简模型

  如图所示，一个用户可以有多个角色，一个角色可以有多个权限，这样就会在用户与角色之间形成N对M的关系，在角色与权限之间也形成N对M的关系。这个作为权限控制最基础的一个模型，其中用户作为发起操作的主体，按照类型可以分为B端的用户和C端的用户，也可以是后台管理的用户，也可以是OA系统内部员工用户。例如在一个OA系统中，员工的账号管理。

  这其中其实角色起到的作用就是连接用户与权限的关系。每个角色关联了多个权限，每个权限控制一个操作。用户可以通过关联多个角色来完成对于多个操作的访问权限。也许这个时候就会有人问，为什么不是用户直接关联权限呢？简单说明一下，在用户体量较小的情况下，可以这样完成，例如一个系统只有一个或者两个用户的时候，甚至可以通过条件判断来完成权限控制，但是对于一个OA系统来说，它的用户体量应该是100往上的，这个时候如果一个用户一个用户的去分配权限，就会有大量的工作，另外一个问题是，这其中，有领导、普通员工之分，这个时候，就可以通过领导与普通员工两种角色来对权限进行区分，而不是每一个用户都鉴权，因为这其中所有领导的权限应该是一样的，所有员工的权限是一样的。这样一来通过角色就可以节省一大笔的开发精力。

  总而言之，权限系统是维护了人与可进行操作的行为之间的关联关系。

  权限又可以分为页面权限、菜单权限、数据权限等等。

页面权限
   也就是说控制用户可以看到那些页面，这些页面的可见性是由菜单来进行控制的，而菜单又包括一级菜单和二级菜单。只有用户有了一二级菜单的访问权限，用户才能访问对应的菜单页面。

操作权限
  在一般的页面功能上都会有最为基本的四个按钮，增加、删除、修改、查询。当用户对这些按钮进行操作的时候，后台就会对用户权限进行校验，判断用户是否具有对应的操作权限。如果有对应的权限，那么就可以进行下一步的操作，如果没有对应的操作权限，就无法进行操作。还有一种控制是通过用户权限判断是否现实对应的按钮。如果有权限则显示对应的按钮，如果没有权限则不显示对应的按钮。这样从某种程度上讲也是对用户体验的一种提升。既然不让人操作，那就直接不显示对应按钮。

数据权限
  数据权限，就是根据用户在同一个页面上看到的数据是不同的，例如部门A的管理人员，就只能看到部门A下的员工的数据。部门B下的领导就只能看到部门B下的员工数据。还有就是如果有分公司的情况，A分公司只能看到其对应的数据，B分公司也只能看到其对应的数据。

  如图所示就是RBAC基础权限控制模型，通过以上的这种模型还扩展除了如下的一些模型。

RBAC角色继承权限模型

  在这个模型中，引入了角色继承概念，也就是说角色之间有了上下级的关系，角色之间可以分为普通的继承与受限制继承关系。

  一般的继承关系只是要求角色继承关系是一个绝对的偏序关系，也就是允许角色之间的多继承关系。而受到继承关系的约束，一般要求角色继承满足一个树状结构，如上图所示。角色之间通过单继承的关系，实现层级关系，这种设计即可分出角色，还可以分出层次。

RBAC 角色约束控制

  这种模型，是基于核心模型基础上对角色进行约束控制，在这个模型中添加了责任分离关系，规定权限被赋予角色的时候，或者角色被赋予用户的时候，以及在某一个时刻激活一个角色应该对应的一种强限制规则。这种责任分离规则可以分为静态责任分离和动态责任分离两种

  主要包括如下的一些约束规则

• 互斥约束：同一个用户只能被分配到一组互斥的角色中的一个角色。什么意思呢？互斥的角色是指角色各自的权限相互制约的两个角色。例如在财务管理中，会计和审核员两个角色，他们就是互斥的角色，用户不能同时拥有两个角色，体现了责任分离的原则。
• 基数约束：一个角色被分配的用户数量限制；一个用户可以拥有的角色数目受限制；一个角色对应的访问权限数据也会受到限制。这样可以控制在更细致的权限系统中进行分配。
• 先决条件角色：就是说用户想获取某个上级角色，必须先获取下级角色。

RBAC最全面的权限管理模型

  在某些用户较多的系统中会出现这样一种情况，用户权限分配较多的情况下，后台管理人员会有大量的工作量来对用户进行角色的分配。这个时候就出现了用户组的概念。将相同操作的用户作为一个用户组。然后对用户分配角色权限，这样一来这个用户组中的所有用户都会有这个角色的权限，这样就减少了后端管理人员的工作量。

  另外在有些公司中，存在角色之间的上下级关系，这个时候，角色权限就与其所在的职位相关，这个时候，不同的用户组中的用户，会因为职位的不同有不同的权限。职位越高拥有的权限也就越多，这样一来。整个的系统中不但有横向的用户组，还有纵向的角色层级。如上图所示。

  在单系统且用户类型单一的情况下，用户和组织是一对一关系，组织和职位是一对多关系，用户和职位是一对一关系，组织和角色是一对一关系，职位和角色是一对一关系，用户和用户组是多对对关系，用户组和角色是一对一关系，当然这些关系也可以根据具体业务进行调整。模型设计并不是死的，如果小系统不需要用户组，这块是可以去掉的。

  分布式系统且用户类型单一的情况下，到这里权限系统就会变得很复杂，这里就要引入了一个"系统"概念，此时系统架构是个分布式系统，权限系统独立出来，负责所有的系统的权限控制，其他业务系统比如商品中心，订单中心，用户中心，每个系统都有自己的角色和权限，那么权限系统就可以配置其他系统的角色和权限。

总结

  权限系统可以说是整个系统中最基础，同时也可以很复杂的，在实际项目中，会遇到多个系统，多个用户类型，多个使用场景，这就需要具体问题具体分析，但最核心的RBAC模型是不变的，我们可以在其基础上进行扩展来满足需求。