基于MVC架构的网站RBAC访问控制框架设计与实现_毕业设计(论文).doc

《基于MVC架构的网站RBAC访问控制框架设计与实现_毕业设计(论文).doc》由会员分享，可在线阅读，更多相关《基于MVC架构的网站RBAC访问控制框架设计与实现_毕业设计(论文).doc（50页珍藏版）》请在三一文库上搜索。

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

2、nctional 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

3、 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 ma

4、terial commercial system. Key words： MVC，RBAC，Access Control， Role，Permission. 4 目录 引引 言言 .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 第三章

5、第三章 设计实现设计实现 .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 A：英文原文：英文原文 35 附录附录 B B：中文翻译：中文翻译 41 1 引引 言言 本此毕业设

6、计将基于角色访问控制（Role-Based Access Control，RBAC） 作为研究课题，来实现一个企业内部管理系统中的权限管理部分。本文在 RBAC2001 建议标准的参考模型(下称 NIST RBAC 模型)的基础上，结合综合信息 管理系统以及软件系统集成的要求和特点，将 RBAC 访问控制框架应用到一个已 有的以 MVC 为架构建立而成的商务网站中去。 2 第一章第一章 课题背景课题背景 1.11.1 MVCMVC 概述概述 由于 Internet 的普及和网络技术的发展，大部分的企业或单位都拥有了自 己的 Web 站点。通过 Internet 或 Intranet，企业的管理

7、变得更加方便；企业 的信息发布变得更加便捷；企业的市场开拓变得更加简便。 企业网站大部分属于商务网站，企业通过利用 Web 系统，可以方便的发布 产品信息，管理订单信息，管理内部的诸如人事、员工薪酬信息等。从而在一 定程度上提高工作和管理效率，降低生产和管理成本。 现在用来建立 Web 站点的工具和编程语言主要有 ASP、PHP 和 JSP，使用的 设计模式是 MVC。MVC 作为构建网站系统的主流设计模式，有其自身的特点和优 势，具体表现在： （1）可以为一个模型在运行时同时建立和使用多个视图。变化-传播机制 可以确保所有相关的视图及时得到模型数据变化，从而使所有关联的视图和控 制器做到行为

8、同步。 （2） 视图与控制器的可接插性，允许更换视图和控制器对象，而且可以 根据需求动态的打开或关闭、甚至在运行期间进行对象替换。 （3） 模型的可移植性。因为模型是独立于视图的，所以可以把一个模型 独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新 的修改。 （4） 潜在的框架结构。可以基于此模型建立应用程序框架，不仅仅是用 在设计界面的设计中。 基于 MVC 模式建设 Web 站点系统，可以提高代码的重用性；可以提高代码 的可维护性；可以提高编写程序的效率。所以目前，越来越多的网站开始采用 MVC 模式来进行架构，但是在这其中，对于系统安全性问题的研究还进行的不 多。 在

9、构建 Web 系统之初，就要考虑系统的安全性，考虑用户对系统的访问控 制。通过访问控制，一方面只有合法的用户才可以安全、正确的使用系统，非 法的用户是无法登陆系统进行操作；的；另一方面合法的用户登录系统之后， 由于用户的类型不同，就会存在不用的用户在访问系统时具有不同的权限，比 如一个企业或公司的经理往往会比企业或公司的员工具有更多的权限和功能， 相应的用户登录系统之后，他们只能行使系统准许他们的权限。 3 纵观现在的 Web 系统，大都存在这样的问题：功能虽强大，但是却存在很 多的安全隐患。系统中的不同类型的用户对信息都具有相同的权限，可以任意 的修改和删除，这对于一些重要的信息是非常危险的

