基于RBAC的实验室预约系统中授权模块的研究与实现

qq_251836457

于 2024-09-18 07:30:00 发布

阅读量292

点赞数 11

文章标签：网络安全服务器

本文链接：https://blog.csdn.net/qq_41221322/article/details/142311292

版权

博主介绍：专注于Java vue .net php phython 小程序等诸多技术领域和毕业项目实战、企业信息化系统建设，从业十五余年开发设计教学工作

☆☆☆ 精彩专栏推荐订阅☆☆☆☆☆不然下次找不到哟
我的博客空间发布了1000+毕设题目方便大家学习使用
感兴趣的可以先收藏起来，还有大家在毕设选题，项目以及论文编写等相关问题都可以给我留言咨询，希望帮助更多的人
访问控制策略及模型

访问控制（Access Control）机制是在身份认证的基础上，通过某种途径显示地准许或限制访问能力及范围的一种方法。通过访问控制，可以限制对于关键资源的访问，防止非法用户的入侵或者因合法用户不慎操作所造成的破坏。

2.1访问控制策略

目前主流的访问控制技术有四种：自主访问控制（DAC）；强制访问控制（MAC）；基于角色的访问控制（RBAC）；基于任务的访问控制（TBAC）。

2.1.1自主访问控制

自主访问控制模型（Discretionary Access Control Model, DAC Model）

　　自主访问控制模型是根据自主访问控制策略建立的一种模型，允许合法用户以用户或用户组的身份访问策略规定的客体，同时阻止非授权用户访问客体，某些用户还可以自主地把自己所拥有的客体的访问权限授予其他用户。自主访问控制又称为任意访问控制。在实现上，首先要对用户的身份进行鉴别，然后就可以按照访问控制列表所赋予用户的权限，允许和限制用户使用客体的资源。主体控制权限的修改通常由特权用户（管理员）或是特权用户组实现。

　　任意访问控制对用户提供的这种灵活的数据访问方式，使得DAC广泛应用在商业和工业环境中；由于用户可以任意传递权限，那么，没有访问文件(File1)权限的用户A就能够从有访问权限的用户B那里得到访问权限或是直接获得文件；可见，DAC模型提供的安全防护还是相对比较低的，不能给系统提供充分的数据保护。

自主访问控制模型的特点是授权的实施主体（可以授权的主体、管理授权的客体、授权组）自主负责赋予和回收其他主体对客体资源的访问权限。DAC模型一般采用访问控制矩阵和访问控制列表来存放不同主体的访问控制信息，从而达到对主体访问权限限制的目的。

2.1.2 强制访问控制

强制访问控制模型（Mandatory Access Control Model， MAC Model）。

强制访问控制允许加载新的访问控制模块，并借此实施新的安全策略，其中一部分为一个很小的系统子集提供保护并加强特定的服务，其他的则对所有的主体和客体提供全面的标签式安全保护。定义中有关强制的部分源于如下事实，控制的实现由管理员和系统做出，而不像自主访问控制(DAC)那样是按照用户意愿进行的。

强制访问控制是系统独立于用户行为强制执行访问控制，它也提供了客体（数据对象）在主体（数据库用户）之间共享的控制，但强制访问控制机制是通过对主体和客体的安全级别进行比较来确定授予还是拒绝用户对资源的访问，从而防止对信息的非法和越权访问，保证信息的保密性。与自主访问控制不同的是，强制访问控制由安全管理员管理，由安全管理员根据一定的规则来设置，普通数据库用户不能改变他们的安全级别或对象的安全属性；自主访问控制尽管也作为系统安全策略的一部分，但主要由客体的拥有者管理。

2.1.3 基于角色的访问控制

基于角色的访问控制模型（Role-based Access Control Model，RBAC Model）。

RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。

Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）

What：权限针对的对象或资源（Resource、Class）。

How：具体的权限（Privilege,正向授权与负向授权）。

Operator：操作。表明对What的How操作。

Role：角色，一定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系。

Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承)，也可以包含用户，组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化，以满足不同层级权限控制的要求。

RBAC的关注点在于Role和User, Permission的关系。称为User assignment(UA)和Permission assignment(PA).关系的左右两边都是Many-to-Many关系。就是user可以有多个role，role可以包括多个user。

凡是用过RDBMS都知道，n:m 的关系需要一个中间表来保存两个表的关系。这UA和PA就相当于中间表。事实上，整个RBAC都是基于关系模型。

