本科毕业设计--基于mvc架构的网站rbac访问控制框架设计与实现.doc

基于MVC架构的网站RBAC访问控制框架设计与实现

毕业设计论文

摘　要
一个实际的商务网站系统除了需要关注于功能需求之外，还需要考虑很多非功能性需求，安全性就是其中一个非常重要的方面。访问控制是几乎所有的应用系统都不可缺少的一部分。本文从MVC架构商务管理系统的需求出发，首先分析了几种访问控制的优缺点，在此基础上提出了利用RBAC模型来进行系统的访问控制。并将其用于某一具体的商务系统中，给出了实现过程。
关键词：MVC、RBAC、访问控制、角色、权限。

46

Abstract
When functional requirements are chiefly paid attention to by people in a commercial application system, many nonfunctional requirements are also taken into account. Security is one of the most important aspects of the nonfunctional requirements. Access control almost is a necessary part in all application systems. This paper analyses the requirements of comprehensive commercial information management system based on MVC. It analyses the merits and demerits among the common access controls, and proposes process access control based on RBAC model. Finally, it describes how to realize the model in a material commercial system.

Key words： MVC，RBAC，Access Control， Role，Permission.

目录
引　言 1
第一章 课题背景 2
1.1 MVC概述 2
1.2 RBAC模型概述 3
1.2.1 RBAC原理简介 3
1.2.2 RBAC适用性分析 5
1.3 RBAC在MVC中的应用现状 6
第二章 系统框架分析与设计 9
2.1 基于MVC架构的Web系统 9
2.2 RBAC模型的建立 11
2.3 RBAC模型在MVC网站中的应用 12
第三章 设计实现 14
3.1 RBAC框架实现 14
3.2 RBAC模型在系统中的实现 17
3.2.1 系统功能模块的实现 17
3.2.2 系统权限模块的实现 21
3.2.3 系统角色模块的实现 23
3.2.4 为用户设置角色 25
3.2.5 用户权限功能树的生成 26
第四章 系统测试 29
4.1 系统测试 29
4.1.1 测试环境 29
4.1.2 测试方案 29
4.2 总结与展望 32
4.3 致谢 33
参考文献 34
附录A：英文原文 35
附录B：中文翻译 41

引　言
本此毕业设计将基于角色访问控制（Role-Based Access Control，RBAC）作为研究课题，来实现一个企业内部管理系统中的权限管理部分。本文在RBAC2001建议标准的参考模型(下称NIST RBAC模型)的基础上，结合综合信息管理系统以及软件系统集成的要求和特点，将RBAC访问控制框架应用到一个已有的以MVC为架构建立而成的商务网站中去。
第一章 课题背景
1.1 MVC概述
由于Internet的普及和网络技术的发展，大部分的企业或单位都拥有了自己的Web站点。通过Internet或Intranet，企业的管理变得更加方便；企业的信息发布变得更加便捷；企业的市场开拓变得更加简便。
企业网站大部分属于商务网站，企业通过利用Web系统，可以方便的发布产品信息，管理订单信息，管理内部的诸如人事、员工薪酬信息等。从而在一定程度上提高工作和管理效率，降低生产和管理成本。
现在用来建立Web站点的工具和编程语言主要有ASP、PHP和JSP，使用的设计模式是MVC。MVC作为构建网站系统的主流设计模式，有其自身的特点和优势，具体表现在：
（1）可以为一个模型在运行时同时建立和使用多个视图。变化-传播机制可以确保所有相关的视图及时得到模型数据变化，从而使所有关联的视图和控制器做到行为同步。
（2） 视图与控制器的可接插性，允许更换视图和控制器对象，而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。
（3） 模型的可移植性。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。
（4） 潜在的框架结构。可以基于此模型建立应用程序框架，不仅仅是用在设计界面的设计中。
基于MVC模式建设Web站点系统，可以提高代码的重用性；可以提高代码的可维护性；可以提高编写程序的效率。所以目前，越来越多的网站开始采用MVC模式来进行架构，但是在这其中，对于系统安全性问题的研究还进行的不多。
在构建Web系统之初，就要考虑系统的安全性，考虑用户对系统的访问控制。通过访问控制，一方面只有合法的用户才可以安全、正确的使用系统，非法的用户是无法登陆系统进行操作；的；另一方面合法的用户登录系统之后，由于用户的类型不同，就会存在不用的用户在访问系统时具有不同的权限，比如一个企业或公司的经理往往会比企业或公司的员工具有更多的权限和功能，相应的用户登录系统之后，他们只能行使系统准许他们的权限。
纵观现在的Web系统，大都存在这样的问题：功能虽强大，但是却存在很多的安全隐患。系统中的不同类型的用户对信息都具有相同的权限，可以任意的修改和删除，这对于一些重要的信息是非常危险的。对信息的科学管理，应该是最高层的用户拥有对信息最高的权限，而处于底层或次底层的用户仅拥有对信息最少的权限。此外，现在大部分Web系统中都缺少一个良好的访问控制模块。在该模块中，可以为系统设定不同的用户，分配不同的权限。将系统中的用户和系统中的权限关联起来，形成一种有效的系统安全管理。
综上所述，企业在构建自身的商务Web系统时，在考虑功能完整性和操作简便性的同时，还应重点考虑构建的Web系统的安全性。只有在保证了安全性的前提下，功能的完整性和操作的简便性才变得有意义。

