rbac权限,基于角色访问控制(RBAC)技术

　　基本上做过it的人都知道，访问控制其实是一件很麻烦的事情，但也不难理解。在我学习rbac之前，我对权限的理解基本上是权限被分配给角色，角色被分配给用户组，然后用户可以属于用户组等等。一些企业应用程序可能有更复杂的情况。例如，部门A的员工A将被分配角色A；如果A在B部门兼职，不是简单的把B的角色分配给A，但兼职还是有区别的；Rbac只是一个模型。参见以下标准介绍：

　　NIST(美国国家标准技术研究院，美国国家标准技术研究院，2004)标准RBAC模型由四个组件模型组成，它们是：

　　基本模型RBAC0(核心RBAC0

　　角色分级模型RBAC1(分级RBAC，包括一般、有限)；

　　角色约束模型RBAC2(约束RBAC2动态职责分离，即SSD和dsd)；

　　统一模型RBAC3(结合了RBAC)。

　　从上面的rbac0开始：

　　这张图是从右到左分析的。

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

　　2.然后就是op操作。操作不是权限，操作对象=权限，应该这么理解。

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

　　3.prms权限就是图中的红圈，这个不用解释了；角色和用户用户也很好理解。

　　4.会话很难理解。现在让我们假设没有会话。实际上权限控制基本形成。

　　在分配方面，PRM可以分配给多个角色，角色可以有多个PRM，角色可以分配给多个用户，用户可以有多个角色；

　　这就涉及到一个问题，当用户登录系统时，如何计算其拥有的权限？当然，先搞清楚这个用户有多少个角色，再按角色搞清楚总共有多少权限，从而得到一组权限，代表这个用户登录系统后的权限；

　　但有些系统不这么认为，rbac也不这么认为；比如，用过oracle的人应该知道，我们用sqlplus登录oracle时，需要选择是以sysdba还是普通身份登录，这其实就是一个角色的选择；如果选择以正常方式登录，那么sysdba部分权限不可用；是不是sysdba的权限没有分配给用户？不完全是。

　　所以可以理解为所有分配给用户的权限都是一个很大的集合，都处于非活动状态。用户每次登录系统，都有选择地激活一些权限，作为本次登录系统的权限集合；

　　那这个怎么做，看rbac0的图，是session；会话与用户和角色相关。每次用户登录时，都会激活一个会话。该会话对应的角色下的权限是该用户登录系统的权限集合。

　　个人理解，对于一些小型系统，比如一个简单的新闻发布网站，如果想使用rbac进行权限控制，或者想编写一个简单的rbac框架，可以考虑去掉会话的rbac0模式；

　　然后注意ob对象的数据库存储的设计。例如，ob代表系统中的2000个注册用户。从理论上讲，用户的操作可以是读取、修改、删除和添加。如果被分配，所有用户都有权阅读和修改他们的个人信息。然后，有2000个对象x读取和修改操作=4000个权限，然后分配给2000个角色。

　　而且管理员有读取和修改所有用户的权限，所以每增加一个新用户都要在ob中维护这个用户，然后会生成prms分发给管理员，也很麻烦。

　　如果哪个系统需要这么完整和细微的权限控制，那么麻烦是必要的。如果一个简单的系统，比如用户只是普通用户和管理员，就没必要搞得那么复杂。

　　个人理解rbac模式只是给出一个思路，具体实现可以灵活。

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

　　比如我加了潜规则，用户查看自己的信息或者修改自己的信息时，可以直接查看，不需要rbac的权限检查；当然你要明白，这个潜规则不是rbac层面的东西，而是业务层面的东西；

　　再例如，用户添加文档的许可限制用户最多添加10个文档。这种权限在rbac中是如何配置和体现的？

　　嗯，我只能告诉你，没有办法。rbac做的就是有没有这个权限；至于什么时候有，是时间限制还是时间限制，这些都不是rbac关心的，而是业务层逻辑关心的。

　　好了，长谈，我们来看看rbac1，上图：

　　rbac0和rbac1的区别是rh角色继承，类似于oop中类的继承。不多解释了，看官方说明。

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

　　再看上面的rbac2:

　　Rbac2基于rbac0(注意不是基于rbac1)，限制比较多，可能有些机构需要；

　　例如：出纳角色和会计角色不允许分配给同一个人；这个需求只能通过rbac2模式下的约束来实现；或者清洁角色和公司管理员角色不能同时分配给一个用户(基本上没有人会分配错！)

　　约束的作用是实现责任的分离，也就是用户之间的权责，不要重叠太多以免麻烦。

　　rbac2中有两种约束；

　　1.静态责任分离：这是我刚刚给出的例子。某些角色不允许同时分配给一个用户；

　　2.动态职责分离：这是先了解session首先，允许将两个互斥的角色分配给一个用户，突破了静态责任分离的限制。但是，不允许会话同时激活两个互斥的角色。好吧，它也实现了职责分离，但这被定义为动态的；

　　好了，最后给大家介绍一下最好的rbac3。总之，rbac1 rbac2=rbac3无需解释。