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权限 进行扩展和实现，成熟的开发模型就能为开发者带来足够的便利，也很佩服勤劳、勇敢、智慧的工程师，可以设计出如此出彩的模型。  此次也深入地意识到本身知识面的不足，本身闭门造车确定会与这个社会脱节，与此同时，学习速度太慢，不会使用搜索引擎去找答案，也会被这个社会淘汰。谨记。