1.2 RBAC模型概述
1.2.1 RBAC原理简介
1992 年，美国国家标准与技术研究所（NIST）的David Ferraiolo 和Rick Kuhn在综合了大量的实际研究之后，率先提出基于角色的访问控制模型框架，并给出了RBAC 模型的一种形式化定义。该模型第一次引入了角色的概念并给出其基本语义，指出RBAC 模型实现了最小权限原则（the least privilege）和职责分离原则（separation of duty）。该模型中给出了一种集中式管理的RBAC管理方案。1995年他们以一种更直观的方式对该模型进行了描述。
Ravi Sandhu和他领导的位于George Mason大学的信息安全技术实验室（LIST）于1996 年提出了著名的RBAC96模型，将传统的RBAC模型根据不同需要拆分成四种嵌套的模型并给出形式化定义，极大的提高了系统灵活性和可用性。1997 年他们更进一步，提出了一种分布式RBAC管理模型DRBAC97，实现了在RBAC模型基础上的分布式管理。这两个模型清晰的表征了RBAC概念并且蕴涵了他人的工作，成为RBAC的经典模型。绝大多数基于角色的访问控制研究都以这两个模型作为出发点。
在RBAC中，涉及到的基本概念如下：
用户（User）：系统的使用者。可以是人、计算机、机器人等，一般指人。
角色（Role）：一定数量的权限的集合。权限分配的单位与载体，目的是隔离用户与权限的逻辑关系。对应于组织中某一特定的职能岗位，代表特定的任务范畴。角色的例子有：经理、采购员、推销员等。
权限（Permission）：表示对系统中的客体进行特定模式访问的操作许可，例如对数据库系统中关系表的选择、插入、删除。在应用中，许可受到特定应用逻辑的限制。
用户指派（User Assignment）：用户与角色之间的关系是多对多的关系。用户指派指根据用户在组织中的职责和能力被赋为对应角色的成员。用户通过被指派到角色间接获得访问资源的权限。
权限指派（Permission Assignment）：角色与权限之间的关系也是多对多的关系。权限指派指角色按其职责范围与一组操作权限相关联。进行权限分配时，应遵循最小特权原则（the Least Privilege Rule），即分配的权限集既能保证角色充分行使其职权，又不能超越职权范围。
角色激活（Role Activation）：是指用户从被授权的角色中选择一组角色的过程。用户访问的时候实际具有的角色只包含激活后的角色，未激活的角色在访问中不起作用。相对于静态的角色授权来说，角色激活是一种动态的过程，提供了相当的灵活性。
会话（Session）：用户是一个静态的概念，会话则是一个动态的概念。一次会话是用户的一个活跃进程，它代表用户与系统进行交互，也叫主体（Subject）。用户与会话是一对多关系，一个用户可同时打开多个会话。
活跃角色集（ARS）：一个对话构成一个用户到多个角色的映射，即会话激活了用户授权角色集的某个子集，这个子集被称为活动角色集，ARS决定了本次会话的许可集。
在RBAC中，它遵循如下的基本原则：
角色继承（Role Inheritance）
为了提高效率，避免相同权限的重复设置，RBAC采用了“角色继承”的概念，定义了这样的一些角色，他们有自己的属性，但可能还继承其他角色的属性和权限。角色继承把角色组织起来，能够很自然地反映组织内部人员之间的职权、责任关系。
最小权限原则（the Least Privilege Rule）
所谓最小权限原则是指：用户所拥有的权力不能超过他执行工作时所需的权限。实现最小权限原则，需分清用户的工作内容，确定执行该项工作的最小权限集，然后将用户限制在这些权限范围之内。在RBAC中，可以根据组织内的规章制度、职员的分工等设计拥有不同权限的角色，只有角色需要执行的操作才授权给角色。当一个主体预访问某资源时，如果该操作不在主体当前活跃角色的授权操作之内，该访问将被拒绝。
职责分离（Separation of Duty）
对于某些特定的操作集，某一个角色或用户不可能同时独立地完成所有这些操作。职责分离的概念包括：多路共享资源，用功能分解命名互相区分的权限集，对用户进行强制分类，允许层次性的分解权限。
1.2.2 RBAC适用性分析
在RBAC模型中，一个用户通过用户授权获得一个或者几个角色，但角色不能被同时激活；一个角色可以被同时授予多个用户；每个角色有一个或多个节点，一个节点也可以被赋予多个角色；每个节点有一个或者多个功能，一个功能可以被同时挂在不同的节点上，而节点可以有子节点，子节点也可以再有子节点；一个功能对应一个或多个页面；一个页面有一个或多个操作。这样每个用户登录时就可以根据角色得到一棵功能树从而使用系统中的资源。
为更真实的描述现实， RBAC模型还有许多的控制机制。如对Web页面多维度和细粒度控制，对角色、功能、节点的静态限制和对角色的动态限制。对页面的限制主要是限制用户在特定时间和特定地点所能看到的功能和所能进行的操作。其他限制主要是在功能被赋予节点时、节点被赋予角色时和角色被赋予用户时的限制。模型中有了这些限制才更完整、更真实地反应现实，从而使实际模型细化的过程更加平滑，现实和计算机实现策略达到较好的融合。
页面是Web应用系统中最重要的元素，控制页面访问是整个系统安全的重要条件。对页面的访问控制可以从时间和空间两个方面来进行，对页面功能和数据的访问，可以通过用户登录后所带session中的信息进行控制。
时间约束分为一般时间约束和周期时间约束两种。一般时间约束是指从一个时间点持续到另一时间点之间可以访问某个页面，例如，企业商务系统中的商品招标页面，它在某一指定时间段内开放，对这种约束可以在用户访问网页的时候判断访问时间是否在允许范围内。周期时间约束是指对那些功能和数据周期性开放的页面进行访问控制。空间约束主要是对用户在不同地方（网段）登录所能看到的页面以及页面能提供的信息进行控制。例如，管理部门内部事务所对应的页面通常对用户所在的访问位置有较严的限制。一般系统的高层用户都有一个固定的IP段，就可以对那些重要的页面设置允许访问的IP范围来达到对关键资源的保护。对页面的空间约束可以分成分网段、分楼层、分房间、分IP地址等不同层次的控制。
对页面功能和数据的访问需要知道用户的大概类型，主要包括管理员、部门管理员、一般职工、游客（企业或单位以外的人员）等。用户登录后将用户的类型保存到session中，在用户访问页面时就可以根据用户的不同类型，以及他们对时间、空间等硬性约束的满足情况来显示相应的功能和数据。
通过了解RBAC模型的原理和RBAC模型中对访问控制的支持，我们可以看出，RBAC模型可以很好的应用于已有或将要开发的企业商务Web系统中。通过在系统中使用RBAC模型，可以很好的解决如下的问题：
权限管理混乱的问题。通过在系统中增加角色这个概念，很好的解决了这个问题。在RBAC模型中，可以利用角色与系统中的所有权限关联，使得某种角色具有某种特定的权限，从而在为用户设定好相应的角色之后，也就意味着得到了相应的系统权限。
控制逻辑混乱的问题。通过使用RBAC模型，可以避免在系统中书写负责的控制逻辑来进行访问控制。尤其当系统设计的用户和角色比较多时，单纯的依靠代码进行访问控制将变得相当困难。
换句话说，RBAC模型为我们提供了良好的访问控制支持。在企业商务Web系统中利用RBAC模型，可以简便、科学、清晰地进行访问控制，从而在一定程度上提高了整个Web系统的安全性。
1.3 RBAC在MVC中的应用现状
网站程序的安全是系统开发人员必须考虑的重要因素之一，因为这涉及到网站的建设者、网站用户的诸多安全问题，如果不处理好，可能会给系统的使用者和管理者带来严重问题。现在普遍在使用的安全措施有如下几种：
（1）防止SQL注入
比如URL、表单等提交信息时，通过一段防止SQL注入的过滤代码即可防止出错信息暴露，或者通过转向，当系统出错时转到一个提示出错的页面等。
对于文本型输入，如果要进行检查，就得根据字段本身的性质进行。例如如果是年龄，就得限定必须是数字，大小必须限定在一个范围之间，比如说18-120之间。对于用户名，应该建立一个集合，这个集合里存放有被允许的字符，或被禁止的字符。
（2）验证码技术
所谓验证码，就是将一串随机产生的数字或符号，生成一幅图片，图片里加上一些干扰象素，由用户肉眼识别其中的验证码信息，输入表单提交网站验证，验证成功后才能使用某项功能。放在会员注册、留言本等所有客户端提交信息的页面，要提交信息，必须要输入正确的验证码，从而可以防止不法用户用软件频繁注册，频繁发送不良信息等。
（3）MD5加密技术
MD5的全称是Message-Digest Algorithm 5，当用户登录的时候，系统把用户输入的密码计算成MD5值，然后再去和保存在文件系统中的MD5值进行比较，进而确定输入的密码是否正确。通过这样的步骤，系统在并不知道用户密码的明码的情况下就可以确定用户登录系统的合法性。这不但可以避免用户的密码被具有系统管理员权限的用户知道，而且还在一定程度上增加了密码被破解的难度。
（4）数据备份
一般采用数据库系统自动定时备份、定时自动删除几天以前的数据等，即可完成数据的备份功能。而图片、文件一般是不能自动备份，需要手工操作，所以我们必须要定期手工对网站的图片、文件进行备份操作。
访问控制技术是由美国国防部（Department of Defense, DoD）资助的研究和开发成果演变而来的。这一研究导致两种基本类型访问控制的产生：自主访问控制（Discretionary Access Control, DAC）和强制访问控制（Mandatory Access Control, MAC）。最初的研究和应用主要是为了防止机密信息被未经授权者访问，近期的应用主要是把这些策略应用到为商业领域。
自主访问控制，允许把访问控制权的授予和取消留给个体用户来判断。为没有访问控制权的个体用户授予和废除许可。自主访问控制机制允许用户被授权和取消访问其控制之下的任何客体（object），换句话说，用户就是他们控制下的客体的拥有者。然而，对于多数组织来说，最终用户对所访问的信息没有拥有权。对于这些组织，公司或代理机构是事实上的系统客体和处理他们的程序的拥有者。访问优先权受组织控制，而且也常常基于雇员功能而不是数据所有权。
强制访问控制，在美国国防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定义如下：“一种限制访问客体的手段，它以包含在这些客体中的信息敏感性和访问这些敏感性信息的主体的正式授权信息（如清除）为基础”。
强制访问控制是“强加”给访问主体的，即系统强制主体服从访问控制政策。强制访问控制（MAC）的主要特征是对所有主体及其所控制的客体（例如：进程、文件、段、设备）实施强制访问控制。为这些主体及客体指定敏感标记，这些标记是等级分类和非等级类别的组合，它们是实施强制访问控制的依据。系统通过比较主体和客体的敏感标记来决定一个主体是否能够访问某个客体。用户的程序不能改变他自己及任何其它客体的敏感标记，从而系统可以防止特洛伊木马的攻击。
强制访问控制一般与自主访问控制结合使用，并且实施一些附加的、更强的访问限制。一个主体只有通过了自主与强制性访问限制检查后，才能访问某个客体。用户可以利用自主访问控制来防范其它用户对自己客体的攻击，由于用户不能直接改变强制访问控制属性，所以强制访问控制提供了一个不可逾越的、更强的安全保护层以防止其它用户偶然或故意地滥用自主访问控制。
以上访问控制策略对于处理一些无需保密但又敏感的信息的政府和行业组织的需求并不是特别的适合。在这样的环境下，安全目标支持产生于现有法律、道德规范、规章、或一般惯例的高端组织策略。这些环境通常需要控制个体行为的能力，而不仅仅是如何根据信息的敏感性为其设置标签从而访问这一信息的个人能力。
就基于角色访问控制而言，访问决策是基于角色的，个体用户是某个组织的一部分。用户具有指派的角色（比如医生、护士、出纳、经理）。定义角色的过程应该基于对组织运转的彻底分析，应该包括来自一个组织中更广范围用户的输入。
访问权按角色名分组，资源的使用受限于授权给假定关联角色的个体。例如，在一个商务管理系统中，经理角色可能包括人事管理、工资管理、分配项目等；而一般员工的角色则被限制为仅能浏览自己的一些信息，如基本信息、工资信息和工程项目信息等。
基于角色的访问控制模型RBAC比传统的自主访问控制和强制访问控制更优越，同时也提供了更高的灵活性和扩展性。RBAC访问控制模型实现了用户与访问权限的逻辑分离，减少了授权管理的复杂性，降低了管理开销和管理的复杂度。对于现在规模日益增大的基于MVC架构的商务信息管理系统来说，采用RBAC访问控制模型的访问控制模块将会起到越来越大的作用。
综上分析，控制访问角色的运用是一种开发和加强企业特殊安全策略，进行安全管理过程流程化的有效手段。运用RBAC模型可以很好的解决Web系统中提出的访问控制要求，而DAC、MAC等等访问控制技术由于各种各样的局限性和特性，都不是WEB系统下实现访问控制的最好选择。
从目前的应用现状来看，以MVC为架构而建成的WEB网站特别是商务网站的数量较为庞大，而由于其自身的管理特性，对安全措施的要求也越来越高，这就要求我们找到一种更为有效的权限管理方法去适应网站对访问控制技术的要求。而RBAC作为一种科学、合理、灵活、成熟的访问控制技术，最适合于在WEB环境下使用，所以如何使它应用到那些基于MVC架构的网站中去，会是一个具有相当研究价值的课题。