10、。对信息的科学管理，应 该是最高层的用户拥有对信息最高的权限，而处于底层或次底层的用户仅拥有 对信息最少的权限。此外，现在大部分 Web 系统中都缺少一个良好的访问控制 模块。在该模块中，可以为系统设定不同的用户，分配不同的权限。将系统中 的用户和系统中的权限关联起来，形成一种有效的系统安全管理。 综上所述，企业在构建自身的商务 Web 系统时，在考虑功能完整性和操作 简便性的同时，还应重点考虑构建的 Web 系统的安全性。只有在保证了安全性 的前提下，功能的完整性和操作的简便性才变得有意义。 1.21.2 RBACRBAC 模型概述模型概述 1.2.11.2.1 RBACRBAC 原理简介原

11、理简介 1992 年，美国国家标准与技术研究所（NIST）的 David Ferraiolo 和 Rick Kuhn 在综合了大量的实际研究之后，率先提出基于角色的访问控制模型 框架，并给出了 RBAC 模型的一种形式化定义。该模型第一次引入了角色的概 念并给出其基本语义，指出 RBAC 模型实现了最小权限原则（the least privilege）和职责分离原则（separation of duty） 。该模型中给出了一种集 中式管理的 RBAC 管理方案。1995 年他们以一种更直观的方式对该模型进行了 描述。 Ravi Sandhu 和他领导的位于 George Mason 大学的信息

12、安全技术实验室 （LIST）于 1996 年提出了著名的 RBAC96 模型，将传统的 RBAC 模型根据不同 需要拆分成四种嵌套的模型并给出形式化定义，极大的提高了系统灵活性和可 用性。1997 年他们更进一步，提出了一种分布式 RBAC 管理模型 DRBAC97，实 现了在 RBAC 模型基础上的分布式管理。这两个模型清晰的表征了 RBAC 概念并 且蕴涵了他人的工作，成为 RBAC 的经典模型。绝大多数基于角色的访问控制研 究都以这两个模型作为出发点。 在 RBAC 中，涉及到的基本概念如下： 用户（User）：系统的使用者。可以是人、计算机、机器人等，一般指人。 角色（Role）：一定

13、数量的权限的集合。权限分配的单位与载体，目的是 隔离用户与权限的逻辑关系。对应于组织中某一特定的职能岗位，代表特定的 4 任务范畴。角色的例子有：经理、采购员、推销员等。 权限（Permission）：表示对系统中的客体进行特定模式访问的操作许可， 例如对数据库系统中关系表的选择、插入、删除。在应用中，许可受到特定应 用逻辑的限制。 用户指派（User Assignment）：用户与角色之间的关系是多对多的关系。 用户指派指根据用户在组织中的职责和能力被赋为对应角色的成员。用户通过 被指派到角色间接获得访问资源的权限。 权限指派（Permission Assignment）：角色与权限之间的关

14、系也是多对多 的关系。权限指派指角色按其职责范围与一组操作权限相关联。进行权限分配 时，应遵循最小特权原则（the Least Privilege Rule） ，即分配的权限集既能 保证角色充分行使其职权，又不能超越职权范围。 角色激活（Role Activation）：是指用户从被授权的角色中选择一组角色 的过程。用户访问的时候实际具有的角色只包含激活后的角色，未激活的角色 在访问中不起作用。相对于静态的角色授权来说，角色激活是一种动态的过程， 提供了相当的灵活性。 会话（Session）：用户是一个静态的概念，会话则是一个动态的概念。一 次会话是用户的一个活跃进程，它代表用户与系统进行交互

15、，也叫主体 （Subject） 。用户与会话是一对多关系，一个用户可同时打开多个会话。 活跃角色集（ARS）：一个对话构成一个用户到多个角色的映射，即会话激 活了用户授权角色集的某个子集，这个子集被称为活动角色集，ARS 决定了本 次会话的许可集。 在 RBAC 中，它遵循如下的基本原则： 角色继承（Role Inheritance） 为了提高效率，避免相同权限的重复设置，RBAC 采用了“角色继承”的概 念，定义了这样的一些角色，他们有自己的属性，但可能还继承其他角色的属 性和权限。角色继承把角色组织起来，能够很自然地反映组织内部人员之间的 职权、责任关系。 最小权限原则（the Least

