RBAC：权限模型的初步理解

  近来部门接到一个外包项目，是基于现有的系统做一个知识文档库，类似于百度网盘一样的功能，只是在角色和权限上与网盘不同，这个项目我们部门称为KM，Knowledge Manager ，难点就在于文件的权限管理。

  以下是与权限相关的一些功能点：

• KM 有五类角色：KM 企业管理员， KM 部门管理员 ，KM团队管理员 ，KM团队成员 ， KM成员，权限依次递减

• KM 有三个实体 ： 网盘、文件夹、文件

• KM 网盘的类型有：部门网盘，团队网盘，个人网盘

• KM 文件夹的操作：创建、修改、删除、移动、分享、授权

• KM 文件的操作：创建、修改、删除、移动、分享、授权

归根到底有两点：

1. 不同角色对不同实体的操作有不一样的权限

2. 高级别的角色可以改变低级别的角色对指定实体的操作权限

  我自己出来工作已经两年，计划五年内成为一名架构师，虽然这次不需要我对系统进行设计，但是我肯定不会放弃这次机会，在上级出方案之前，我足足把需求文档看了四遍，去想如何才能设计一个好的架构进行开发，不过，最后的结果还是打击到我了，实在没想到还有如此简单的方法。全文分解为两部分：

• 我自己的设计：策略模式

• 上级的设计：RBAC权限模型

策略模式

  开始的想法是，架构必然和设计模式有关，考虑到实体执行的操作类型如上文所说基本有六种操作，结合五类角色，正好可以采用策略模式，基本的思路如下：

• 获取用户信息，基于不同网盘、文件夹、文件，实现对应的角色

• 根据角色，判断对应的操作是否具相应的权限

• 若不满足权限，则查询权限表，判断高级角色是否授权

• 最终返回是否具备权限的数据，以供前端进行响应式回显

  这就是我最开始的思路，其实想到这套方案，心里还是挺开心的，原因在于：

• 用到了策略模式，刚学就能用上

• 解耦，以后不同角色对不同实体的操作的维护难度大大降低

• 不需要频繁的查询数据库，毕竟有一部分业务逻辑是不需要通过查询数据库的，类似于KM 企业管理员，权限最大，对任何实体都具备操作权限

  然而当我把想法在早会上提出来时，上级告诉我说，现行有一种很成熟的权限模型：RBAC权限模型，他的设计能够解决这个项目大部分的需求。方案不被采纳固然有一点小失落，但是，我却看到了一个很厉害的模型，足以让我涨见识，以后遇到权限管理的时候，首先应该想到RBAC模型，结合项目的需求，对模型进行扩展。

RBAC权限模型

• 基本概念

  • 基于角色的权限访问控制（Role-Based Access Control）

  • 权限授权实际上是Who、What、How的关系，三者构成了访问权限三元组,也就是“Who对What(Which)进行How的操作

• 支持三个著名的安全原则

  • 最小权限原则

  • 责任分离原则

  • 数据抽象原则

• 类图
  

• 数据库表：
  

• 个人理解

  • 通过给角色授权，然后将附有权利的角色施加到某个用户身上，这样用户就可以实施相应的权利

  • 通过中间角色的身份，是权限管理更加灵活：角色的权利可以灵活改变，用户的角色的身份可以随着场所的不同而发生改变

  • 这样这套RBAC就几乎可以运用到所有的权限管理的模块上

---

  RBAC在使用的过程，被不断地改进，进一步研发出更成熟的模型，以下的模型则是基于基本模型进行扩展：

• RBAC1 ：基于RBAC0模型，进行了角色的分层，也就是说角色上有了上下级的区别，存在了继承包含关系，也就是前边说过的适合于用树展现的哪种自关联的结构，这种模型合适于层次明确，包含明确的角色关系

  • 类图
    

• RBAC2 ：基于RBAC0模型的基础上，进行了角色的访问控制。

  • RBAC2中的一个基本限制时互斥角色的限制，互斥角色是指各自权限互相制约的两个角色，对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权

  • 角色的权利权利是有限的，用户有用的角色也是有限的，当然分配用户时也是有限的，不能进行无限制的分配用户

  • 要想获得较高的权限，要首先拥有低一级的权限

  • 类图
    

• RBAC3 : 最全面级的权限管理，基于RBAC0的基础上，将RBAC1和RBAC2进行整合了，最全面，也最复杂

  • 类图
    

---

  任何的权限控制都可以基于 RBAC权限 进行扩展和实现，成熟的开发模型就能为开发者带来足够的便利，也很佩服勤劳、勇敢、智慧的工程师，能够设计出如此出彩的模型。
  这次也深刻地意识到自己知识面的不足，自己闭门造车肯定会与这个社会脱节，与此同时，学习速度太慢，不会使用搜索引擎去找答案，也会被这个社会淘汰。谨记。