第二章 系统框架分析与设计
2.1 基于MVC架构的Web系统
在当前开发的商务系统中，一般都会包括部门管理功能模块，员工管理功能模块，工程项目管理功能模块和员工薪水管理功能模块，以及包括针对员工使用的信息查看模块。先下面给出一个已经设计完善的基于MVC架构的WEB网站，系统的功能模块图如图2-1所示。
系统的功能模块
部门管理模块
员工管理模块
工程项目管理模块
员工工资管理模块
信息查看模块
系统功能管理模块
系统用户管理模块
系统角色管理模块

图2-1 系统功能模块图
部门管理模块：针对公司内部的所有的部门进行管理，用户可以方便地添加部门、修改部门信息、删除某一部门和查询某一部门的信息。
员工管理模块：针对公司内部的所有的员工进行管理，用户可以方便地添加员工信息、修改员工信息、删除某一员工信息和查询某一部门的所有员工信息。
工程项目管理模块：针对公司的工程项目进行管理，用户可以方便地添加工程项目信息、修改某一工程项目的信息、删除某工程项目的信息和查询某一工程项目信息。
员工工资管理模块：针对公司内部的所有的员工的薪酬进行管理，用户可以方便地添加工资信息、修改工资信息、删除工资信息和查询某一员工在某段时间内的所有工资信息。
信息查看模块：针对公司员工设计的功能模块，通过该模块员工可以方便的查看自己的基本信息，工资信息以及所负责的工程项目信息。
系统功能管理模块：用户可以通过该模块管理系统中涉及到的所有功能，可以添加、删除和修改。
系统用户管理模块：用户可以通过该模块管理系统中涉及到的所有用户，可以添加、删除和修改。
系统角色管理模块：用户可以通过该模块为系统中的不同的用户设置不同的权限，并能够修改某一用户所赋予的权限。
在上述的商务系统中，在安全性上一般会有如下的要求：
能够很好的实现访问控制。在一个企业中，存在着很多种不同的用户，如经理、董事长、一般职工，系统维护人员等。当所有的用户面对同一个系统时，就应该做到用户之间要有区分，即进入系统后不同的用户只能实行自身拥有的权限，不可以越权。
部分信息的保密。公司中存在着一些决定企业利益的信息，这些信息只能由公司的管理人员来查看和管理，任何非法的侵入都有可能造成不良的后果。
现代主流的Web系统的体系架构设计基于J2EE平台上的MVC设计模式，应用Struts框架，采用B/S模式，具体的架构设计如图2-2所示。
Oracle 9i
Browser
Action
Action
Action
HTML
JSPs
Struts Tags(JSTL)
Style Sheet
Action
Servlet
Request
Processor
Web Container
Controller
Model
Presentation
Layer
Http Response
Http Request
BusinessManagement_MessagerResources.properties