16、 Privilege Rule） 所谓最小权限原则是指：用户所拥有的权力不能超过他执行工作时所需的 权限。实现最小权限原则，需分清用户的工作内容，确定执行该项工作的最小 权限集，然后将用户限制在这些权限范围之内。在 RBAC 中，可以根据组织内的 规章制度、职员的分工等设计拥有不同权限的角色，只有角色需要执行的操作 才授权给角色。当一个主体预访问某资源时，如果该操作不在主体当前活跃角 色的授权操作之内，该访问将被拒绝。 职责分离（Separation of Duty） 5 对于某些特定的操作集，某一个角色或用户不可能同时独立地完成所有这 些操作。职责分离的概念包括：多路共享资源，用功能分解命名

17、互相区分的权 限集，对用户进行强制分类，允许层次性的分解权限。 1.2.21.2.2 RBACRBAC 适用性分析适用性分析 在 RBAC 模型中，一个用户通过用户授权获得一个或者几个角色，但角色不 能被同时激活；一个角色可以被同时授予多个用户；每个角色有一个或多个节 点，一个节点也可以被赋予多个角色；每个节点有一个或者多个功能，一个功 能可以被同时挂在不同的节点上，而节点可以有子节点，子节点也可以再有子 节点；一个功能对应一个或多个页面；一个页面有一个或多个操作。这样每个 用户登录时就可以根据角色得到一棵功能树从而使用系统中的资源。 为更真实的描述现实， RBAC 模型还有许多的控制机制。如

18、对 Web 页面多 维度和细粒度控制，对角色、功能、节点的静态限制和对角色的动态限制。对 页面的限制主要是限制用户在特定时间和特定地点所能看到的功能和所能进行 的操作。其他限制主要是在功能被赋予节点时、节点被赋予角色时和角色被赋 予用户时的限制。模型中有了这些限制才更完整、更真实地反应现实，从而使 实际模型细化的过程更加平滑，现实和计算机实现策略达到较好的融合。 页面是 Web 应用系统中最重要的元素，控制页面访问是整个系统安全的重 要条件。对页面的访问控制可以从时间和空间两个方面来进行，对页面功能和 数据的访问，可以通过用户登录后所带 session 中的信息进行控制。 时间约束分为一般时间

19、约束和周期时间约束两种。一般时间约束是指从一 个时间点持续到另一时间点之间可以访问某个页面，例如，企业商务系统中的 商品招标页面，它在某一指定时间段内开放，对这种约束可以在用户访问网页 的时候判断访问时间是否在允许范围内。周期时间约束是指对那些功能和数据 周期性开放的页面进行访问控制。空间约束主要是对用户在不同地方（网段） 登录所能看到的页面以及页面能提供的信息进行控制。例如，管理部门内部事 务所对应的页面通常对用户所在的访问位置有较严的限制。一般系统的高层用 户都有一个固定的 IP 段，就可以对那些重要的页面设置允许访问的 IP 范围来 达到对关键资源的保护。对页面的空间约束可以分成分网段、

20、分楼层、分房间、 分 IP 地址等不同层次的控制。 对页面功能和数据的访问需要知道用户的大概类型，主要包括管理员、部 门管理员、一般职工、游客（企业或单位以外的人员）等。用户登录后将用户 的类型保存到 session 中，在用户访问页面时就可以根据用户的不同类型，以 及他们对时间、空间等硬性约束的满足情况来显示相应的功能和数据。 6 通过了解 RBAC 模型的原理和 RBAC 模型中对访问控制的支持，我们可以看 出，RBAC 模型可以很好的应用于已有或将要开发的企业商务 Web 系统中。通过 在系统中使用 RBAC 模型，可以很好的解决如下的问题： 权限管理混乱的问题。通过在系统中增加角色这个

