RBAC模型的探究（一）

最近在作本身的毕设，须要用到RBAC模型！如下内容是本身从书上或网上得来的！

 角色访问控制（RBAC）引入了Role的概念,目的是为了隔离User(即动做主体，Subject)与Privilege(权限，表示对Resource的一个操做，即Operation+Resource)。
Role做为一个用户(User)与权限(Privilege)的代理层，解耦了权限和用户的关系，全部的受权应该给予Role而不是直接给User或Group。Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。例如，对于新闻的删除操做。Role-Privilege是many-to-many的关系，这就是权限的核心。基于角色的访问控制方法（RBAC）的显著的两大特征是：1.因为角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减少了受权管理的复杂性，下降管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

1.1       肯定角色须要操做的对象

1.1.1 以数据库中的表做为资源

在本系统中能够存在两种方案来定义角色须要操做的对象，一种方案是角色直接与数库中的表相关联，也就是说创建一张角色与表的关系表就能够放映出这个关系，可是这样设计有一个地方很差控制，系统完成后是以一个一个页面的形式存在于客户面前，而每个页面里面所表现的内容难道只和数据库中的一张表有关系？若是存在和多张表的关系时候，那就得首先判断某特定用户属于的角色对这些表的全部权限以后再处理具体的表示层；这种作法须要请求一个页面的时候进行比较多的判断，至关于在角色页面中又增长了一个数据库，即为角色，数据库，页面之间的关系，在作一个对数据库操做比较少的系统时这么作显然是很麻烦的。

1.1.2 以页面做为资源

本系统另一种定义资源的方式是以页面作为资源，当页面作为资源的时候，咱们能够在一开就用一个 asp.net内置的对象session来存储角色，而后再用户要请求该页面的时候用这个session来查数据库中的角色权限表，来判断该角色是否对该页面有各类操做的权限，固然某一个用户可能有好几个角色，那只须要多生成几个session来存储角色。这样作的好处是，在用户请求页面的时候判断比较容易。

1.1.3       资源选择总结

以上两种方案我选择的是以页面作为资源，主要是该系统对于数据库的操做不会像 HIS系统中那样对于数据库的操做那样多。

 

1.2       操做的描述

操做做为权限的核心之一，一般状况下包括了增删改查四种操做，关键的问题就在于如何在数据库中放映出这四种操做，这里仍然有两种方案。第一能够将这四种操做分别做为四个字段，用一个标志号来表示某主体是否具备某种操做，第二能够将这四个操做放在一个字段中用 4位二进制数表示，有某一操做就将具体的二进制数至1。这样作的好处，对于权限的操做看起来清晰明了，并且在具体查询角色权限表的时候也只用去查询一个字段，不用查询4个字段，操做上会减小很多。

 

1.3       对于角色和用户的简单描述

一个系统会有使用它的用户群，这个群里，确定会有不少具备对这个系统有着同等权力的

用户，因而将这些具备同等权力的用户分进某一个角色里。这样角色的数量确定会少于用户的数量，因而在之后的对庞大的用户资料进行的维护过程当中，能够将维护过程简化为用户角色管理与角色权限管理了。

 

1.4       本系统关于用户权限的基本数据表

通过以上分析，本系统所须要的用户管理模块所须要基本数据表就出来了

1.     用户信息表

2.     角色信息表

3.     用户角色关系表

4.     角色权限关系表

5.     权限对象说明表

以上的表格中，每张表都会用一个 ID号来做为该表的主键，其中用户和角色之间是多对多的关系，角色和权限之间也是多对多的关系。每一个表中具体字段暂且不表。

 

1．5          分析基本数据表

如今假设一个用户登录本系统且这个用户为合法用户，那么在他登录以后就能够根据用户角色表肯定该用户的角色（这个角色能够是一个角色，也能够是多个角色）；而后再根据角色权限表能够最终肯定该用户对那几个页面有某种具体的组合操做的权力。