Struts-config.xml

View

Java
Bean
Business
Objects
Database Layer
Web.xml

Business Layer
Client
Layer

图2-2 商务管理系统架构图
在图2-2中，系统架构可以细分为以下4个层次：
客户层（Client Layer）：运行在用户机器的浏览器中，处理与用户的交互。
表现层（Presentation Layer）：运行在J2EE Web容器中，产生系统的表现逻辑，处理用户的请求并做出响应；整个Web层建立在Struts框架基础上，其中View由HTML和JSP页面组成，其数据表示是ActionForm Bean；Controller由ActionServlet组合Struts-config.xml和Action类组成；而Model则交由业务逻辑层来实现。
业务逻辑层（Business Layer）：运行在J2EE Web容器中，完成系统的业务需求，为Web层提供所需的业务方法，由JavaBean构成系统的Business Objects（BO），并使用DAO模式把数据访问封装起来，以供在其他应用层中统一调用。
数据源层（Database Layer）：即数据库层，存放系统的应用数据，系统采用Oracle9i作为数据库服务器。
系统的架构可以表示为JSP+Struts+Database。使用这种架构一方面便于系统的开发和管理；另一方面，层与层之间的开发几乎是完全独立的，从而降低了数据在各层之间的耦合性，提高了系统的可维护性和可扩展性。此外，系统是由Java来开发实现的，Java的跨平台特性实现了系统的可移植性。
2.2 RBAC模型的建立
根据上述商务系统对安全性的需求，通过在Web系统中使用RBAC模型可以很好的满足各项需求。
RBAC的核心思想就是：根据用户需求，给用户分派各种角色，为不同的角色分配各种权限，用户通过自己所属的角色获得操作权限许可。其核心模型如图2-3所示。