21、概念，很好的解决了这 个问题。在 RBAC 模型中，可以利用角色与系统中的所有权限关联，使得某种角 色具有某种特定的权限，从而在为用户设定好相应的角色之后，也就意味着得 到了相应的系统权限。 控制逻辑混乱的问题。通过使用 RBAC 模型，可以避免在系统中书写负责的 控制逻辑来进行访问控制。尤其当系统设计的用户和角色比较多时，单纯的依 靠代码进行访问控制将变得相当困难。 换句话说，RBAC 模型为我们提供了良好的访问控制支持。在企业商务 Web 系统中利用 RBAC 模型，可以简便、科学、清晰地进行访问控制，从而在一定程 度上提高了整个 Web 系统的安全性。 1.31.3 RBACRBAC 在

22、在 MVCMVC 中的应用现状中的应用现状 网站程序的安全是系统开发人员必须考虑的重要因素之一，因为这涉及到 网站的建设者、网站用户的诸多安全问题，如果不处理好，可能会给系统的使 用者和管理者带来严重问题。现在普遍在使用的安全措施有如下几种： （1）防止 SQL 注入 比如 URL、表单等提交信息时，通过一段防止 SQL 注入的过滤代码即可防 止出错信息暴露，或者通过转向，当系统出错时转到一个提示出错的页面等。 对于文本型输入，如果要进行检查，就得根据字段本身的性质进行。例如 如果是年龄，就得限定必须是数字，大小必须限定在一个范围之间，比如说 18-120 之间。对于用户名，应该建立一个集合，

23、这个集合里存放有被允许的字 符，或被禁止的字符。 （2）验证码技术 所谓验证码，就是将一串随机产生的数字或符号，生成一幅图片，图片里 加上一些干扰象素，由用户肉眼识别其中的验证码信息，输入表单提交网站验 证，验证成功后才能使用某项功能。放在会员注册、留言本等所有客户端提交 信息的页面，要提交信息，必须要输入正确的验证码，从而可以防止不法用户 用软件频繁注册，频繁发送不良信息等。 （3）MD5 加密技术 MD5 的全称是 Message-Digest Algorithm 5，当用户登录的时候，系统把 用户输入的密码计算成 MD5 值，然后再去和保存在文件系统中的 MD5 值进行比 7 较，进而确

24、定输入的密码是否正确。通过这样的步骤，系统在并不知道用户密 码的明码的情况下就可以确定用户登录系统的合法性。这不但可以避免用户的 密码被具有系统管理员权限的用户知道，而且还在一定程度上增加了密码被破 解的难度。 （4）数据备份 一般采用数据库系统自动定时备份、定时自动删除几天以前的数据等，即 可完成数据的备份功能。而图片、文件一般是不能自动备份，需要手工操作， 所以我们必须要定期手工对网站的图片、文件进行备份操作。 访问控制技术是由美国国防部（Department of Defense, DoD）资助的研 究和开发成果演变而来的。这一研究导致两种基本类型访问控制的产生：自主 访问控制（Disc

25、retionary Access Control, DAC）和强制访问控制 （Mandatory Access Control, MAC） 。最初的研究和应用主要是为了防止机密 信息被未经授权者访问，近期的应用主要是把这些策略应用到为商业领域。 自主访问控制，允许把访问控制权的授予和取消留给个体用户来判断。为 没有访问控制权的个体用户授予和废除许可。自主访问控制机制允许用户被授 权和取消访问其控制之下的任何客体（object） ，换句话说，用户就是他们控制 下的客体的拥有者。然而，对于多数组织来说，最终用户对所访问的信息没有 拥有权。对于这些组织，公司或代理机构是事实上的系统客体和处理他们的程

26、 序的拥有者。访问优先权受组织控制，而且也常常基于雇员功能而不是数据所 有权。 强制访问控制，在美国国防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定义如下：“一种限制访问客体的手段，它以包含在这些 客体中的信息敏感性和访问这些敏感性信息的主体的正式授权信息（如清除） 为基础” 。 强制访问控制是“强加”给访问主体的，即系统强制主体服从访问控制政 策。强制访问控制（MAC）的主要特征是对所有主体及其所控制的客体（例如： 进程、文件、段、设备）实施强制访问控制。为这些主体及客体指定敏感标记， 这些标记是等级分类和非等级类别的组