Session在RBAC中是比较隐晦的一个元素。标准上说：每个Session是一个映射，一个用户到多个role的映射。当一个用户激活他所有角色的一个子集的时候，建立一个session。每个Session和单个的user关联，并且每个User可以关联到一个或多个Session.

在RBAC系统中，User实际上是在扮演角色(Role)，可以用Actor来取代User，这个想法来自于Business Modeling With UML一书Actor-Role模式。考虑到多人可以有相同权限，RBAC引入了Group的概念。Group同样也看作是Actor。而User的概念就具象到一个人。

这里的Group和GBAC（Group-Based Access Control）中的Group（组）不同。GBAC多用于操作系统中。其中的Group直接和权限相关联，实际上RBAC也借鉴了一些GBAC的概念。

Group和User都和组织机构有关，但不是组织机构。二者在概念上是不同的。组织机构是物理存在的公司结构的抽象模型，包括部门，人，职位等等，而权限模型是对抽象概念描述。组织结构一般用Martin fowler的Party或责任模式来建模。

Party模式中的Person和User的关系，是每个Person可以对应到一个User，但可能不是所有的User都有对应的Person。Party中的部门Department或组织Organization，都可以对应到Group。反之Group未必对应一个实际的机构。例如，可以有副经理这个Group，这是多人有相同职责。

引入Group这个概念，除了用来解决多人相同角色问题外，还用以解决组织机构的另一种授权问题：例如，A部门的新闻我希望所有的A部门的人都能看。有了这样一个A部门对应的Group，就可直接授权给这个Group。

摘自（百度百科http://baike.baidu.com/view/73432.htm?fr=ala0_1_1）

2.1.4 基于任务的访问控制

TBAC是一种新的安全模型,从应用和企业层角度来解决安全问题(而非已往从系统的角度)。它采用“面向任务”的观点，从任务(活动)的角度来建立安全模型和实现安全机制，在任务处理的过程中提供动态实时的安全管理。在TBAC中，对象的访问权限控制并不是静止不变的，而是随着执行任务的上下文环境发生变化，这是我们称其为主动安全模型的原因。具体说来,TBAC有两点含义。首先，它是在工作流的环境考虑对信息的保护问题。在工作流环境中，每一步对数据的处理都与以前的处理相关，相应的访问控制也是这样，因而TBAC是一种上下文相关的访问控制模型。其次，它不仅能对不同工作流实行不同的访问控制策略，而且还能对同一工作流的不同任务实例实行不同的访问控制策略.这是“基于任务”的含义，所以TBAC又是一种基于实例(instance-based)的访问控制模型。最后，因为任务都有时效性，所以在基于任务的访问控制中，用户对于授予他的权限的使用也是有时效性的。

TBAC的基本概念

(1) 授权步(Authorization Step)。图2-1表示一个原始授权处理步,是指在一个工作流程中对处理对象的一次处理过程.它是访问控制所能控制的最小单元。授权步由受托人集(Trustee Set)和多个许可集(Permissions Set)组成，如图所示。其中，受托人集是可被授予执行授权步的用户的集合，许可集则是受托集的成员被授予授权步时拥有的访问许可。当授权步初始化以后，一个来自受托人集中的成员将被授予授权步，我们称这个受托人为授权步的执行委托者,该受托人执行授权步过程中所需许可的集合称为执行者许可集。在TBAC中,一个授权步的处理可以决定后续授权步对处理对象的操作许可，我们将这些许可称为激活许可集。执行者许可集和激活许可集一起称为授权步的保护态。

(2) 授权结构体(Authorization unit)。授权结构体是由一个或多个授权步组成的结构体，它们在逻辑上是联系在一起的。授权结构体分为一般授权结构体和原子授权结构体.一般授权结构体内的授权步依次执行，原子授权结构体内部的每个授权步紧密联系，其中任何一个授权步的失败都会导致整个结构体的失败。

(3) 任务(Task)。任务是工作流程中的一个逻辑单元。它是一个可区分的动作，可能与多个用户相关，也可能包括几个子任务。

(4) 依赖(Dependency)。依赖是指授权步之间或授权结构体之间的相互关系，包括顺序依赖、失败依赖、分权依赖和代理依赖。依赖反映了基于任务的访问控制的原则。