图2-3 RBAC模型
核心RBAC模型的组成部分是：
Users：用户集{u1，u2，u3…… ，un}；
Roles：角色集{r1，r2，r3，…… ，rn}；
OPS：操作集{op1，op2，op3，……，opn}
OBJ：客体集{obj1，obj2，obj3，……，objn}
P= OPS X 0BJ：权限集是不同客体上不同操作的描述{pl，p2，p3，.⋯ ，pn}
：用户—角色分配关系：多对多；
Assigned-users：，角色与用户的映射，将一个角色与一组用户相映射；
：权限-角色分配关系，多对多；
Assigned privileges ： ，角色与权限的映射，将一个角色与一组权限相映射；
Session ：会话集{s1，s2，s3，……，sn }
User_sessions ：，用户与会话的映射，将一个用户与一个会话相映射；
Session_roles ：，会话与角色的映射，将一个会话与一组角色相映射；
Avail_session_privilege ：，在一次会话中一个用户允许的权限；
用户：不仅指人，也可以指机器，网络或智能代理。
角色：管理员依据安全策略划分出来的操作集合，表示该角色成员所授予的职权和责任。
客体：指系统需要保护的资源。
权限：对系统中的客体进行特定存取的许可。权限是与客体紧密相关的，不同的系统，其权限规定是不同的，既可以指网络的应用，如对某个子网的访问权限，也可以指对数据库的表单等的访问。权限的粒度大小取决于实际系统的定义。
会话：为了对系统资源进行操作，用户需要建立会话，每个会话将一个用户与他所对应的角色集中的一部分建立映射关系，这一角色子集成为被会话激活的角色，在这次会话中，用户可以执行的操作就是该会话激活的角色对应的权限所允许的操作。
上述RBAC模型是RBAC核心模型，此模型保留了RBAC的最小特征集，是每个RBAC系统都需要的元素。
2.3 RBAC模型在MVC网站中的应用
由需求分析可知，需要为企业内部网管理系统设计一个用户权限管理的功能模块，从而达到对用户权限进行管理的目的。当今的大型的信息管理系统都具有功能复杂，用户众多的特点，如果仍采用传统的权限管理方式，直接将权限分配给用户，对具有相同权限的一类用户同样的授权操作将被重复很多遍，一旦用户工作岗位有变化，则对其权限的调整将非常复杂，而基于RBAC模型的权限控制方法则大大简化了这种授权管理的复杂度，降低了系统管理的开销。
RBAC模型描述了一种良好的访问控制方法和原理。通过在商务Web系统中使用RBAC模型可以方便、科学、合理地进行访问控制，有了良好的访问控制，不同的用户在使用系统的时候仅能访问自身被赋予的权限，用户之间不能越权访问，从而保证了信息的安全性和一致性，从而提高了系统的安全性。
通过以下几个步骤，可以将RBAC模型应用在MVC网站中。
（1）建立功能的概念。功能，即操作。在系统中，如对员工的添加、删除和修改的操作，都可以描述为一个功能。
（2）建立权限节点的概念。权限节点，顾名思义，它对应着一个或一组功能操作菜单，表示了该节点可以进行系统操作的范围。
（3）建立角色的概念。将角色与节点对应起来，一个角色可以对应多个节点，一个节点也可以对应多个角色，这是一个多对多的关系。角色与节点对应好之后，也就意味着角色与某一个或某一组功能操作菜单建立了关联。系统中存在不同类型的用户，也即不同的用户隶属于不同的角色。
（4）将系统的用户和角色关联起来。一旦一个用户被设置了某个角色，那么也就意味着该用户具有了某些权限。具有了某些权限，也就意味着拥有了某些功能（对系统的操作和管理）。
举例来说，假设系统中存在两个权限节点1和2，两个角色A和B，用户有甲（经理）和乙（部门经理），很显然甲和乙在登陆系统后应该具有不同的权限，甲可以管理整个公司的信息，而乙仅能管理所在部门的信息。这时，设定权限节点1下包含了管理整个公司信息的所有功能，权限节点2下包含了管理某个部门信息的所有功能；将角色A与节点1进行关联，将角色B与节点2进行关联。最后，将用户甲的角色设定为角色A，用户乙的角色设定为角色B。在用户甲和乙登陆系统后，就会看到自己所具有的功能菜单，其他用户的功能菜单是非可见的，从而实现了访问控制。
简言之，通过在系统中设置功能、权限和角色的概念，就可以在系统中实现RBAC模型，并让它很好地为Web系统提供访问控制功能。