27、合，它们是实施强制访问控制的依据。 系统通过比较主体和客体的敏感标记来决定一个主体是否能够访问某个客体。 用户的程序不能改变他自己及任何其它客体的敏感标记，从而系统可以防止特 洛伊木马的攻击。 强制访问控制一般与自主访问控制结合使用，并且实施一些附加的、更强 的访问限制。一个主体只有通过了自主与强制性访问限制检查后，才能访问某 个客体。用户可以利用自主访问控制来防范其它用户对自己客体的攻击，由于 用户不能直接改变强制访问控制属性，所以强制访问控制提供了一个不可逾越 8 的、更强的安全保护层以防止其它用户偶然或故意地滥用自主访问控制。 以上访问控制策略对于处理一些无需保密但又敏感的信息的政府和行

28、业组 织的需求并不是特别的适合。在这样的环境下，安全目标支持产生于现有法律、 道德规范、规章、或一般惯例的高端组织策略。这些环境通常需要控制个体行 为的能力，而不仅仅是如何根据信息的敏感性为其设置标签从而访问这一信息 的个人能力。 就基于角色访问控制而言，访问决策是基于角色的，个体用户是某个组织 的一部分。用户具有指派的角色（比如医生、护士、出纳、经理） 。定义角色的 过程应该基于对组织运转的彻底分析，应该包括来自一个组织中更广范围用户 的输入。 访问权按角色名分组，资源的使用受限于授权给假定关联角色的个体。例 如，在一个商务管理系统中，经理角色可能包括人事管理、工资管理、分配项 目等；而一般

29、员工的角色则被限制为仅能浏览自己的一些信息，如基本信息、 工资信息和工程项目信息等。 基于角色的访问控制模型 RBAC 比传统的自主访问控制和强制访问控制更优 越，同时也提供了更高的灵活性和扩展性。RBAC 访问控制模型实现了用户与访 问权限的逻辑分离，减少了授权管理的复杂性，降低了管理开销和管理的复杂 度。对于现在规模日益增大的基于 MVC 架构的商务信息管理系统来说，采用 RBAC 访问控制模型的访问控制模块将会起到越来越大的作用。 综上分析，控制访问角色的运用是一种开发和加强企业特殊安全策略，进 行安全管理过程流程化的有效手段。运用 RBAC 模型可以很好的解决 Web 系统中 提出的访

30、问控制要求，而 DAC、MAC 等等访问控制技术由于各种各样的局限性和 特性，都不是 WEB 系统下实现访问控制的最好选择。 从目前的应用现状来看，以 MVC 为架构而建成的 WEB 网站特别是商务网站 的数量较为庞大，而由于其自身的管理特性，对安全措施的要求也越来越高， 这就要求我们找到一种更为有效的权限管理方法去适应网站对访问控制技术的 要求。而 RBAC 作为一种科学、合理、灵活、成熟的访问控制技术，最适合于在 WEB 环境下使用，所以如何使它应用到那些基于 MVC 架构的网站中去，会是一 个具有相当研究价值的课题。 9 第二章第二章 系统框架分析与设计系统框架分析与设计 2.12.1

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

32、门管理模块：针对公司内部的所有的部门进行管理，用户可以方便地添 加部门、修改部门信息、删除某一部门和查询某一部门的信息。 员工管理模块：针对公司内部的所有的员工进行管理，用户可以方便地添 加员工信息、修改员工信息、删除某一员工信息和查询某一部门的所有员工信 息。 工程项目管理模块：针对公司的工程项目进行管理，用户可以方便地添加 工程项目信息、修改某一工程项目的信息、删除某工程项目的信息和查询某一 工程项目信息。 员工工资管理模块：针对公司内部的所有的员工的薪酬进行管理，用户可 以方便地添加工资信息、修改工资信息、删除工资信息和查询某一员工在某段 时间内的所有工资信息。 信息查看模块：针对公司员

