RBAC基于角色的权限控制个人理解

基本上搞过it的都知道权限控制其实是很麻烦的一件事情，但是不难理解。在我学习rbac之前，对权限的理解基本上就是权限分配给角色，角色又分配给用户组，然后用户可以属于用户组之类的。一些企业级应用可能会有更复杂的情况，比如A部门的员工甲，就分配A角色给甲；若甲在B部门兼职，那就不是简单的把B角色分配给甲，兼职还是有区别的；rbac也只是一种模式而已，看下面的标准介绍：

NIST（The National Institute of Standards and Technology，美国国家标准与技术研究院，2004）标准RBAC模型由4个部件模型组成，这4个部件模型分别是：

·基本模型RBAC0（Core RBAC）；

·角色分级模型RBAC1（Hierarchical RBAC，含General，Limited）；

·角色限制模型RBAC2（Constraining RBAC，含Static/Dynamic Separation of Duty，即SSD和DSD）；

·统一模型RBAC3（Combines RBAC）。

先从rbac0开始，上图：

此图从右往左分析

1、先看ob对象，也就是我们需要 *** 作的对象，可以是用户本身，可以是角色本身，也可以是任何需要做权限控制的实体或虚拟的数据；

2、然后是op *** 作， *** 作不是权限， *** 作 + 对象 ＝ 权限，应该这样理解

拿windows的文件来举例，那么ob就是文件，op就是 读、写、执行等，而权限 可以理解成 ob 和 op的笛卡尔乘积；例如  对文件的读权限、对文件的写权限等

3、prms权限，就是图中的大红圈，这个就不用解释了；role角色、user用户   这2个也很好理解

4、session这个比较难理解，现在我们假设没有session这个环节，其实权限控制也基本成型；

从分配上理解，prms可以分配给多个role，role可以有多个prms，role可以分配给多个user，user可以有多个role；

这样涉及到一个问题，当用户登录系统后，它具有的权限怎么计算呢？当然是先找这个用户有多少个角色，然后通过角色找总共有多少个权限，这样得到的一个权限的集合，这个集合就代表这个用户登录系统后的权限；

但是有的系统不是这么考虑的，rbac也不是这么考虑的；例如oracle，使用过的人应该知道，我们用sqlplus登录oracle时，需要选择此次登录，是用sysdba还是normal，这其实是对角色的一种选择；如果你选择以normal方式登录，那sysdba部分的权限就没有；那是不是sysdba部分的权限没有分配给用户呢？其实也不是

所以可以这样理解，所有分配给用户的权限是一个大的集合，而且是处于未激活状态，每次用户登录系统的时候，有选择的激活一部分的权限，作为此次登录系统的权限集合；

那如何做到这点，看rbac0的图，就是session；session是关联用户与角色的，每次用户登录，就会激活一个session，这个session对应的角色下的权限，就是此次用户登录系统的权限集合；

我个人理解，对于一些小的系统，比如一个简单的新闻发布网站，想用rbac来做权限控制，或者是自己想写一个简单的rbac小框架，可以考虑去除session的rbac0模式；

然后要注意ob对象这个数据库存储的设计，例如ob代表系统中注册的用户，有2000人，从理论上讲，用户的 *** 作有  读、修改、删除、新增，如果要分配的话，那所有用户都对自己的个人信息有 读、修改 权限，那就有 2000对象 x 读、修改 *** 作 = 4000个权限，然后分配给2000个角色，这2000个角色又单独分配给对应的2000个用户，这样就变的非常的麻烦；

而且，管理员有所有用户的 读、修改 *** 作权限，那每新增一个用户，都要把这个用户 维护到 ob中，再产生prms，再分配给管理员，这样也非常的麻烦；

如果哪个系统需要这么完整细微的权限控制，那麻烦是必须的，如果简单的系统，例如用户只有 普通用户 和 管理员 2种，那完全没有必要弄的那么复杂；

我个人理解，rbac模式只是给出一个思路，具体实现是可以灵活多变的；

比如ob，我可以把“所有用户”作为一个ob，然后 对此ob的 *** 作权限分配给管理员，这样就不怕动态新增用户的时候，需要维护权限表；

再如，我加上潜规则，在用户查看自己的信息、或修改自己的信息时，可以不经过rbac的权限校验，直接查看；当然，你要理解，这个潜规则，就不是rbac层面的东西了，应该是业务层面的东西；

再举个例子，用户新增单据的权限，限制用户只能最多新增10张单据，那这种权限在rbac中如何配置如何体现？

好吧，我只能告诉你，没有办法。rbac做的仅仅是  有 或者 没有  这个权限；至于 什么情况下有，是次数限制  还是  时间段限制，这些都不是rbac关心的，这些是业务层逻辑关心的。

好吧，说多了，来看看rbac1，上图：

rbac0 和 rbac1之前的差别在rh角色继承，这个继承和oop中类的继承很相似；不多解释，看看官方点的说明

角色间的继承关系可分为一般（General）继承关系和受限（Limited）继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则增加了职责关系的分离，进一步要求角色继承关系是一个树结构。一般继承的RBAC和受限继承的RBAC两者的区别在于：前者是图；而后者可以有多个父节点但只能有一个子节点，是一个反向树结构。

再看看rbac2，上图：

rbac2是在rbac0 的基础上（注意不是rbac1的基础上），加上了更多的限制，这种限制在某些机构可能会需要；

举个例子：出纳角色  和  会计角色，不允许分配给同一个人；这个需求就只能通过rbac2模式中的约束来实现；或者 保洁角色 和 公司管理员角色  不能同时分配给一个用户（这基本上不会有人分配错吧！）

约束的作用是实现责任分离，就是用户相互之间的权限与责任，不要太多的重叠在一起，免得出麻烦

rbac2中的约束，分2种；

1、静态责任分离：就是我刚刚举的例子，不允许某些角色同时分配给一个用户；

2、动态责任分离：这就是要先理解session了；首先允许把互斥的2个角色分配给一个用户，突破了静态责任分离的限制；但是，不允许session同时激活2个互斥的角色，好吧，同样是实现了责任分离，不过这个被定义为动态的而已；

好了，最后终于要给大家介绍最牛x的rbac3，一句话：不解释，rbac1+rbac2=rbac3