第三章 设计实现
3.1 RBAC框架实现
数据存储是个非常重要的功能需求。系统中很多的地方都要存储数据，并且其格式要求也不相同，数据量也差别较大。良好的设计不但能减少因数据保存不当造成的对系统的损害，而且能显著地提高系统的性能。在考虑数据存储方案时，有三种可行的选择，分别是文件方式、数据库方式、LDAP方式，这三种方式都有各自的优缺点。文件方式的好处在于简单直观，存取速度最快，但不够安全，在 RBAC 的早期版本中，我们采用的就是文件方式。LDAP方式可以保证数据的安全和完整性，但使用不方便，普及程度也不高；数据库方式是业界比较认可的主流存储方案，而且现在的数据库技术也比较成熟，是较为理想的选择。有鉴于此，我们在系统中采用了数据库方式作为本系统数据存储方案。以下为数据存储的表结构：
1、P_YHB 用户表
用于记录用户基本信息。如表3-1所示。
表3-1 用户表
编号
列名
类型
长度
说明
约束
1
*YHID
VARCHAR
8
用户ID

2
YHMC
VARCHAR
20
用户名称

3
YHMM
VARCHAR
25
用户密码

4
SSBM
VARCHAR
5
用户所属部门

5
YHMS
VARCHAR
500
用户描述

