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

基于MVC架构的网站RBAC访问控制框架设计与实现_毕业设计(论文) 基于MVC架构的网站RBAC访问控制框架设计与实现 毕业设计论文 1 摘 要 一个实际的商务网站系统除了需要关注于功能需求之外，还需要考虑很多非功能性需求，安全性就是其中一个非常重要的方面。访问控制是几乎所有的应用系统都不可缺少的一部分。本文从MVC架构商务管理系统的需求出发，首先分析了几种访问控制的优缺点，在此基础上提出了利用RBAC模型来进行系统的访问控制。并将其用于某一具体的商务系统中，给出了实现过程。 关键词:MVC、RBAC、访问控制、角色、权限。 2 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. 3 目录 引 言 ............................................................................................................................................... 1 第一章 课题背景 .............................................................................................................................. 2 1.1 MVC概述 ................................................................................................................................. 2 1.2 RBAC模型概述........................................................................................................................ 3 1.2.1 RBAC原理简介 ............................................................................................................... 3 ............................................................................................................ 5 1.2.2 RBAC适用性分析 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 4 引 言 本此毕业设计将基于角色访问控制(Role-Based Access Control，RBAC)作为研究课题，来实现一个企业内部管理系统中的权限管理部分。本文在RBAC2001建议的参考模型(下称NIST RBAC模型)的基础上，结合综合信息管理系统以及软件系统集成的要求和特点，将RBAC访问控制框架应用到一个已有的以MVC为架构建立而成的商务网站中去。 1 第一章 课题背景 1.1 MVC概述 由于Internet的普及和网络技术的发展，大部分的企业或单位都拥有了自己的Web站点。通过Internet或Intranet，企业的管理变得更加方便;企业的信息发布变得更加便捷;企业的市场开拓变得更加简便。 企业网站大部分属于商务网站，企业通过利用Web系统，可以方便的发布产品信息，管理订单信息，管理内部的诸如人事、员工薪酬信息等。从而在一定程度上提高工作和管理效率，降低生产和管理成本。 现在用来建立Web站点的工具和编程语言主要有ASP、PHP和JSP，使用的设计模式是MVC。MVC作为构建网站系统的主流设计模式，有其自身的特点和优势，具体表现在: (1)可以为一个模型在运行时同时建立和使用多个视图。变化-传播机制可以确保所有相关的视图及时得到模型数据变化，从而使所有关联的视图和控制器做到行为同步。 (2) 视图与控制器的可接插性，允许更换视图和控制器对象，而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。 (3) 模型的可移植性。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。 (4) 潜在的框架结构。可以基于此模型建立应用程序框架，不仅仅是用在设计界面的设计中。 基于MVC模式建设Web站点系统，可以提高代码的重用性;可以提高代码的可维护性;可以提高编写程序的效率。所以目前，越来越多的网站开始采用MVC模式来进行架构，但是在这其中，对于系统安全性问题的研究还进行的不多。 在构建Web系统之初，就要考虑系统的安全性，考虑用户对系统的访问控制。通过访问控制，一方面只有合法的用户才可以安全、正确的使用系统，非法的用户是无法登陆系统进行操作;的;另一方面合法的用户登录系统之后，由于用户的类型不同，就会存在不用的用户在访问系统时具有不同的权限，比如一个企业或公司的经理往往会比企业或公司的员工具有更多的权限和功能，相应的用户登录系统之后，他们只能行使系统准许他们的权限。 纵观现在的Web系统，大都存在这样的问题:功能虽强大，但是却存在很多 2 的安全隐患。系统中的不同类型的用户对信息都具有相同的权限，可以任意的修改和删除，这对于一些重要的信息是非常危险的。对信息的科学管理，应该是最高层的用户拥有对信息最高的权限，而处于底层或次底层的用户仅拥有对信息最少的权限。此外，现在大部分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):表示对系统中的客体进行特定模式访问的操作许可，例如对数据库系统中关系表的选择、插入、删除。在应用中，许可受到特定应用 3 逻辑的限制。 用户指派(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) 对于某些特定的操作集，某一个角色或用户不可能同时独立地完成所有这些操作。职责分离的概念包括:多路共享资源，用功能分解命名互相区分的权限集，对用户进行强制分类，允许层次性的分解权限。 4 1.2.2 RBAC适用性分析 在RBAC模型中，一个用户通过用户授权获得一个或者几个角色，但角色不能被同时激活;一个角色可以被同时授予多个用户;每个角色有一个或多个节点，一个节点也可以被赋予多个角色;每个节点有一个或者多个功能，一个功能可以被同时挂在不同的节点上，而节点可以有子节点，子节点也可以再有子节点;一个功能对应一个或多个页面;一个页面有一个或多个操作。这样每个用户登录时就可以根据角色得到一棵功能树从而使用系统中的资源。 为更真实的描述现实， RBAC模型还有许多的控制机制。如对Web页面多维度和细粒度控制，对角色、功能、节点的静态限制和对角色的动态限制。对页面的限制主要是限制用户在特定时间和特定地点所能看到的功能和所能进行的操作。其他限制主要是在功能被赋予节点时、节点被赋予角色时和角色被赋予用户时的限制。模型中有了这些限制才更完整、更真实地反应现实，从而使实际模型细化的过程更加平滑，现实和计算机实现策略达到较好的融合。 页面是Web应用系统中最重要的元素，控制页面访问是整个系统安全的重要条件。对页面的访问控制可以从时间和空间两个方面来进行，对页面功能和数据的访问，可以通过用户登录后所带session中的信息进行控制。 时间约束分为一般时间约束和周期时间约束两种。一般时间约束是指从一个时间点持续到另一时间点之间可以访问某个页面，例如，企业商务系统中的商品招标页面，它在某一指定时间段内开放，对这种约束可以在用户访问网页的时候判断访问时间是否在允许范围内。周期时间约束是指对那些功能和数据周期性开放的页面进行访问控制。空间约束主要是对用户在不同地方(网段)登录所能看到的页面以及页面能提供的信息进行控制。例如，管理部门内部事务所对应的页面通常对用户所在的访问位置有较严的限制。一般系统的高层用户都有一个固定的IP段，就可以对那些重要的页面设置允许访问的IP范围来达到对关键资源的保护。对页面的空间约束可以分成分网段、分楼层、分房间、分IP地址等不同层次的控制。 对页面功能和数据的访问需要知道用户的大概类型，主要包括管理员、部门管理员、一般职工、游客(企业或单位以外的人员)等。用户登录后将用户的类型保存到session中，在用户访问页面时就可以根据用户的不同类型，以及他们对时间、空间等硬性约束的满足情况来显示相应的功能和数据。 通过了解RBAC模型的原理和RBAC模型中对访问控制的支持，我们可以看出，RBAC模型可以很好的应用于已有或将要开发的企业商务Web系统中。通过在系统中使用RBAC模型，可以很好的解决如下的问题: 权限管理混乱的问题。通过在系统中增加角色这个概念，很好的解决了这个 5 问题。在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)数据备份 6 一般采用数据库系统自动定时备份、定时自动删除几天以前的数据等，即可完成数据的备份功能。而图片、文件一般是不能自动备份，需要手工操作，所以我们必须要定期手工对网站的图片、文件进行备份操作。 访问控制技术是由美国国防部(Department of Defense, DoD)资助的研究和开发成果演变而来的。这一研究导致两种基本类型访问控制的产生:自主访问控制(Discretionary Access Control, DAC)和强制访问控制(Mandatory Access Control, MAC)。最初的研究和应用主要是为了防止机密信息被未经授权者访问，近期的应用主要是把这些策略应用到为商业领域。 自主访问控制，允许把访问控制权的授予和取消留给个体用户来判断。为没有访问控制权的个体用户授予和废除许可。自主访问控制机制允许用户被授权和取消访问其控制之下的任何客体(object)，换句话说，用户就是他们控制下的客体的拥有者。然而，对于多数组织来说，最终用户对所访问的信息没有拥有权。对于这些组织，公司或代理机构是事实上的系统客体和处理他们的程序的拥有者。访问优先权受组织控制，而且也常常基于雇员功能而不是数据所有权。 强制访问控制，在美国国防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定义如下:“一种限制访问客体的手段，它以包含在这些客体中的信息敏感性和访问这些敏感性信息的主体的正式授权信息(如清除)为基础”。 强制访问控制是“强加”给访问主体的，即系统强制主体服从访问控制政策。强制访问控制(MAC)的主要特征是对所有主体及其所控制的客体(例如:进程、文件、段、设备)实施强制访问控制。为这些主体及客体指定敏感标记，这些标记是等级分类和非等级类别的组合，它们是实施强制访问控制的依据。系统通过比较主体和客体的敏感标记来决定一个主体是否能够访问某个客体。用户的程序不能改变他自己及任何其它客体的敏感标记，从而系统可以防止特洛伊木马的攻击。 强制访问控制一般与自主访问控制结合使用，并且实施一些附加的、更强的访问限制。一个主体只有通过了自主与强制性访问限制检查后，才能访问某个客体。用户可以利用自主访问控制来防范其它用户对自己客体的攻击，由于用户不能直接改变强制访问控制属性，所以强制访问控制提供了一个不可逾越的、更强的安全保护层以防止其它用户偶然或故意地滥用自主访问控制。 以上访问控制策略对于处理一些无需保密但又敏感的信息的政府和行业组织的需求并不是特别的适合。在这样的环境下，安全目标支持产生于现有法律、道德、规章、或一般惯例的高端组织策略。这些环境通常需要控制个体行为的能力，而不仅仅是如何根据信息的敏感性为其设置标签从而访问这一信息的个人能力。 7 就基于角色访问控制而言，访问决策是基于角色的，个体用户是某个组织的一部分。用户具有指派的角色(比如医生、护士、出纳、经理)。定义角色的过程应该基于对组织运转的彻底分析，应该包括来自一个组织中更广范围用户的输入。 访问权按角色名分组，资源的使用受限于授权给假定关联角色的个体。例如，在一个商务管理系统中，经理角色可能包括人事管理、工资管理、分配项目等;而一般员工的角色则被限制为仅能浏览自己的一些信息，如基本信息、工资信息和工程项目信息等。 基于角色的访问控制模型RBAC比传统的自主访问控制和强制访问控制更优越，同时也提供了更高的灵活性和扩展性。RBAC访问控制模型实现了用户与访问权限的逻辑分离，减少了授权管理的复杂性，降低了管理开销和管理的复杂度。对于现在规模日益增大的基于MVC架构的商务信息管理系统来说，采用RBAC访问控制模型的访问控制模块将会起到越来越大的作用。 综上分析，控制访问角色的运用是一种开发和加强企业特殊安全策略，进行安全管理过程流程化的有效手段。运用RBAC模型可以很好的解决Web系统中提出的访问控制要求，而DAC、MAC等等访问控制技术由于各种各样的局限性和特性，都不是WEB系统下实现访问控制的最好选择。 从目前的应用现状来看，以MVC为架构而建成的WEB网站特别是商务网站的数量较为庞大，而由于其自身的管理特性，对安全措施的要求也越来越高，这就要求我们找到一种更为有效的权限管理方法去适应网站对访问控制技术的要求。而RBAC作为一种科学、合理、灵活、成熟的访问控制技术，最适合于在WEB环境下使用，所以如何使它应用到那些基于MVC架构的网站中去，会是一个具有相当研究价值的课题。 8 第二章 系统框架分析与设计 2.1 基于MVC架构的Web系统 在当前开发的商务系统中，一般都会包括部门管理功能模块，员工管理功能模块，工程项目管理功能模块和员工薪水管理功能模块，以及包括针对员工使用的信息查看模块。先下面给出一个已经设计完善的基于MVC架构的WEB网站，系统的功能模块图如图2-1所示。 系统的功能模块 部员工员信系系系 门工程工息统统统 管管项工查功用角 理理目资看能户色 模模管管模管管管 块 块 块 理理理理理 模模模模模 块 块 块 块 块 图2-1 系统功能模块图 部门管理模块:针对公司内部的所有的部门进行管理，用户可以方便地添加部门、修改部门信息、删除某一部门和查询某一部门的信息。 员工管理模块:针对公司内部的所有的员工进行管理，用户可以方便地添加员工信息、修改员工信息、删除某一员工信息和查询某一部门的所有员工信息。 工程项目管理模块:针对公司的工程项目进行管理，用户可以方便地添加工程项目信息、修改某一工程项目的信息、删除某工程项目的信息和查询某一工程项目信息。 员工工资管理模块:针对公司内部的所有的员工的薪酬进行管理，用户可以方便地添加工资信息、修改工资信息、删除工资信息和查询某一员工在某段时间内的所有工资信息。 信息查看模块:针对公司员工设计的功能模块，通过该模块员工可以方便的查看自己的基本信息，工资信息以及所负责的工程项目信息。 9 系统功能管理模块:用户可以通过该模块管理系统中涉及到的所有功能，可以添加、删除和修改。 系统用户管理模块:用户可以通过该模块管理系统中涉及到的所有用户，可以添加、删除和修改。 系统角色管理模块:用户可以通过该模块为系统中的不同的用户设置不同的权限，并能够修改某一用户所赋予的权限。 在上述的商务系统中，在安全性上一般会有如下的要求: 能够很好的实现访问控制。在一个企业中，存在着很多种不同的用户，如经理、董事长、一般职工，系统维护人员等。当所有的用户面对同一个系统时，就应该做到用户之间要有区分，即进入系统后不同的用户只能实行自身拥有的权限，不可以越权。 部分信息的保密。公司中存在着一些决定企业利益的信息，这些信息只能由公司的管理人员来查看和管理，任何非法的侵入都有可能造成不良的后果。 现代主流的Web系统的体系架构设计基于J2EE平台上的MVC设计模式，应用Struts框架，采用B/S模式，具体的架构设计如图2-2所示。 BusinessWeb Container Layer Client Controller Model Database Layer Layer Action Java Http Action Servlet Bean Request Action Request Business Action Processor Objects Http Browser Response View Oracle 9i HTML Struts Tags(JSTL) JSPs Style Sheet Presentation Layer Web.xml Struts-config.xml BusinessManagement_MessagerResources .properties 图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则交由 10 业务逻辑层来实现。 业务逻辑层(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} 11 UA,Users*Roles:用户—角色分配关系:多对多; Assigned-users:，角色与用户的映射，将一个角色与一组用户相映射; :权限-角色分配关系，多对多; Assigned privileges : ，角色与权限的映射，将一个角色与一组权限相映射; Session :会话集{s1，s2，s3，„„，sn } User_sessions :，用户与会话的映射，将一个用户与一个会话相映射; Session_roles :，会话与角色的映射，将一个会话与一组角色相映射; Avail_session_privilege :，在一次会话中一个用户允许的权限; 用户:不仅指人，也可以指机器，网络或智能代理。 角色:管理员依据安全策略划分出来的操作集合，表示该角色成员所授予的职权和责任。 客体:指系统需要保护的资源。 权限:对系统中的客体进行特定存取的许可。权限是与客体紧密相关的，不同的系统，其权限规定是不同的，既可以指网络的应用，如对某个子网的访问权限，也可以指对数据库的表单等的访问。权限的粒度大小取决于实际系统的定义。 会话:为了对系统资源进行操作，用户需要建立会话，每个会话将一个用户与他所对应的角色集中的一部分建立映射关系，这一角色子集成为被会话激活的角色，在这次会话中，用户可以执行的操作就是该会话激活的角色对应的权限所允许的操作。 上述RBAC模型是RBAC核心模型，此模型保留了RBAC的最小特征集，是每个RBAC系统都需要的元素。 2.3 RBAC模型在MVC网站中的应用 由需求分析可知，需要为企业内部网管理系统设计一个用户权限管理的功能模块，从而达到对用户权限进行管理的目的。当今的大型的信息管理系统都具有 12 功能复杂，用户众多的特点，如果仍采用传统的权限管理方式，直接将权限分配给用户，对具有相同权限的一类用户同样的授权操作将被重复很多遍，一旦用户工作岗位有变化，则对其权限的调整将非常复杂，而基于RBAC模型的权限控制方法则大大简化了这种授权管理的复杂度，降低了系统管理的开销。 RBAC模型描述了一种良好的访问控制方法和原理。通过在商务Web系统中使用RBAC模型可以方便、科学、合理地进行访问控制，有了良好的访问控制，不同的用户在使用系统的时候仅能访问自身被赋予的权限，用户之间不能越权访问，从而保证了信息的安全性和一致性，从而提高了系统的安全性。 通过以下几个步骤，可以将RBAC模型应用在MVC网站中。 (1)建立功能的概念。功能，即操作。在系统中，如对员工的添加、删除和修改的操作，都可以描述为一个功能。 (2)建立权限节点的概念。权限节点，顾名思义，它对应着一个或一组功能操作菜单，表示了该节点可以进行系统操作的范围。 (3)建立角色的概念。将角色与节点对应起来，一个角色可以对应多个节点，一个节点也可以对应多个角色，这是一个多对多的关系。角色与节点对应好之后，也就意味着角色与某一个或某一组功能操作菜单建立了关联。系统中存在不同类型的用户，也即不同的用户隶属于不同的角色。 (4)将系统的用户和角色关联起来。一旦一个用户被设置了某个角色，那么也就意味着该用户具有了某些权限。具有了某些权限，也就意味着拥有了某些功能(对系统的操作和管理)。 举例来说，假设系统中存在两个权限节点1和2，两个角色A和B，用户有甲(经理)和乙(部门经理)，很显然甲和乙在登陆系统后应该具有不同的权限，甲可以管理整个公司的信息，而乙仅能管理所在部门的信息。这时，设定权限节点1下包含了管理整个公司信息的所有功能，权限节点2下包含了管理某个部门信息的所有功能;将角色A与节点1进行关联，将角色B与节点2进行关联。最后，将用户甲的角色设定为角色A，用户乙的角色设定为角色B。在用户甲和乙登陆系统后，就会看到自己所具有的功能菜单，其他用户的功能菜单是非可见的，从而实现了访问控制。 简言之，通过在系统中设置功能、权限和角色的概念，就可以在系统中实现RBAC模型，并让它很好地为Web系统提供访问控制功能。 13 第三章 设计实现 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 角色描述 可为空 14 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 CZ VARCHAR 操作(只读、读写、执5 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 15 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 部门联系电话 DEPMANAGVARCHAR 部门负责人 4 8 ER 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 企业员工工资表 16 编号 列名 类型 长度 说明 约束 1 *ID NUMBER 工资帐单序号 2 SALARY_NUM VARCHAR 10 工资帐单金额 3 WORKERBM VARCHAR 10 员工编号 11.1 4 SALARY_DATE DATE 工资帐单发放日期 11、P_WORKER企业员工信息表 记录每个企业员工的信息。如表3-11所示。 表3-11 企业员工表 编号 列名 类型 长度 说明 约束 1 *WORKERBM VARCHAR 10 员工编号 2 WORKERMC VARCHAR 50 员工姓名 3 WORKERAGE VARCHAR 3 员工年龄 4 WORKERSEX VARCHAR 1 员工性别 5 WORKERADDRESS VARCHAR 200 员工地址 6 WORKERLXDH VARCHAR 50 员工联系电话 7 WORKERZJHM VARCHAR 50 员工证件号码 8 WORKERDEPBM VARCHAR 5 员工所在部门 8.1 3.2 RBAC模型在系统中的实现 3.2.1 系统功能模块的实现 在功能管理模块中，用户可以进行的操作有:功能添加、修改和删除。系统功能添加的实现过程可以描述为: 转向 提交表单 ActionForm类 浏览器 Struts-config.xml 数据库 JavaBean 调用 封装表单数据 查找 Action类 图3-1 系统功能模块实现的流程图 从图3-1可以看出，用户在试图添加一个系统功能时，应该首先填写表单，填写好表单后，点击表单的提交按钮之后，会触发一个请求事件(Action)，该 17 事件由页面的表单指定。在Struts-config.xml文档中找到相应的Action，同时得到该Action使用的ActionForm类。此时表单的数据将会保存到该ActionForm类中，在Action中就可以得到表单中的数据。 为了完成最终的功能添加，在相应的Action实现类中，还需要调用模型层中的业务功能函数，来完成此次的业务逻辑。在相应的JavaBean中，完成与数据库的交互，实现对数据的添加。 用到的ActionForm类是GnoperatorForm类，该类继承ActionForm类，并具有gnid,cz,ljxjd,gnmc,gnms,zurl等属性。GnoperatorForm的部分实现代码如下: public class GnoperatorForm extends ActionForm { private static final long serialVersionUID = 1L; private String gnid; private String cz; private String ljxjd; private String gnmc; private String gnms; private String kfgb; private String zurl; „„ public String getGnmc() { return gnmc; } public void setGnmc(String gnmc) { this.gnmc = gnmc; } public String getGnms() { return gnms; } public void setGnms(String gnms) { this.gnms = gnms; } „„ } 实现功能添加的Action类GnoperatorAction.java,部分实现代码如下: public class GnoperatorAction extends Action { 18 public ActionForward execute(ActionMapping mapping, ActionForm form,HttpServletRequest request, HttpServletResponse response) { ActionForward nextdisplay = new ActionForward(); // 生成一 个ActionForward对象 String actionmappingpara = mapping.getParameter(); // 接收 ActionMaping的参数 if ("gnoperator".equalsIgnoreCase(actionmappingpara)) { nextdisplay = gnoperator(mapping, form, request, response); } else if ("gnoperator_update".equalsIgnoreCase(actionmappingpara)) { nextdisplay = gnoperator_update(mapping, form, request, response); } else if ("gnoperator_getgn".equalsIgnoreCase(actionmappingpara)) { nextdisplay = gnoperator_getgn(mapping, form, request, response); } return nextdisplay; } //完成功能添加的实现方法 public ActionForward gnoperator(ActionMapping mapping,ActionForm form,HttpServletRequest request, HttpServletResponse response) { GnoperatorForm gnof = (GnoperatorForm) form; ActionForward forward = new ActionForward(); String method = (String) request.getParameter("method"); dbOp db = new dbOp(); response.setCharacterEncoding("gbk"); if (method.equalsIgnoreCase("insert")) { // 新增功能 if (db.insertintoGnb(gnof)) { gnof.setGnmc(""); gnof.setGnms(""); gnof.setZurl(""); 19 gnof.setZimc(null); gnof.setZims(null); gnof.setZiurl(null); request.setAttribute("result", "success"); forward = mapping.findForward("success"); } else { request.setAttribute("result", "failure"); forward = mapping.findForward("failure"); } } else if (method.equalsIgnoreCase("update")) { // 更新功能 if (db.UpdateGnb(gnof)) { request.setAttribute("result", "更新成功"); forward = mapping.findForward("successupdate"); } else { request.setAttribute("result", "更新失败"); forward = mapping.findForward("failureupdate"); } } db.close(); return forward; } „„ } 完成功能添加的业务函数存放在dbOp类中，它的部分实现代码如下: public class dbOp extends DBOperator { /** * 插入一个新的功能 */ public boolean insertintoGnb(GnoperatorForm gnof) { String gnmc = this.toGBK(gnof.getGnmc()); String zurl = this.toGBK(gnof.getZurl()); String gnms = this.toGBK(gnof.getGnms()); String ljxjd = gnof.getLjxjd(); boolean b = false; 20 String sql = "insert into p_gnb(gnid, gnmc, gnms, zurl, cz, ljxjd, sfglip, kfgb) " + "values (p_gnidxl.nextval,'"+ gnmc+ "','" + gnms + "','"+ zurl + "','1','" + ljxjd + "','0','1'" + ")"; try { Statement insert_stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_ READ_ONLY); insert_stmt.execute(sql); b = true; insert_stmt.close(); } catch (SQLException e) { e.printStackTrace(); } return b; } „„//其他业务函数 } 3.2.2 系统权限模块的实现 为了方便的进行权限的设置和角色的管理，借助SWT Designer(Eclipse的一个插件，专门用来有界面的Java应用程序)开发了一个专门用于管理权限节点和系统角色的应用程序。具体的实现类如下所示。 /** 节点的管理类 */ public class NodeMan { public String nodeid;// 节点id public String nodename;// 节点名称 public String ifparent;// 是否是父节点 public String nodedes; // 节点的描述信息 public String gnid;// 功能id public String gnmc;// 功能名称 public String gnms;// 功能描述 public String gnnxh;// 功能内序号 public String jdnxh;// 节点内序号 „„ 21 /** 添加父节点 */ public boolean addparnode(String nodename, String ifparent, String nodedes, String jdnxh) { boolean flag = false; try { pstmt = con .prepareStatement("insert into p_jdb(jdid, jdmc, fjdid, jdms,jdnxh) " + "values (p_jdidxl.nextval,?,?,?,?)"); pstmt.setString(1, nodename); pstmt.setString(2, ifparent); pstmt.setString(3, nodedes); pstmt.setString(4, jdnxh); pstmt.executeUpdate(); flag = true; } catch (SQLException e) { e.printStackTrace(); flag = false; } finally { this.close(); } return flag; } /* 修改某一个节点的信息 */ public boolean UpdateNodeInfo(String nodename, String nodedes, String nodeid) { boolean flag = false; try { pstmt = con .prepareStatement("update p_jdb set jdmc = ?,jdms = ? where jdid = ?"); pstmt.setString(1, nodename); pstmt.setString(2, nodedes); pstmt.setString(3, nodeid); 22 pstmt.executeUpdate(); flag = true; } catch (SQLException e) { e.printStackTrace(); flag = false; } finally { this.close(); } return flag; } „„ } 3.2.3 系统角色模块的实现 系统中角色的实现类是RoleMan.java，部分代码如下所示。 /** * 角色的管理类 */ public class RoleMan { public String roleid;// 角色id public String rolename;// 角色名称 public String roledes;// 角色描述 public String rolemaxnum;// 角色下的用户最大数 /* 增加一个角色 */ public boolean addrole(String rolename, String roledes, String rolenum, String roletype) { boolean flag = false; try { pstmt = con .prepareStatement("insert into p_jsb(jsid, jsmc, jsms, jsxyhzds, jslx) " + "values(p_jsidxl.nextval,?,?,?,?)"); pstmt.setString(1, rolename); 23 pstmt.setString(2, roledes); pstmt.setString(3, rolenum); pstmt.setString(4, roletype); pstmt.executeUpdate(); flag = true; } catch (SQLException e) { e.printStackTrace(); flag = false; } finally { this.close(); } return flag; } /** 更新某个角色的信息 */ public boolean ChgrolebyId(String rolename, String roledes, String rolenum, String roleid) { boolean flag = false; try { pstmt = con .prepareStatement("update p_jsb set jsmc=?,jsms=?,jsxyhzds=? where jsid=?"); pstmt.setString(1, rolename); pstmt.setString(2, roledes); pstmt.setString(3, rolenum); pstmt.setString(4, roleid); pstmt.executeUpdate(); flag = true; } catch (SQLException e) { flag = false; e.printStackTrace(); } finally { this.close(); } return flag; 24 } „„ } 3.2.4 为用户设置角色 添加完系统功能，建立好权限节点，此时节点和系统的功能关联在一起;建立好角色并为某个角色分配好节点之后，系统角色与系统的功能就建立了关联，最后一步就是将系统用户和建立的系统角色建立关联，为某用户设置某一角色，设置好之后，该用户就可以获取该角色关联到的所有系统功能。 用来实现这一功能的Java类是dbOp.java，具体实现代码如下。 public class dbOp extends DBOperator { /** * 为一组用户设置角色 */ public boolean insertYhJs(String jsid, String yhid[]) { String sql = ""; boolean b = false; try { for (int i = 0; i < yhid.length; i++) { sql = "insert into p_yhjsb (jsid, yhid) values ('" + jsid + "','" + yhid[i] + "')"; this.insertRecord(sql); } b = true; } catch (Exception e) { System.out.println(e); b = false; } return b; } /** * 删除用户角色 */ 25 public boolean deleteYhJs(String yhid, String jsid) { boolean b = false; String sql = "delete p_yhjsb where yhid = '" + yhid + "' and jsid = '" + jsid + "'"; try { PreparedStatement delete_stm = con.prepareStatement(sql); delete_stm.executeUpdate(); delete_stm.close(); b = true; } catch (Exception e) { System.out.println(e); b = false; } return b; } „„ } 3.2.5 用户权限功能树的生成 在实现了RBAC模型的Web系统中，每个用户(设置好某个系统角色之后)登陆成功之后，会在页面的左侧看到相应的权限功能树，即表示该用户对系统拥有的管理和使用权限。 权限功能树的生成，需通过如下几个步骤: (1)首先根据用户的ID获取该用户的角色ID，有了角色ID之后，接着要根据角色ID获取该角色ID对应的权限ID，有了权限节点ID，就可以获取该节点ID下对应的所有功能。实现代码如下。 /** * 获得用户的权限树 */ public ArrayList getUserTree(String userId) { ArrayList array = new ArrayList(); String sql = " select p_jdb.* from (select * from ( select * 26 from p_yhjsb where yhid='" + userId + "')b, p_jsjdb where " + "p_jsjdb.jsid=b.jsid )yhjs, p_jdb where yhjs.jdid=p_jdb.jdid"; try { query_statement = sql; result = null; result = this.getResult(); while (result.next()) { oneTree onetree = new oneTree(); onetree.setId(result.getString("jdid")); onetree.setName(result.getString("jdmc")); onetree.setPid(result.getString("fjdid")); onetree.setTitle(result.getString("jdms")); array.add(onetree); String jdid = result.getString("jdid"); this.foronjdid(jdid, array);,, 对某个节点进行处理 } } catch (Exception e) { } return array; } /** * 权限树的实体类 */ public class oneTree implements Serializable { String id; // 中节点的ID String pid; // 上面节点的父节点 String name; // 树中节点显示的名字 String url; // 树中节点对应的主URL String title; // 鼠标移到节点时的提示 String targer;// 点击此url时新窗口出现的位置; String icon;// String iconopen; 27 String open; „„, (,)在获取了该用户的所有权限节点和功能列表后，就需要某种机制来实现在页面上显示成一个树的形状，在系统中使用了一个开源的dtree.js(一个用JavaScript实现的程序)和dtree.css(一个用来规定显示格式的样式表文件)，借助它们，就可以将获取的权限和功能列表以树的形式显示在页面上。这两个文件存在于系统的根目录中。 28 第四章 系统测试 4.1 系统测试 4.1.1 测试环境 测试环境下使用的操作系统是Windows XP(SP2 )，cpu为P4 2.4GHz，内存256兆。软件环境是:Eclipse，MyEclipse，并使用SWT Designer 作为Eclipse 的插件。Web服务器是Tomcat，开源软件。使用的后台数据库服务器是Oracle9i，提供了数据的安全性和稳定性。 4.1.2 测试方案 为了验证RBAC模型在具体系统中的访问控制效果，进行了如下的测试。 (,)合法用户的合法登陆 假定系统中存在公司经理(为经理设置了经理的角色)，某员工张三(为其设置了员工的角色)和系统的管理员(为其设置了系统管理员的角色)，在他们输入了正确的用户名和用户密码后，将分别进入如下图所示的页面。 图,,, 公司经理登陆成功看到的操作界面 29 图,,, 公司员工张三登陆成功看到的操作界面 图,,, 系统管理员登陆成功看到的操作界面 (,)非法用户的访问 存在三种情况，其一是用户名是错误的，即该用户不被系统承认;其二是合法用户的登录密码错误;最后一种是用户名是非法的，密码也是错误的。 30 图,,, 非法用户登陆时看到的操作界面 (,)合法用户的登陆(未设置角色) 假定有员工王五，但是还没有为他设置系统角色，那么他登陆后将看到如图,,,所示的页面。 图,,, 合法用户(未设置角色)登陆后看到的页面 31 4.2 总结与展望 基于角色的访问控制模型RBAC是目前主流的访问控制模型，它比传统的自主访问控制和强制访问控制更优越，同时也提供了更高的灵活性和扩展性。RBAC访问控制模型实现了用户与访问权限的逻辑分离，减少了授权管理的复杂性，降低了管理开销和管理的复杂度。对于现在规模日益增大的基于B/S架构的信息管理系统来说，采用RBAC访问控制模型的访问控制模块将会起到越来越大的作用。 本文分析MVC商务网站系统的特点和优势，并就在网站访问控制上将强制访问控制、自主访问控制与当前广泛使用的RBAC模型进行了分析和比较，得出RBAC模型在,,,应用系统中的优势，并根据最新的商务网站需求，提出了一个改进的RBAC模型，介绍了该模型的定义和特点，并给出了一个利用该模型设计的一个企业商务管理系统的实现。本方案有足够的灵活性，对Web页面的控制能达到较好的效果。 为更真实的描述现实，ERBAC模型增加了许多的控制机制。如对页面多维度和细粒度控制，对角色、功能、节点的静态限制和对角色的动态限制。对页面的限制主要是限制用户在特定时间和特定地点所能看到的功能和所能进行的操作。其他限制主要是在功能被赋予节点时、节点被赋予角色时和角色被赋予用户时的限制。模型中有了这些限制才更完整、更真实地反应现实，从而使实际模型细化的过程更加平滑，现实和计算机实现策略达到较好的融合。 另一方面，RBAC在实际Web应用中仍存在一些不足，比如它进行了过多的抽象，对现实的模拟不够。本文通过改进的RBAC模型对这些不足提出一些局部解决方案。除此之外，在对RBAC功能的扩展中还有些是很值得去研究的，比如角色生存周期以及角色根据状态动态变更权限等。 但是由于本模型实现时的数据是以关系表的形式存储在ORACLE数据库中的，虽然实现起来简单方便，但是环境配置要求较高，且不利于向其它数据库的移植。下一步的工作目标是用MYSQL或SQL-SERVER来存储模型实现数据，基于STRUTS开发一个RBAC标签库，利用标签来进一步进行Web页面的访问控制。 32 4.3 致谢 漫长的四年大学生活就要结束了。在我即将离开之际，回首过去，感慨万千。在这里我要感谢各科目的老师对我的辛勤栽培，感谢同学朋友对我的鼓励，感谢母校能够提供给我这么良好的学习环境，特别要感谢陆悠老师在长达半年的毕业设计期间对我的指导和教诲，没有他们就没有我的这篇毕业论文。相信我在踏上社会这个大舞台后，一定不会辜负所有人的期望，走出属于自己的一片天～ 33 参考文献 [1] Sandhu R S, Coyne E, Feinstein H, et al. Role-Based Access Control Models. IEEE Computer, 1996,29(2):38-47 [2]倪晚成、刘连臣、刘伟，基于角色—页面模型的WEB用户访问控制方法[J].计算机工程与应用，2006，21 125~126 [3] 甘泉，贺也平，韩乃平. 一种改进的基于角色的访问控制. 《计算机工程》，2006(7):140-142 郭慧，李阳明，王丽芬. 基于角色和任务的访问控制模型的设计与[4] 研究. 《计算机工程》，2006(16):143-145 李沛武，卢正鼎. RBAC角色区间的封装和分布式管理. 《小型微型[5] 计算机系统》，2005(2):252-255 [6] 孙永，王雄. 一种域增强的RBAC模型及其管理模型. 《计算机工程与应用》，2005(6): 60-64 [7] (美)史迪文斯(Stevens,W.R.) . UNIX环境高级编程(机械工业出版社，2000 [8] 孙卫琴，李洪成(Tomcat与Java Web开发技术详解(电子工业出版社，2004 [9] 孙卫琴(精通Struts:基于MVC的Java Web设计与开发(电子工业出版社，2004 34 附录A:英文原文 Role-Based Access Control for the Web John F. Barkley, D. Richard Kuhn, Lynne S. Rosenthal, Mark W. Skall, and Anthony V. Cincotta, National Institute of Standards and Technology Gaithersburg, Maryland 20899 ABSTRACT Establishing and maintaining a presence on the World Wide Web (Web), once a sideline for U.S. industry, has become a key strategic aspect of marketing and sales. Many companies have demonstrated that a well designed Web site can have a positive effect on their profitability. Enabling customers to answer their own questions by clicking their way through Web pages, instead of dealing with operators and voice response systems, increases the efficiency of the customer interface. One of the most challenging problems in managing large networked systems is the complexity of security administration. This is particularly true for organizations that are attempting to manage security in distributed multimedia environments such as those using World Wide Web services. Today, security administration is costly and prone to error because administrators usually specify access control lists for each user on the system individually. Role-based access control (RBAC) is a technology that is attracting increasing attention, particularly for commercial applications, because of its potential for reducing the complexity and cost of security administration in large networked applications. The concept and design of RBAC is perfectly suited for use on both intranets and internets. It provides a secure and effective way to manage access to an organization’s Web information. This paper describes a research effort to develop RBAC on the Web. The security and software components that provide RBAC for 35 networked servers using Web protocols have been implemented and are described in this paper. The RBAC components can be linked with commercially available web servers, and require no modification of the server software. Introduction Establishing and maintaining a presence on the World Wide Web (Web), once a sideline for U.S. industry, has become a key strategic aspect of marketing and sales. Many companies have demonstrated that a well-designed Web site can have a positive effect on their profitability. Enabling customers to answer their own questions by clicking their way through Web pages, instead of dealing with operators and voice response systems, increases the efficiency of the customer interface. Companies are seizing the Web as a swift way to streamline - even transform their organizations. More recently companies have begun using web technology to service the public as well as private and internal clients. Web sites are set up to segregate some information from the general public, providing it to only selected or "private" clients. Typically, public internet is cordoned off from the general public by having user accounts and passwords. Additionally, Web sites are now running inside the company often created for and by employees. These internal private nets or "intranets" use the infrastructure and standards of the Internet and the World Wide Web but are cordoned off from the public Internet through firewalls. The Web can be used as an inexpensive yet powerful alternative to other forms of communications. A plethora of corporate information (e.g., procedures, training materials, directories, forms) can be converted to electronic form and made available via the Web. With a single source for these materials the cost of maintenance is significantly reduced, while greatly simplifying the task of ensuring currency. Thus an objective of enterprise computing, creation of a company wide system irrespective of the underlying information technology infrastructure can be fulfilled. Although the internet and intranets can offer great benefits to a company or government agency, security threats remain. To date net enthusiasts tend to focus on how to link people and businesses, not on using the network as a way to run and manage businesses securely. Although 36 existing Web servers can effectively provide all or nothing access to a particular Web site and a number of popular Web servers can even provide fairly fine grained access control, they provide very primitive tools to administer these controls from the perspective of a single enterprise. This paper describes the benefits of RBAC and an implementation of RBAC on the Web (RBAC/Web), and in particular as RBAC applies to an intranet computing environment. This will provide Web administrators with a capability for the first time to centrally administer and regulate user access to information in a manner that is consistent with the current set of laws, regulations, and practices that face their business today. Although this paper focuses on intranets, the benefits, concepts and implementation of RBAC/Web are also applicable to a company’s internet environment where restrictive access to information is desired. RBAC Description Role-based access control (RBAC) [1], [2], [3], [4], [5] is an alternative to traditional discretionary (DAC) and mandatory access control (MAC) policies that is attracting increasing attention [6], particularly for commercial applications. The principal motivation behind RBAC is the desire to specify and enforce enterprise-specific security policies in a way that maps naturally to an organization's structure. Traditionally, managing security has required mapping an organization's security policy to a relatively low-level set of controls, typically access control lists. With RBAC, security is managed at a level that corresponds closely to the organization's structure. Each user is assigned one or more roles, where roles are based on the user's job responsibilities and competencies in the organization. Each role is assigned one or more privileges (e.g., information access, deletion, creation), see Figure 1. It is a user's membership into roles that determine the privileges the user is permitted to perform. Security administration with RBAC consists of determining the operations that must be executed by persons in particular jobs, and assigning employees to the proper roles. The RBAC framework provides for mutually exclusive roles as well as roles having overlapping responsibilities and privileges. For example, some general operations may be allowed by all employees, while other 37 operations may be specific to a role. Role hierarchies are a natural way of organizing roles within an organization and defining the relationship and attributes of the roles. Complexities introduced by mutually exclusive roles or role hierarchies as well as regulating who can perform what actions, when, from where, in what order, and in some cases under what relational circumstances, is all handled by the RBAC software. Separation of Duty RBAC mechanisms can be used by a system administrator in enforcing a policy of separation of duties. Separation of duties is considered valuable in deterring fraud since fraud can occur if an opportunity exists for collaboration between various job related capabilities. Separation of duty requires that for particular sets of transactions, no single individual be allowed to execute all transactions within the set. The most commonly used examples are the separate transactions needed to initiate a payment and to authorize a payment. No single individual should be capable of executing both transactions. The system administrator can control access at a level of abstraction that is natural to the way that enterprises typically conduct business. This is achieved by statically and dynamically regulating users' actions through the establishment and definition of roles, role hierarchies, relationships, and constraints. We define static separation of duty to mean that roles which have been specified as mutually exclusive cannot both be included in a user's set of authorized roles. With dynamic separation of duty, users may be authorized for two roles that are mutually exclusive, but cannot have both roles active at the same time. In other words, static separation of duty enforces the mutual exclusion rule at the time an administrator sets up role authorizations, while dynamic separation of duty enforces the rule at the time a user selects roles for a session. Role Administration and Visualization The roles are established, manipulated and viewed using the RBAC/Web Admin tool. The Admin tool allows system administrators to create and define roles, role hierarchies, relationships and constraints. Once the 38 RBAC framework is established for the organization, the principal administrative actions are the granting and revoking of users into and out of roles as job assignments dictate. These maintenance tasks are easily performed using the Admin tool. Additionally, the Admin tool is being enhanced to utilize the Virtual Reality Modeling Language (VRML, pronounced 'vermal'). VRML is an interactive, inter-networked, 3D graphics language for the Web. It is used to represent graphics, test, sound, and links to other content as either a static or dynamic picture on the Web. The inclusion of VRML into RBAC lets system administrators use an interactive computer model to check and validate the role structure, relationship, and privileges. Being able to view and interact with complex models, allows the administrator to identify conflicts, eradicate flaws and improve the implementation early in the RBAC setup. The VRML component will enable authorized users to navigate the RBAC database, finding and linking roles, and displaying attributes and graphics associated with those roles. By presenting a 3D model of established roles, the user can easily see which roles are mutually exclusive as well as the hierarchical structure of related roles and conflicts between roles (see Figure 2). VRML's navigational controls allows the user to interactively 'walk-through' and manipulate the view perspective of the 3D model, known as a scene graph. For example, the scene graph can be rotated to show the 'backside' of the graph where role relationships may have been obscured when viewed as a 'flat', 2D graph. To improve readability, clarity and flexibility, the role hierarchy is organized into layers, where each layer contains another level of detail. By 'clicking' on a role, the role opens to reveal the next layer of related roles or information about the role, e.g., the privileges associated with that role or a user membership list. RBAC Example Consider the branch office of a bank. In this environment, there are roles such as branch manager, teller, and account representative, as illustrated in Figure 2. The graph structure shows role hierarchy. The role financial_advisor inherits the role account_rep. An individual authorized for the role 39 financial_advisor is permitted to perform all of the operations permitted to an individual authorized for the role account_rep. Thus, an individual in the role of financial_advisor is able to create and remove accounts. Because account representatives, branch managers, internal auditors, and tellers are all employees of the bank, their corresponding roles inherit the employee role. In Figure 2, the role account_rep is highlighted, appearing as a dark sphere, in order to show the other role relationships for account_rep. The roles teller and account_holder are shown as yellow rectangular solids to indicate that these roles have a "Dynamic Separation of Duties" (DSD) relationship with the role account_rep. This relationship is a conflict in interest relationship indicating that an individual acting in the role of account_rep cannot also be acting in either of the roles of account_holder or teller. The policy of the bank is that an account representative, an employee of the bank, can have an account in the bank but such an individual may not simultaneously process their personal account while processing accounts of others. Likewise, because a teller has an open cash drawer that must balance when closed, an individual acting in the role of account_rep and sitting at a desk away from a teller's window is not permitted to simultaneously act in the role of teller even if authorized for that role. The role internal_auditor is shown in a red hexahedron to indicate that this role has a "Static Separation of Duties" (SSD) relationship with the role account_rep. The SSD relationship is also a conflict of interest relationship like the DSD relationship but much stronger. If two roles have a DSD relationship, then they may both be authorized for an individual but that individual may not act in both roles simultaneously. If two roles have a SSD relationship, then they may not even be authorized for the same individual. In this example, the policy of the bank is that there is a fundamental conflict of interest between the roles of internal_auditor and account_rep. Thus, these two roles may never be authorized for the same individual. The new version of the Admin tool using VRML will allow us to represent conflicts of interest and other relationships in a more natural way and view the scene from an infinite number of viewpoints. VRML allows complex 40 3D objects to be created for this purpose. The user can 'enter' a selected role and explore several levels of detail (i.e., information) associated with that role. In addition, the sound capabilities of VRML can be utilized to give audio warnings when roles are used which cause conflicts of interest or other problems, or when improper procedures are used. RBAC for World Wide Web Applications Role Based Access Control (RBAC) for the World Wide Web (RBAC/Web) is an implementation of RBAC for use by World Wide Web (Web) servers. Because RBAC/Web places no requirements on a browser, any browser that can be used with a particular Web server can be used with that server enhanced with RBAC/Web. RBAC/Web is implemented for both UNIX (e.g., for Netscape, NCSA, CERN, or Apache servers) and Windows NT (e.g., for Internet Information Server, WebSite, or Purveyor) environments. Components of RBAC/Web are shown in Table 1. RBAC/Web for UNIX uses all of the components in Table 1. Because built-in NT security mechanisms are closely compatible with RBAC, the NT version uses only the Database, Session Manager, and Admin Tool components. RBAC/Web for NT requires no modification of Web server internals or access to source code. With RBAC/Web for UNIX, there are two ways to use RBAC/Web with a UNIX Web server. The simplest way is by means of the RBAC/Web CGI. The RBAC/Web CGI can be used with any existing UNIX server without modifying its source code. RBAC URLs are passed through the Web server and processed by the RBAC/Web CGI. RBAC/Web configuration files map URLs to file names, while providing access control based on the user's roles. Installation of the RBAC/Web CGI is similar to the installation of the Web server. 附录B:中文翻译 Web环境下基于角色的访问控制 John F. Barkley, D. Richard Kuhn, Lynne S. Rosenthal, Mark W. Skall, 和 Anthony V. Cincotta, 国家研究院所定规则及盖瑟斯堡技术，马里兰20899 41 摘要 建立和维持一个万维网(Web)，它作为美国工业的一种附属形式，已经成为了买卖和销售战略中的重点。许多公司示范了一个设计良好的万维网能让他们在收益性上产生积极的效果。促成客户藉由Web网页按他们的方法获得他们想要的讯息，而不是通过处理操作员或声音回应系统，以增加客户接口的效率。 特别是对于尝试使用万维网服务器来管理多媒体环境安全的组织来说，最挑战性的问题之一在于管理大的网络系统时，所面对的安全管理方面的复杂性。今天，安全管理昂贵和容易出错是因为管理人通常单独为每个在系统上的使用者指定访问控制目录。 基于角色的访问控制(RBAC)是一种逐渐吸引人们注意的技术，特别是在商务应用上，因为它具有减少大型网络应用的复杂性和费用的潜力。 RBAC的概念和设计是为了能完全适应企业内部网和因特网。它提供了一个安全有效的方法去管理和组织其万维网信息的访问。本文描述了如何才能致力于在万维网上去应用基于角色的访问控制。为使用万维网协议的网络服务器提供基于角色的访问控制的安全和软件组件，这些内容都已经被实现并且在本文中得到了描述。基于角色的访问控制组件能被用于商务的万维网服务器上，并且不需要服务器软件的修正。 引言 建立和维持一个万维网(Web)，作为美国工业的一种附属形式，已经成为了买卖和销售战略中的重点。许多公司示范了一个设计良好的万维网能让他们在收益性上产生积极的效果。促成客户藉由Web网页按他们的方法获得他们想要的讯息，而不是通过处理操作员或声音回应系统，以增加客户接口的效率。公司纷纷抓住万维网这样一个迅速的精简办法——甚至不惜转变他们的组织。 越来越多的新公司开始使用万维网技术去为公众或私人以及国内客户提供服务。万维网站的建立是用来分隔一些来自普通大众的信息，提供给他唯一的选择或设定“私人”用户。具体才说，公共网络封锁住了使用者的帐户和密码以免公开。此外，在企业内部运行的万维网站经常是为其雇员而产生设立的。这些内部私人站点或使用基础设施、因特网标准和万维网的“内部网”是通过防火墙来与公共网络相封锁的。万维网能被当作一种可供选择的便宜而又强有力的通信形式。过剩的企业信息(e.g.程序,训练材料，目录,表格)能经由万维网制作而被转换为电子形式。借助此单一途径，为这些材料维护的费用显著地减少了，这也确保了流通任务的简化。如此一来，企业计算机的一个目的:创造一个公司的大型系统，在其下分布的信息科技系统内的各部分是能被实现的。 42 虽然互联网和内部网能为公司或政府机构提供非常好的利益，但安全威胁依然残留。热心者们往往集中于人或生意上，而忽视了以使用网络作为运行和管理商业安全的方式。已经存在的万维网服务器能有效地提供所有的或不存在访问给一个特别的网站，许多流行的万维网伺候器甚至能更清楚而又细腻地提供访问控制，他们提供非常原始的工具来管理这些单一企业的远程控制。 本文描述了有关基于角色的访问控制和基于角色的访问控制在万维网环境下执行(RBAC/Web)的优势，而且在个别项目中基于角色的访问控制适用于一个企业内网络计算环境。今天在此将会第一次提供给万维网管理人一种核心管理能力和管理使用者访问信息的方式，同时与法规流向保持一致并适应他们的商务要求。虽然本文的焦点在于企业内部网、利益、观念和和基于角色的访问控制在万维网环境下的执行，但对数据的限制访问需要可以应用在公司的因特网环境中。 基于角色的访问控制描述 基于角色的访问控制 (RBAC) 是传统的随意权限控制(DAC) 和强制性的访问控制 (MAC) 的替代品，在商业后成为了一种正在不断吸引人们注意的技 。 在基于角色的访问控制背后的主要推动力是自然的对组织结构进行规定和术 加强企业专项安全性策略的渴望。传统上来说, 安全管理需要把组织的安全政策放置到一个相对低水平的控制上去,传统地存取控制目录。 藉由基于角色的访问控制技术，安全在一个比较接近符合组织结构的水平上被处理。 在角色以组织中的使用者其工作职责和能力为基础的地方，每个使用者被分配一个或多个角色。每个角色又被分配一个或多个权限 (例如数据访问，划除,创造)。 只有进入决定特权使用者的角色范围之内后，使用者的全体操作才被允许。基于角色的访问控制的安全管理使得只有当特定的操作者被判断其动作可以被运行,然后分配职员到适当的角色后才能进行。 基于角色的访问控制结构可以提供给互斥的角色和角色有交叠处理职责的特权。 举例来说，一些一般的操作可能被所有的职员允许,当其他的操作可能是对一个角色的特性时候。 角色层次是在一个组织里面组织角色而且定义关系和角色属性的自然方法。 在基于角色的访问控制软件全部处理后，被互斥的角色或组织角色的复杂引入也调节了谁能运行什么行动,何时, 从哪里, 以什么次序, 和在某些情形之下表示关系的环境。 职责的分离 基于角色的访问控制机制可能被系统管理人用在执行一种政策分立的职责。自从面临在类似的工作或机会中诈骗能够发生后，分立的职责被认为在防止诈骗方面是有价值的。分立的职责必须是为了交易的特殊集合，没有简单单一的被允许去执行所有在集合里的交易。最常用的例子是 43 交易的分期付款和授权付款。没有单个的个体能够运行两个交易。系统管理人对企业传统的处理生意的方式是一个自然而又抽象化的程度控制访问。且由静止又动态地经过角色，角色等级，关系和限制的建立和定义管理使用者的行动被达成了。 我们定义静态职责的分离意味着互斥的给定角色不能同时被包括在用户的授权权限集合里。根据动态的职责分离，用户也许被授权了两个互斥的角色，但是不能同时操控这两个角色。换句话说，当一位管理人建立角色授权的时候，静态职责的分离迫使规则互斥;而当一个用户选择角色的时候，动态职责的分离迫使规则同样互斥。 管理和显示角色 使用基于角色的访问控制/万维网管理工具的角色被建立和操纵。管理工具允许系统管理员产生并且定义角色，角色层次，关系和限制。一旦基于角色的访问控制结构被确定是为了组织，首要的管理行动是用户进入的许可和废除并且缺乏对角色的分配指示。这些维护工作使用管理工具将被容易运行。 另外，管理工具正在被用以提高利用虚拟的真实靠模切语言(虚拟现实建模语言 ,发音 'vermal')。虚拟现实建模语言 是交谈式的、网际企业式的、同时也是用于万维网的3D立体图形语言。它用来表现图形，测试，声音和万维网上任意静态或动态图象的链接内容。基于角色的访问控制的虚拟现实建模语言 让系统管理人使用一个交谈式计算机模型检查，而且使角色结构，关系和特权有效。能够观察和互相影响复杂的模型，允许管理人识别冲突，根除缺点而且早在基于角色的访问控制安装时就对安装启用进行改良。 虚拟现实建模语言 成份将会使经认可的使用者能够执行基于角色的访问控制数据库，发现而且链接角色，而且显示属性和被和那些角色整合的图形。藉由一个确定角色的3D立体模型呈现，用户能很容易地看出哪一个角色是互斥的和在角色之间的相关角色，以及冲突的阶层结构。虚拟现实置标语言的导航控制允许使用者以交互式“初排”而且操纵 3D立体模型的视野远景,即一个场景曲线图。举例来说，当看“平面” 或2 D 曲线图的时候，角色关系可能已经被隐藏的情况下场景曲线图可能被旋转来显示曲线图的“背部”。为了改善可读性、清晰度和适应性，角色层次被组织成层，而每个层又包含着其它级别的细节。通过一个角色，角色能开启和展现相关的角色层或角色信息。例如，与特权相关的角色或一个用户的从属清单。 基于角色的访问控制举例 考虑银行的分公司。 在这环境中,有角色 , 像是部门经理，讲话者和帐户代表。 44 曲线图结构展示了角色的层次，角色financial_advisor继承了角色account_rep。单独被授权的角色financial_advisor被允许进行所有account_rep角色所能进行的活动。因此，被授权的角色financial_advisor能够创建和修改帐户。因为帐户代表，部门经理，内部的审计员和出纳员都是银行的职员,他们的对应角色也继承了职员的角色。 在图2中，角色account_rep是突出的，为了显示其他角色关系，account_rep的表现形式是一个暗球的形状。出纳员角色和account_holder以黄色矩形显示是为了说明这些角色与account_rep有一个“动态权责区分”(DSD)的关系。这个关系是一个抵触的利益关系指标，而account_rep 角色的个体权限不能在另一半的account_holder或teller角色上被给予权限。银行的政策是帐户代表或银行职员能有银行的帐户，但是如此的个体在处理其它的帐户时候不可能同时处理他们的个人帐户。同样的，因为一个出纳员有一个公开的现金抽屉且在关闭时一定结算了。一个坐在远离出纳员桌子上的account_rep角色即使被授权了出纳员的角色也不能同时被允许拥有出纳员的个体行动权限。 角色internal_auditor的表现形式是一个红色的六面体形状是为了说明这些角色与account_rep有一个“静态权责区分”(SSD) 的关系。这个静态权责区分的关系同样是一个和动态权责区分关系一样相互抵触的利益关系，但是这个关系更强劲一些。如果两个角色间有一个动态权责区分的关系，那么他们可能同样被一个个体所授权，但是那个个体不可能同时在两个角色上被运用。如果两个角色间有一个静态权责区分的关系，那么他们不可能同样被一个个体所授权。在这一个例子中，银行的政策是在internal_auditor 和 account_rep的角色之间有一个基本的利害冲突，这二个角色可能无法被相同的个体所授权。 使用虚拟现实建模语言的管理工具的新版本将会允许我们以一种自然的方法表现相互抵触的利益或是其它关系，而且是由无数的情况所组成的。虚拟现实建模语言允许复杂的3D立体物体为这一个目的而被产生。使用者能“进入”一个被挑选出的角色而且探究一些和那个角色相互关联的程度方面的细节(也就是数据)。除此之外，当角色被应用的时候，虚拟现实建模语言的声音能力可能可能被利用上，在引起利害冲突、当不合适的程序被用或其他问题的时候给予声音的警告。 基于角色的访问控制在万维网中的应用 为万维网(RBAC/Web)而设的基于角色的访问控制(RBAC)是万维网(Web)服务器对基于角色的访问控制技术的具体执行。因为RBAC/Web点没有浏览器上的需求, 任何浏览器都能被用于一个特殊的用以增强RBAC/Web服务器的Web服务器。RBAC/Web同时被UNIX(举例来说，对网景，NCSA，CERN 或阿帕契伺候器)和Windows NT(举例来说, 对英特网数据伺候器，网站或承办商)环境所应用 RBAC/Web的组件在表1中被显示。基于UNIX的RBAC/Web可以使用表1中的所有组件。因为内建的NT安全机制与基于角色的访问控制非常适合，NT版本只使用数据库，会话管理员，和管理工具组件。NT的RBAC/Web需要Web伺候器 45 的无修正或原代码的访问。基于UNIX的RBAC/Web有两种途径以UNIX Web服务器来使用RBAC/Web。 最简单的方法是经由RBAC/Web通用网关接口(CGI)。RBAC/Web CGI不修正它的原代码，因而能被任何已存在的UNIX服务器用。RBAC URL被RBAC/Web CGI通过网络服务器来处理。当提供基于用户的角色以访问控制的时候，RBAC/Web配置文件名的网址文件图，RBAC/Web CGI的安装与Web的安装类似。 46