狭义上的权限管理有了这 5张代表显已经足够了，可是咱们系统中存在一个功能树，树的节点是根据特定角色的权限来显示的，也就是说得加一个表功能树数据表，里面将页面对象与树的节点关联起来，固然并非全部的页面都会与某一个节点对应，也不是全部的节点必定要对应于一个页面，关于这个功能树的表的设计问题在层次数据库设计中本人已经作过度析，这里再也不详述。我采用的是父节点加子节点的设计方式。

那么在用户登录以后查找到了该用户对应的能操做的且存在于功能树结点中的页面，是否是就可以很顺利的显示出树呢？看来彷佛还有个小问题须要解决掉！

由于一个用户可能对应于几个角色，好几个角色中显然也有可能存在对同一个页面有相同的操做权力，若是该页面是功能树的一个节点，在用户登录以后要显示出树就得想办法去掉相同的节点。

在后台代码中咱们能够作到这一点，具体作法确定是把某用户所对应的全部角色的相关页面 id号放入一个datatable（ado.net中一个具体对象，至关于一张表格）,而后去掉重复的页面，即id号相同的页面，而后再从功能树数据表中去查找这些页面的父节点生成一颗功能树（具体生成方案两种作法，深度遍历和广度遍历，本章不作讨论）。固然咱们彻底能够在数据库中在作一张表为角色功能树节点对应表，这样直接经过查找这张表格找出不重复的节点来生成树，这样就减小了不少后台逻辑，带来了很大的方便。

1．6          权限管理模块总结

综上所述，本系统的权限管理模块一共有 7张数据表：

1. 用户信息表

2. 角色信息表

3. 用户角色关系表

4. 角色权限关系表

5. 权限对象说明表

6. 功能树数据表

7．角色功能树节点对应表

1． 7   对RBAC模型的分析

      NIST（The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）。

       上述几节主要是针对RBAC0来谈的，从实际运用和RBAC的其余3个模型咱们能够看出，在RBAC模型中对于角色的设计实际上是扩展性和灵活性都很强的，本系统中主要是涉及的角色种类并不太多，因此没有考虑角色的继承和限制关系。可是在多以为功能树节点的重复问题上，明显也能够用角色的继承和限制加以解决，可是因为功能树的节点并很少，全部节点一共也就不到二十个，因此并无采用RBAC3模型。

      固然该模型还有一些能够扩展的地方,在参阅了一些文章后，我以为如下几点能够更好的扩展RBAC模型。

       1.用户组受权功能。

          2.角色类型功能。这个功能并非很重要，创建一个类型表，每一个角色能够归属一个角色类型，便于表达方便，层次清晰，这个功能主要的做用在于表示层的显示上。

          3.角色优先功能。能够定义一个优先级别表，给每一个角色赋予优先级别，在处理角色的请求时，根据角色的优先级别排入链表里进行处理，链表里的角色请求能够根据优先级别的不一样动态调整，系统在处理角色请求时，每次都从队首取一个角色请求，再将队首指针指向下一个角色请求。

      4.角色生存周期功能。这个功能能够指定角色的生存时间，时间能够是用户指定的，也能够是根据某个条件来决定的。

        5.角色根据责任链动态变动权限功能。在一个责任链里，一个客户程序发出请求，这个请求将沿着责任链进行传递，责任链里的每一个结点将依次处理该请求，若是结点不能处理该请求，则将此请求转发到责任链的下一结点上；或者是，责任链中的每个结点都对该请求进行处理。在处理的过程当中，角色的权限将根据需求动态变化。

      6.角色根据状态动态变动权限功能。在应用程序中可能存在多种状态，好比在一个字处理程序中，当文件状态是只读时，和文件状态在可读可写时，它的功能是不同的，那么角色须要根据这种状态的变动而动态变动权限集，以便适应这种应用程序的要求。

固然了模型的存在并不意味着任何设计都必定要套用某种模型，只是说这个模型给了咱们一些很好的启示和一套已经比较成熟的方法论，毕竟这些只是工程模型并非数学或者物理定理，咱们再设计中实事求是的根据需求，合理的考虑一些扩展性结合这些模型确定能设计出一套知足咱们须要的系统。