2、P_JSB 角色表
记录和角色相关和信息。如表3-2所示。
表3-2 角色表
编号
列名
类型
长度
说明
约束
1
*JSID
VARCHAR
5
角色ID

2
JSMC
VARCHAR
50
角色名称

3
JSMS
VARCHAR
200
角色描述
可为空
4
JSXYHZDS
NUMBER
10
此角色下的用户最大数
可为空
5
JSLX
VARCHAR
1
角色类型

3、P_YHJSB 用户角色表
用于记录用户角色指派的内容，即记录每个角色被赋予了哪些用户。如表3-3所示。
表3-3 用户角色表
编号
列名
类型
长度
说明
约束
1
*YHID
VARCHAR
8
用户ID
1.1
2
*JSID
VARCHAR
5
角色ID
2.1
4、P_GNB 功能表
存放权限，一条记录就是一个权限，一个权限指的是一个用户可以使用的一个功能项，在表中记录了该权限对应的主URL。如表3-4所示。
表3-4 功能表
编号
列名
类型
长度
说明
约束
1
*GNID
VARCHAR
5
功能ID

2
GNMC
VARCHAR
50
功能名称

3
GNMS
VARCHAR
500
功能描述
可为空
4
ZURL
VARCHAR
200
主URL

5
CZ
VARCHAR
1
操作（只读、读写、执行）