33、工设计的功能模块，通过该模块员工可以方便 10 的查看自己的基本信息，工资信息以及所负责的工程项目信息。 系统功能管理模块：用户可以通过该模块管理系统中涉及到的所有功能， 可以添加、删除和修改。 系统用户管理模块：用户可以通过该模块管理系统中涉及到的所有用户， 可以添加、删除和修改。 系统角色管理模块：用户可以通过该模块为系统中的不同的用户设置不同 的权限，并能够修改某一用户所赋予的权限。 在上述的商务系统中，在安全性上一般会有如下的要求： 能够很好的实现访问控制。在一个企业中，存在着很多种不同的用户，如 经理、董事长、一般职工，系统维护人员等。当所有的用户面对同一个系统时， 就应该做到用户之

34、间要有区分，即进入系统后不同的用户只能实行自身拥有的 权限，不可以越权。 部分信息的保密。公司中存在着一些决定企业利益的信息，这些信息只能 由公司的管理人员来查看和管理，任何非法的侵入都有可能造成不良的后果。 现代主流的 Web 系统的体系架构设计基于 J2EE 平台上的 MVC 设计模式，应 用 Struts 框架，采用 B/S 模式，具体的架构设计如图 2-2 所示。 Action Action Action HTML JSPs Struts Tags(JSTL) Style Sheet Action Servlet Request Processor Web Container Cont

35、rollerModel 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）：运行在用户机器的浏览器中，处理与用户的交 互。 表现层（Pr

36、esentation Layer）：运行在 J2EE Web 容器中，产生系统的表 现逻辑，处理用户的请求并做出响应；整个 Web 层建立在 Struts 框架基础上， 其中 View 由 HTML 和 JSP 页面组成，其数据表示是 ActionForm Oracle 9i Browser 11 Bean；Controller 由 ActionServlet 组合 Struts-config.xml 和 Action 类组 成；而 Model 则交由业务逻辑层来实现。 业务逻辑层（Business Layer）：运行在 J2EE Web 容器中，完成系统的业 务需求，为 Web 层提供所需的

37、业务方法，由 JavaBean 构成系统的 Business Objects（BO） ，并使用 DAO 模式把数据访问封装起来，以供在其他应用层中统 一调用。 数据源层（Database Layer）：即数据库层，存放系统的应用数据，系统 采用 Oracle9i 作为数据库服务器。 系统的架构可以表示为 JSP+Struts+Database。使用这种架构一方面便于 系统的开发和管理；另一方面，层与层之间的开发几乎是完全独立的，从而降 低了数据在各层之间的耦合性，提高了系统的可维护性和可扩展性。此外，系 统是由 Java 来开发实现的，Java 的跨平台特性实现了系统的可移植性。 2.22.2

38、 RBACRBAC 模型的建立模型的建立 根据上述商务系统对安全性的需求，通过在 Web 系统中使用 RBAC 模型可以 很好的满足各项需求。 RBAC 的核心思想就是：根据用户需求，给用户分派各种角色，为不同的角 色分配各种权限，用户通过自己所属的角色获得操作权限许可。其核心模型如 图 2-3 所示。 图 2-3 RBAC 模型 核心 RBAC 模型的组成部分是： Users：用户集u1，u2，u3 ，un； Roles：角色集r1，r2，r3， ，rn； OPS：操作集op1，op2，op3，opn 12 OBJ：客体集obj1，obj2，obj3，objn P= OPS X 0BJ：权限

39、集是不同客体上不同操作的描述pl，p2，p3，. ，pn RolesUsersUA* ：用户角色分配关系：多对多； Assigned-users：，角色与用户的映射，将一个角色与一组 用户相映射； ：权限-角色分配关系，多对多； Assigned privileges ： ，角色与权限的映射，将一个角色与 一组权限相映射； Session ：会话集s1，s2，s3，sn User_sessions ：，用户与会话的映射，将一个用户与一个 会话相映射； Session_roles ：，会话与角色的映射，将一个会话与一 组角色相映射； Avail_session_privilege ：，在一次会话