总之，一个工作流的业务流程由多个任务构成。而一个任务对应于一个授权结构体，每个授权结构体由特定的授权步组成。授权结构体之间以及授权步之间通过依赖关系联系在一起。

2.2 RBAC96模型族

RBAC96是一个模型族，其中包括RBAC0 - RBAC3四个概念性模型，如图2-2所示。基本模型RBAC0定义了完全支持RBAC概念的任何系统的最低需求。RBAC1 和 RBAC2两者都包含RBAC0，但各自都增加了独立的特点，它们被成为高级模型。在RBAC1 中增加了角色分级的概念，一个角色可以从另一个角色继承许可权。RBAC2 增加了一些限制，强调在RBAC的不同组件中在配置方面的一些限制。RBAC1和RBAC2之间是不可比的。RBAC3被成为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内。这些模型构成了RBAC96模型族，图2-3所示。

图2-2 RBAC96内各模型间的关系图

图2-3 RBAC96模型族

2.2.1基本模型RBAC0

RBAC0的模型结构包括用户（U）、角色（R）和许可权（P）的那个三类实体集合，此外还有一个会话集合（S）。

其中用户代表一个组织的职员；角色表示该组织内部的一项任务的功能或某个工作职务，它也表示该角色成员所拥有的权利和职责；许可权是用户对系统中各课题访问或操作的权利，客体是指系统中的数据客体和资源客体，例如，目录、文件、记录、端口、设备、内存或子网都是客体。

会话集中的每个会话表示一个用户可以对应多个角色（指向角色有两个箭头）。在某个会话的持续期间，一个用户可以同时激活多个角色，而该用户所获得的许可权是所有这些角色的所拥有许可权的并集。

每个用户可以同时打开多个回话，每个会话都可以在工作站屏幕上用一个窗口显示。每个会话可以有不同活动角色的组合。RBAC0的这一特点将受到最小特权原则的限制。如果一个用户在一次会话中激活所有角色的权利超过该用户被允许的权利，将受到最小权利原则的限制。

RBAC0模型由以下描述确定：

U、R、P、S分别表示用户集合、角色集合、许可权集合和会话集合。

PA P×R表示许可权与角色之间多对多的指派关系。

UA U×R表示用户与角色之间多对多的指派关系。

用户：S→U 每个会话si到单个用户user(si)的映射函数（常量代表会话的声明周期）。

角色：S→2R 每个会话si到角色子集roles(si) {r|user(si, r')∈UA}（能随时间改变）的映射函数，会话si有许可权Ur∈roles(si){p|(p,r')∈PA}。

在使用RBAC0模型时，应该要求每个许可权和每个用户至少应该被分配给一个角色。两个角色被分配的许可权完全一样是可能的，但仍是两个完全独立的角色，用户也有类似情况。角色可以适当的被看做是一种语义结构，是访问控制策略形式化的基础。

会话是由单个用户控制的，在模型中，用户可以创建会话，并有选择的激活用户角色的某些子集。在一个会话中的角色的激活是由用户来决断的，会话的终止也是由用户初始化的。RBAC0不允许由一个会话去创建另一个会话，会话只能由用户创建。

2.2.2角色分级模型RBAC1

RBAC1模型的特色是模型中的角色是分级的，不同级别的角色由不同的职责与权力，橘色的级别形成偏序关系。图2-4说明了角色等级的概念。在途中位置处于较高处的角色的等级高于较低位置角色的等级。利用角色的分级概念可以限制继承的范围（scope）。

图2-4 角色分级的概念

图中项目成员的等级最低，角色程序员和测试员的等级都高于角色项目成员，并都可以继承项目成员的权利；角色管理员具有最高的等级，它可以继承测试员和程序员的权利。为了满足实际组织中一个角色不完全继承另一个角色所有权利与责任的需求，模型中引入了私有角色的概念，如图中的测试员’和程序员’分别是测试员和程序员的私有uesr，它们可以分别继承测试员和程序员的某些专用权利。

显然，角色的等级关系具有自反性（自己可以继承自己）、传递性（A继承B，B继承C，则A继承C）和反对称性（A继承B，B继承A，则A=B），因此是偏序关系，下面是RBAC1的形式定义。

RBAC1由以下内容确定

U、R、P、S分别表示用户集合、角色集合、许可权集合和会话集合。

PA P×R表示许可权与角色之间多对多的指派关系。

UA U×R表示用户与角色之间多对多的指派关系。