5、P_JSJDB角色节点表
记录权限角色指派的内容，即记录每个角色所拥有的权限信息。如表3-5所示。
表3-5 角色节点表
编号
列名
类型
长度
说明
约束
1
*JSID
VARCHAR
5
角色ID
2.1
2
*JDID
VARCHAR
5
节点ID
6.1
6、P_JDB节点表
记录每个节点信息。如表3-6所示。
表3-6 节点表
编号
列名
类型
长度
说明
约束
1
*JDID
VARCHAR
5
节点ID

2.
JDMC
VARCHAR
50
节点名称

3.
FJDID
VARCHAR
5
父节点ID

4
JDMS
VARCHAR
500
节点描述

5
JDNXH
VARCHAR
2
节点内序号

7、P_JDGNB节点表
记录每个节点所包含的权限信息。如表3-7所示。
表3-7 节点功能表
编号
列名
类型
长度
说明
约束
1
ID
VARCHAR
1
节点层次

2
*GNID
VARCHAR
5
节点ID

3
*JDID
VARCHAR
5
节点ID

8、P_DEPARTMENT企业部门表
记录每个企业部门所包含的部门信息。如表3-8所示。
表3-8 企业部门表
编号
列名
类型
长度
说明
约束
1
*DEPBM
VARCHAR
3
部门编号

2
DEPMC
VARCHAR
100
部门名称

3
DEPLXDH
VARCHAR
25
部门联系电话

4
DEPMANAGER
VARCHAR
8
部门负责人

9、P_PROJECT企业工程项目表
记录每个工程项目所包含的工程项目信息。如表3-9所示。
表3-9 企业工程项目表
编号
列名
类型
长度
说明
约束
1
*PRJBH
VARCHAR
20
项目编号

2
PRJNAME
VARCHAR
100
项目名称

3
PRJMAN
VARCHAR
20
项目负责人
11.1
4
PRJMONEY
VARCHAR
40
项目资金

5
PRJDATE
DATE

立项日期

10、P_SALARY企业员工工资表
记录每个企业员工的工资信息。如表3-10所示。
表3-10 企业员工工资表
编号
列名
类型
长度
说明
约束
1
*ID
NUMBER

工资帐单序号

2