40、中一个用户允许 的权限； 用户：不仅指人，也可以指机器，网络或智能代理。 角色：管理员依据安全策略划分出来的操作集合，表示该角色成员所授予 的职权和责任。 客体：指系统需要保护的资源。 权限：对系统中的客体进行特定存取的许可。权限是与客体紧密相关的， 不同的系统，其权限规定是不同的，既可以指网络的应用，如对某个子网的访 问权限，也可以指对数据库的表单等的访问。权限的粒度大小取决于实际系统 的定义。 会话：为了对系统资源进行操作，用户需要建立会话，每个会话将一个用 户与他所对应的角色集中的一部分建立映射关系，这一角色子集成为被会话激 活的角色，在这次会话中，用户可以执行的操作就是该会话激活的角色

41、对应的 权限所允许的操作。 上述 RBAC 模型是 RBAC 核心模型，此模型保留了 RBAC 的最小特征集，是每 个 RBAC 系统都需要的元素。 13 2.32.3 RBACRBAC 模型在模型在 MVCMVC 网站中的应用网站中的应用 由需求分析可知，需要为企业内部网管理系统设计一个用户权限管理的功 能模块，从而达到对用户权限进行管理的目的。当今的大型的信息管理系统都 具有功能复杂，用户众多的特点，如果仍采用传统的权限管理方式，直接将权 限分配给用户，对具有相同权限的一类用户同样的授权操作将被重复很多遍， 一旦用户工作岗位有变化，则对其权限的调整将非常复杂，而基于 RBAC 模型的 权限

42、控制方法则大大简化了这种授权管理的复杂度，降低了系统管理的开销。 RBAC 模型描述了一种良好的访问控制方法和原理。通过在商务 Web 系统中 使用 RBAC 模型可以方便、科学、合理地进行访问控制，有了良好的访问控制， 不同的用户在使用系统的时候仅能访问自身被赋予的权限，用户之间不能越权 访问，从而保证了信息的安全性和一致性，从而提高了系统的安全性。 通过以下几个步骤，可以将 RBAC 模型应用在 MVC 网站中。 （1）建立功能的概念。功能，即操作。在系统中，如对员工的添加、删除 和修改的操作，都可以描述为一个功能。 （2）建立权限节点的概念。权限节点，顾名思义，它对应着一个或一组功 能操

43、作菜单，表示了该节点可以进行系统操作的范围。 （3）建立角色的概念。将角色与节点对应起来，一个角色可以对应多个节 点，一个节点也可以对应多个角色，这是一个多对多的关系。角色与节点对应 好之后，也就意味着角色与某一个或某一组功能操作菜单建立了关联。系统中 存在不同类型的用户，也即不同的用户隶属于不同的角色。 （4）将系统的用户和角色关联起来。一旦一个用户被设置了某个角色，那 么也就意味着该用户具有了某些权限。具有了某些权限，也就意味着拥有了某 些功能（对系统的操作和管理） 。 举例来说，假设系统中存在两个权限节点 1 和 2，两个角色 A 和 B，用户有 甲（经理）和乙（部门经理） ，很显然甲和

44、乙在登陆系统后应该具有不同的权限， 甲可以管理整个公司的信息，而乙仅能管理所在部门的信息。这时，设定权限 节点 1 下包含了管理整个公司信息的所有功能，权限节点 2 下包含了管理某个 部门信息的所有功能；将角色 A 与节点 1 进行关联，将角色 B 与节点 2 进行关 联。最后，将用户甲的角色设定为角色 A，用户乙的角色设定为角色 B。在用户 甲和乙登陆系统后，就会看到自己所具有的功能菜单，其他用户的功能菜单是 非可见的，从而实现了访问控制。 简言之，通过在系统中设置功能、权限和角色的概念，就可以在系统中实 现 RBAC 模型，并让它很好地为 Web 系统提供访问控制功能。 14 第三章第三章

