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.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

        在我们系统中存在着 5种角色需要对不同的内容进行访问。

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.角色根据状态动态变更权限功能。在应用程序中可能存在多种状态，比如在一个字处理程序中，当文件状态是只读时，和文件状态在可读可写时，它的功能是不一样的，那么角色需要根据这种状态的变更而动态变更权限集，以便适应这种应用程序的要求。

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