RH R×R是对R的偏序关系，称为角色等级或角色支配关系，也可用≥符号表示。

用户：S→U 每个会话si到单个用户user(si)的映射函数（常量代表会话的声明周期）。

角色：S→2R 每个会话si到角色子集roles(si) {r|(r’≥r)[user(si, r')∈UA]}（能随时间改变）的映射函数，会话si有许可权Ur∈roles(si){p|(r''≤r)[(p,r'')∈PA]}。

2.2.3限制模型RBAC2

RBAC2模型是在RBAC0模型增加限制后形成的，它与RBAC1并不兼容。

RBAC2定义如下：

除了在RBAC0中增加了一些限制因素外，RBAC2未加改变的来自于RBAC0，这些限制是用于确定RBAC0中各个组件的值是否是可接受的，只有那些可接受的值才是允许的。

RBAC2中引入的限制可以施加到RBAC0模型中的所有关系和组件上。RBAC2中的一个基本限制时互斥角色的限制，互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。

2.2.4统一模型RBAC3

RBAC3把RBAC1和RBAC2组合在一起，提供角色的分级和继承的能力。但把这两种概念组合在一起也引起一些新问题。

限制也可以应用于角色等级本身，由于角色间的等级关系满足偏序关系，这种限制对模型而言是本质性的，可能会影响这种偏序关系。

两个或多个角色由可能被限制成没有公共的上级角色或下级角色。这些类型的限制在概念角色等级的权力已经被分散化的情况下是有用哦，但是安全主管却希望对所有允许这些改变的方法加以限制。

在限制和角色的等级之间也会产生敏感的相互影响。

RBAC的管理模型示于图2-5。图中的限制时针对所有成分的，图的下半部分是对上半部分关于管理角色AR和管理许可权AP与正规角色集R和许可权集P是分别不可相交的。这个模型显示，正规许可权只能分配给正规角色（RBAC模型中定义的角色），管理许可权只能分配给管理角色。

管理许可权AP有权改变组成RBAC0、RBAC1、RBAC2或RBAC3的所有成分，但正规许可权P不能。管理许可权与正规许可权不相交，即AP∩P=φ。管理许可权和正规许可权只能分别分配给管理角色AR和正规角色R，并且AR∩R=φ。

图2-5 管理模型示意图

管理模型示意图上半部可以对应RBAC0、RBAC1、RBAC2和RBAC3模型，类似地下半部可以对应ARBAC0、ARBAC1、ARBAC2和ARBAC3模型，此处的A表示“管理”。ARBAC0--ARBAC3形成了RBAC的管理模型族，成为ARBAC97。通常我们期望管理模型比RBAC模型本身简单一些，因此可以利用ARBAC0管理RBAC3，而不是用ARBAC3去管理RBAC0模型。

2.3 ARBAC97模型

在大型分布式信息系统中,角色的数量成千上万,由单一的系统安全员来管理这么多的角色及其权限是不现实的，Raving Sandhu 等在RBAC模型中就曾提出了角色的分布式管理的问题,但是没有详细谈到具体如何惊醒管理。之后,他们很快就提出了著名的分布式角色管理模型ARBAC97（Administrative RBAC97），从理论上给出了RBAC模型中角色管理的方法。

2.3.1 URA97

用户-角色指派。该组件涉及用户-指派关系UA的管理，该关系把用户与角色关联在一起。对该关系的修改权由管理角色控制，这样，管理角色中的成员有权管理正规角色中的成员关系。把一个用户指定为管理角色是在URA97以外完成的，并假定是由安全员完成的。

2.3.3 RRA97

角色-角色指派。为了便于对角色的管理，对角色又进行了分类。该组件涉及3类角色，它们是：

能力（Abilities）角色——进以许可权和其他能力做成成员的角色。

组（Groups）角色——仅以用户和其他组为成员的一类角色。

UP-角色——表示用户与许可权的角色，这类角色对其成员没有限制，成员可以使用户、角色、许可权、能力、组或其他UP-角色。

区别这三类模型的主要原因是可以应用不同的管理模型去建立不同类型角色之间的关系。区分的动因首先是对能力的考虑，能力是许可权的集合，可以把该集合中所有许可权作为一个单位指派给一个角色。类似的，组是用户的集合，可以把该集合中所有许可权作为一个单位指派给一个角色。组和能力角色都似乎可以划分等级的。

在一个UP-角色中，一个能力是否是其的一个成员是由UP-角色是否支配该能力决定的，如果支配就是，否则就不是。相反的，如果一个UP-角色被一个组角色支配，则这个组就是该UP-角色的成员。

符合各类组织机构的安全管理需求。RBAC模型支持最小特权原则、责任分离原则，这些原则是任何组织的管理工作都需要的。这就使得RBAC模型由广泛的应用前景。

RBAC模型支持数据抽象原则和继承概念。由于目前主流程序设计语言都支持面向对象技术，RBAC的这一特性便于在实际系统中应用实现。

模型中概念与实际系统紧密对应。RBAC模型中的角色、用户和许可权等概念都是实际系统实际存在的实体，便于设计者建立现存的或待建系统的RBAC模型。

RBAC模型仍是访问控制类模型，本质是对访问矩阵模型的扩充，能够很好的解决系统中主体对客气的访问控制访问权力的分配与控制问题，但模型没有提供信息流控制机制，还不能完全满足信息系统的全部安全需求。

2.4 RBAC模型的优缺点

基于角色的访问控制模型RBAC是目前主流的访问控制模型，它比传统的自主访问控制和强制访问控制更加优越，同时也提供了更高的灵活性和扩展性。基于角色的访问控制机制（RBAC）的最大优势在于其对授权管理的支持。常见的自主性访问控制和强制性访问控制方法都是由主体和访问权限直接发生联系，根据主体/客体的所属关系或主体/客体的安全级来决定主体是否具有对客体的访问权。但是，处于全球网络环境中的计算机或软件系统的访问用户往往种类繁多、数量巨大且动态变化，这使得采用传统的访问控制方法进行安全管理变得非常困难。RBAC 方法引入了角色这个中介，安全管理人员根据需要定义各种角色，并设定合适的访问权限，而用户根据其责任和资历再被指派为不同的角色。

RBAC具有以下优点：

易于理解。用户的特权绑定于角色，而对于安全管理员来说，对一个角色的权限分配和管理明显易于多个具体用户的权限分配及管理。
在用户机构或权限发生变动时，可以灵活的将该用户从一个角色移动到另一个角色来实现权限的协调转换，降低了管理的复杂度而且这些操作对用户完全透明。另外在组织机构发生只能性改变的时候，应用系统之学对于角色进行重行授权或取消某些权限，就可以使系统重新适应需要，这些都使的基于角色的访问控制策略的管理和访问方式具有无可比拟的灵活性和易操作性。
易于管理。在一个非RBAC中，用户或分组直接与权限绑定，在这种情况下如果有一个任务分别由n个用户（或分组）执行，且该任务存在于m对象的ACL中，对于这个任务的变更就必须修改n×m个ACL条目，而在RBAC系统中，有n个角色与该任务关联，该任务在关联与m个对象，管理员只需更改n+m个设置即可完成变更。
易于扩展。在绝大多数应用中，用户的数量远远大于角色的数量，安全官员了只需管理少量的角色就可实现对大量用户啊的管理，而对于传统的DAC来说，用户的增加将造成管理工作的急剧增多。
RBAC能适应范围广泛的安全策略。RBAC与具体的安全策略无关，所以能适应范围广泛的安全策略，包括DAC跟MAC，因而系统管理员能够按照不同的安全策略需要定义角色，适应不同应用领域的安全需要。

但是随着理论研究的不断深入以及应用领域中企业规模的不断扩大和商业业务的新特点的出现，RBAC模型也暴露出一些问题。

模型中安全策略的不平衡性。在RBAC模型中，研究的焦点一直集中在用户和角色所处的主体部分，其中包括角色与角色之间的继承关系，角色之间的约束关系——静态职责跟动态职责的分离；往往会使客体部分。实际上，访问控制是由访问的主体和客体同时组成的，一旦非法用户以某种方法获取访问控制权后，就可以对客体对象实施所有的操作，这在信息安全中是绝对不允许的。
权限泛滥，不具备时间性。RBAC模型的权限描述是应用级的，也就是说创建角色后即把权限分配给角色了。但是，实际操作中，权限是基于系统级的，按照最小特权的原则，角色只应拥有执行当前任务所必须的权限。
缺乏客体管理功能。企业规模的扩大和经营方式的改变使得客体数量日益庞大，人工管理客体的花销也日益增多，RBAC模型中没有提供基于角色的客体管理方法。
操作行为缺乏管理。RBAC模型中没有提供对操作行为的管理，但是和主体对象、客体对象一样，操作行为具有本身特有的安全特性，如果将其抽象出来概括成为操作角色，将会大大提高模型的可用性和灵活性。

实验室预约系统授权模块的设计

为了验证改良后的RBAC模型的可行性，本章在上述理论基础上，将其运用于实验室预约系统（Lab Reservation System， LRS）中。LRS是用于我校实验室的预约及管理。通过该模块的加入，实现了角色与资源、角色与操作的相结合，使得系统的安全性更加完善。该模块就大量用户的权限的分配和管理十分有成效，并能很好的运用于工作流系统中，同时该模块允许用户根据本单位自身的特点实施不同的安全策略。该模块可适用于中大型信息系统，实现企业级的安全管理。

3.1实验室预约系统项目介绍

3.1.1 项目背景

进入2000年之后的全国各大高校的教育模式中，由于教育信息化的程度逐步提高，传统的以教师为中心、面对面、“黑板+粉笔”为主导的教学模式受到很大的冲击。首先，信息技术进入传统的课堂，多媒体、网络等新技术手段辅助 “黑板+粉笔”的教学模式，使得课堂教学更加生动、学生认知程度不断加深。除此之外，信息化还带来了革命性的教学模式，大量网络教学的新模式，如网站教学、网络课堂、资源型学习、兴趣学习、互动学习等。这些新的教学模式与传统的模式相比，不仅形式新颖，还引进许多新的教学理念。信息化正在从各个方面影响高校的正规教育。

高校开放实验室的目的是为了培养学生的实验兴趣、提高实验室的利用率并减轻实验室管理人员的负担，从而提高教学质量。现如今校园网的普及和网络远程教育的发展，为基于web的实验室预约管理平台的实现提供了有利的条件。纵观国内高校的实验室管理现状，大致有四种情况：第一是有部分高校仍然采用人工管理手段，管理手段落后，严重阻碍了实验室的发展，不能适应高校信息化发展趋势；第二，有的高校实验室虽实现了计算机管理，但采用的是单机管理系统，虽使用了现代化的管理手段，但不能适应网络化管理的趋势，信息孤岛现象严重。第三，有的高校管理软件是基于局域网的，而且是为完成某一特定功能的，具有特殊性，不具普遍性，这样的软件缺点很明显，不易推广，系统采用Client／Server模式，不具备开放性，通用性。第四，有的高校也开发了基于WEB的实验室预约系统，但仍存在不能满足不同实验室的要求和实验教学的需要，信息孤岛现象仍未消除。

课题实现以实用为基本原则，解决实验室资源管理的需求为主要目标，考虑系统的通用性，充分体现人性化、个性化。课题实现主要功能模块有：

教师端：
1. 课程与总机时申请模块；
2. 机时预约模块；
3. 我的机时管理模块；
管理员端：

申请审核模块；
学期初始化模块，主要完成开学时间设置、学期长度设置、课时节次设置、学期实验室开放状态设置等功能；
基础数据初始化模块，主要完成实验室基本信息、校区、学院信息、实验工具、实验平台信息等基础数据的管理功能；
课程管理模块，主要完成课程信息的录入、课程信息的采集管理等功能；
实验室管理模块，主要完成特殊条件下的实验室开放、预约等管理功能；
数据备份与清理模块，主要完成每学期预约记录的备份与预约表等预约相关表的清理功能；
消息管理模块，主要完成利用站内信息机制实现基于消息的工作流管理机制；

公共端：

实验室可用余量实时监控与展现功能模块；
实验室一日预约详情查询与展示模块；
实验室一周预约概况查询与展示模块；
帮助系统模块。

3.1.2系统需求分析

针对LRS的项目背景和我校实验室预流程的分析可以总结出：

管理范围广。高校实验室的种类有很多，作为学生课后实践的场所，对学生的学业起着不可估量作用。同时为了满足各类用户对于使用不同实验室的需求，可以说是管理范围非常广泛。
人员组织结构复杂。用户不仅可以包括学校现代化教学中心的员工，还包括其他部门的工作人员、本校教师、本校学生、外校人员等。用户数目众多，但人事变更、职责变化却是十分频繁。

因此，如何使实验室预约系统用户获得相应的正常权限、避免不正当访问或者是非法操作，已经成为系统亟待解决的问题。

3.1.3 系统用例

该系统用户主要分为3类用户，对于不同用户具有不同权限对系统进行各类的访问，同时也具有相应的操作权限，如图3-1所示。

图3-1 系统用例图

3.2 权限管理模块的设计

如图3-2所示，当用户登录系统中，在通过系统中的Session可以找到该用户对映的角色集，而在角色集中将每个不同的角色具有的权限做了一个并集，从而使得该用户具有的具有一个整合的权限集，通过该权限集就使得该用户能合法的访问系统中对映于该用户的资源。期间，该模型还明确各类资源必须与用户的角色进行反向验证的过程，通过验证的角色就可以顺利访问。

图3-2 系统权限模型图

***3.3* *系统整体架构***

通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。如图3-3所示：

1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用系统时的所见所得。

2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。

3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增、删、改、查，图3-6所示。

根据前期的系统需求分析，将整个系统的功能按照“自顶向下”原则设计为12大关键组成模块，分别是：学期初始化模块、基础数据初始化模块、课程管理模块、实验室管理模块、站内消息模块、系统清理模块、审核模块、预约模块、余量监控与展现模块等。各个功能模块不仅能独立完成任务，同时也会通过接受特定参数服务于其他模块。比如基础数据模块负责基础信息的增删改查，但是它需要时刻服务于其他模块，因为其他模块在完成任务时，需要同时调用多个模块，而基础数据则作为主要数据模块。接着从设计开发的角度出发，从功能和需求入手，将设计与实现其中的预约管理模块功能作为本次设计开发的重点。图3-7展示了实验室预约系统的整体模块划分：

实验室预约平台中一个很重要的因素就是时间问题，系统中的每一个操作都会受到时间的限制，比如你登录系统的时间不在教学周内，系统就会提醒你学期还没有开始，无法登录。图3-8是学期初始化的子模块结构：

图中子设置节次模块是根据学校的不同，会有不同的节次设置，我们会因地制宜。开学时间的设置则是限制教师进行机时预约的一个因素，系统会自动为我们判定是否符合条件。而节假日的设定也是一个制约因素，在节假日期间是不允许预约的，系统将为教师自动屏蔽这些时间段。

在系统初始化时，必须初始化这些基本数据，否则系统不能运行，基础数据的初始化模块如图3-9所示：

接下来是一个比较重要的模块，就是实验室管理模块，通过这个模块我们可以管理所有我们刚才录入的基础数据，他们之间的关联以及实验室的状态，这是后台管理的核心任务，模块结构如图所示：

实验室预约系统中授权模块的实现

4.1平台及开发工具

该系统于Windows 7操作系统上开发，后台数据库使用的是Microsoft SQL Sever 2000，采用目前流行的Microsoft Visual Studio 2005作为开发工具。

4.2数据库的建立

4.2.1系统中表的建立

经过全面的系统分析，对系统模块进行多层次级别的划分之后，我们设计出了23张数据表，他们之间相互配合，表与表之间多层次关联，如图4-1所示：

图4-1 数据库结构图

4.2.2权限控制表的结构：

这23张数据表中的7张用于实现系统中权限的控制，如图4-2所示

1. 用户表：用于保存用户信息。

2. 角色表：用于保存角色信息。

3. 操作表：用于保存系统中所有操作模块信息。

4. 实验室表：用于保存实体模块信息。

5. 角色—操作表、用户—角色表、角色—实验室表：用于保存用户与角色、角色与操作、角色与实验室之间关系的表。

图4-2 权限控制关系图

Operation、Role、User三张数据表分别对应的是RBAC模型中的三个对象功能、角色、用户，关系表Role_Operation是把权限分配到角色，关系表User_Role是把角色分配到用户。

4.2.3存储过程的建立：

1、某个时间点上每个机房的总数、余数、开放状态

名称：proc_getLabTimePointUsedStatus

输入参数：@campusID @labTypeID @week @weekDay @periodID

输出参数：表（labName, campusName, labTypeName, max, used, remain, openStateName, whoUsed，labID）

2、开放设备数，已用设备数，开放机房数，已用机房数

名称：proc_getOpened_Used

输入参数：@campusID @labTypeID @week

输出参数：表（weekDay, periodID, labOpened , labUsed, equipOpened, equipUsed）

3、显示在用的校区

名称：proc_campusUsed

输入参数：无

输出参数：表（campusID, campusName）

4、特定校区在用机房类型

名称：proc_labTypeUsed

输入参数：@campusID

输出参数：表（labTypeID, labTypeName）

5、某天详细预约情况

名称：proc_getDetailsOfSomeday

输入参数：@week smallint,@weekDay smallint,@campusID int,@labTypeID int

输出参数：表（periodName, courseName, labName, reservationNumber, teacherName）

4.3 权限模块的建立

功能这点上的设计，也就是权限这一块，我们把粒度控制到页面这一层面，一个页面代表一个权限，这样一个页面就对应一个权限编号，清晰明了，利于我们后期权限的访问控制。因此我们的权限列表是固定的，根据系统的前期需求分析都已确定。

但对于角色Role、用户User可以在系统中自由增删改，通过将权限动态分配给角色以及将角色动态分配给用户来实现RBAC模型中动态授权这一过程。RBAC的关注点在于Role和User, Permission的关系。称为User assignment(UA)和Permission assignment(PA).关系的左右两边都是Many-to-Many关系。就是user可以有多个role，role可以包括多个user。

通过上面关于RBAC的实现过程我们可以看到，只要某一实体具备了某一个权限，就可以直接对某一资源进行操作。可以这样理解，RBAC只是实现了从实体到资源的单向可到达性，当我们登录系统时，系统告诉我们所拥有的权限并且为我们一一列出，我们只需要点击相应的链接就可以访问所需的资源，或者也可以说是相应的页面，我们无法访问权限列表以外的页面，这就是RBAC中体现的资源可达性。

在现代信息系统中，安全管理一直是设计的核心部分。而访问控制技术则是任何安全信息系统的重要环节，它的主要任务是保证资源不被非法使用和访问。RBAC访问控制就是规定了主体对客体访问的限制，并在身份识别的基础上，根据身份对提出资源访问的请求加以控制。RBAC访问控制决定了谁能够访问系统，能访问系统的何种资源以及如何使用这些资源。但这些都只是从User的角度分析，我们可以换位思考下，站在资源这个角度，等于就是来者不拒，就好比把每个资源都比喻成一个房间，用户拿着门卡，然后找到房间，不需要刷卡就可以直接进入房间，这显然不符合企业安全管理的要求。

我们在具体实现过程中，我们就在每个房间都安置了门禁，保证资源不被非法操作，考虑到具体项目的资源是以页面为独立个体，因此我们在每个页面都做了相应的控制语句，并且抽取出了一个公共类，让每个页面继承，具体代码如下：

public class CheckPermissions : System.Web.UI.Page

{

private OperationService operation = OperationService.GetInstance();

public CheckPermissions(){ }

protected void Page_Init(object sender, EventArgs e)

{

if (Session["LoginUserInfo"] == null)

{

Response.Redirect("../ErrorPage/ErrorPage.aspx");

}

protected bool IsAccess(int pageID)

{

bool isAccess = false;

IList<UserInfo> List= operation.GetUserList(pageID);

if (((LoginUserInfo)Session["LoginUserInfo"]).userID.Equals("super"))

{

isAccess = true;

}

else

{

foreach (UserInfo userInfo in List)

{

if (((LoginUserInfo)Session["LoginUserInfo"]).userID == userInfo.userID)

{

isAccess = true;

}

return isAccess;

}

首先，我们通过session判定用户是否已经登录，这是第一层判定，接下来是判定当前用户是否有权进入页面，通过IsAccess方法实现，可以看到，它的参数是pageID，需要不同的页面传入自身的ID，页面ID是和数据库中的权限表ID一一对应的，因此通过数据库中表与表的关联以及页面ID我们就可以轻松得到可以访问当前页面的用户列表，判定当前用户是否在列表中，从而也就达到了资源门禁的作用，用户无法再通过在地址栏中输入URL地址直接访问权限列表之外的资源了。

但在实际编程过程中考虑到权限数量之多，导致页面调用IsAccess方法时无法及时得到当前页面的权限编号，加重了编程的负担，因此定义了一个枚举静态类，代码如下：

public static class PageIDEnum

{

public enum pageID

{

AdminTermDateSetTermDateSet = 3,

AdminTermDateSetPeriod = 4,

AdminTermDateSetHolidaySet = 5,

AdminBasicDataSetCampus = 7,

AdminBasicDataSetCollege = 8,

AdminBasicDataSetLabType = 9,

AdminBasicDataSetTerrace = 10,