45、 设计实现设计实现 3.13.1 RBACRBAC 框架实现框架实现 数据存储是个非常重要的功能需求。系统中很多的地方都要存储数据，并 且其格式要求也不相同，数据量也差别较大。良好的设计不但能减少因数据保 存不当造成的对系统的损害，而且能显著地提高系统的性能。在考虑数据存储 方案时，有三种可行的选择，分别是文件方式、数据库方式、LDAP 方式，这三 种方式都有各自的优缺点。文件方式的好处在于简单直观，存取速度最快，但 不够安全，在 RBAC 的早期版本中，我们采用的就是文件方式。LDAP 方式可以 保证数据的安全和完整性，但使用不方便，普及程度也不高；数据库方式是业 界比较认可的主流存储方案，

46、而且现在的数据库技术也比较成熟，是较为理想 的选择。有鉴于此，我们在系统中采用了数据库方式作为本系统数据存储方案。 以下为数据存储的表结构： 1、P_YHB 用户表 用于记录用户基本信息。如表 3-1 所示。 表表 3-13-1 用户表用户表 编号列名类型长度说明约束 1*YHIDVARCHAR8用户 ID 2YHMCVARCHAR20用户名称 3YHMMVARCHAR25用户密码 4SSBMVARCHAR5用户所属部门 5YHMSVARCHAR500用户描述 2、P_JSB 角色表 记录和角色相关和信息。如表 3-2 所示。 表表 3-23-2 角色表角色表 编号列名类型长度说明约束 1*J

47、SIDVARCHAR5角色 ID 2JSMCVARCHAR50角色名称 3JSMSVARCHAR200角色描述可为空 15 4JSXYHZDSNUMBER10此角色下的用户最大数可为空 5JSLXVARCHAR1角色类型 3、P_YHJSB 用户角色表 用于记录用户角色指派的内容，即记录每个角色被赋予了哪些用户。如表 3-3 所示。 表表 3-33-3 用户角色表用户角色表 编号列名类型长度说明约束 1*YHIDVARCHAR8用户 ID1.1 2*JSIDVARCHAR5角色 ID2.1 4、P_GNB 功能表 存放权限，一条记录就是一个权限，一个权限指的是一个用户可以使用的 一个功能项，在

48、表中记录了该权限对应的主 URL。如表 3-4 所示。 表表 3-43-4 功能表功能表 编号列名类型长度说明约束 1*GNIDVARCHAR5功能 ID 2GNMCVARCHAR50功能名称 3GNMSVARCHAR500功能描述可为空 4ZURLVARCHAR200主 URL 5 CZVARCHAR 1 操作（只读、读写、执 行） 5、P_JSJDB 角色节点表 记录权限角色指派的内容，即记录每个角色所拥有的权限信息。如表 3-5 所示。 表表 3-53-5 角色节点表角色节点表 编号列名类型长度说明约束 1*JSIDVARCHAR5角色 ID2.1 2*JDIDVARCHAR5节点 ID

49、6.1 6、P_JDB 节点表 记录每个节点信息。如表 3-6 所示。 表表 3-63-6 节点表节点表 编号列名类型长度说明约束 1*JDIDVARCHAR5节点 ID 16 2.JDMCVARCHAR50节点名称 3.FJDIDVARCHAR5父节点 ID 4JDMSVARCHAR500节点描述 5JDNXHVARCHAR2节点内序号 7、P_JDGNB 节点表 记录每个节点所包含的权限信息。如表 3-7 所示。 表表 3-73-7 节点功能表节点功能表 编号列名类型长度说明约束 1IDVARCHAR1节点层次 2*GNIDVARCHAR5节点 ID 3*JDIDVARCHAR5节点 ID 8、P_DEPARTMENT 企业部门表 记录每个企业部门所包含的部门信息。如表 3-8 所示。 表表 3-83-8 企业企业部门表部门表 编号列名类型长度说明约束 1*DEPBMVARCHAR3部门编号 2DEPMCVARCHAR100部门名称 3DEPLXDHVARCHAR25部门联系电话 4 DEPMANAG ER VARCHAR 8 部门负责人 9、P_PROJECT 企业工程项目表 记录每个工程项目所包含的工程项目信息。如表 3-9 所示。 表表 3-93-9 企业工程项目表企业工程项目表 编号列名类型长度说明约束