基于MVC架构的网站RBAC访问控制框架设计与实现毕业论文设计40论文41文档格式.docx

基于MVC架构的网站RBAC访问控制框架设计与实现毕业论文设计40论文41文档格式.docx

《基于MVC架构的网站RBAC访问控制框架设计与实现毕业论文设计40论文41文档格式.docx》由会员分享，可在线阅读，更多相关《基于MVC架构的网站RBAC访问控制框架设计与实现毕业论文设计40论文41文档格式.docx（40页珍藏版）》请在冰豆网上搜索。

企业网站大部分属于商务网站，企业通过利用Web系统，可以方便的发布产品信息，管理订单信息，管理内部的诸如人事、员工薪酬信息等。

从而在一定程度上提高工作和管理效率，降低生产和管理成本。

现在用来建立Web站点的工具和编程语言主要有ASP、PHP和JSP，使用的设计模式是MVC。

MVC作为构建网站系统的主流设计模式，有其自身的特点和优势，具体表现在：

（1）可以为一个模型在运行时同时建立和使用多个视图。

变化-传播机制可以确保所有相关的视图及时得到模型数据变化，从而使所有关联的视图和控制器做到行为同步。

（2）视图与控制器的可接插性，允许更换视图和控制器对象，而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。

（3）模型的可移植性。

因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。

需要做的只是在新平台上对视图和控制器进行新的修改。

（4）潜在的框架结构。

可以基于此模型建立应用程序框架，不仅仅是用在设计界面的设计中。

基于MVC模式建设Web站点系统，可以提高代码的重用性；

可以提高代码的可维护性；

可以提高编写程序的效率。

所以目前，越来越多的网站开始采用MVC模式来进行架构，但是在这其中，对于系统安全性问题的研究还进行的不多。

在构建Web系统之初，就要考虑系统的安全性，考虑用户对系统的访问控制。

通过访问控制，一方面只有合法的用户才可以安全、正确的使用系统，非法的用户是无法登陆系统进行操作；

的；

另一方面合法的用户登录系统之后，由于用户的类型不同，就会存在不用的用户在访问系统时具有不同的权限，比如一个企业或公司的经理往往会比企业或公司的员工具有更多的权限和功能，相应的用户登录系统之后，他们只能行使系统准许他们的权限。

纵观现在的Web系统，大都存在这样的问题：

功能虽强大，但是却存在很多的安全隐患。

系统中的不同类型的用户对信息都具有相同的权限，可以任意的修改和删除，这对于一些重要的信息是非常危险的。

对信息的科学管理，应该是最高层的用户拥有对信息最高的权限，而处于底层或次底层的用户仅拥有对信息最少的权限。

此外，现在大部分Web系统中都缺少一个良好的访问控制模块。

在该模块中，可以为系统设定不同的用户，分配不同的权限。

将系统中的用户和系统中的权限关联起来，形成一种有效的系统安全管理。

综上所述，企业在构建自身的商务Web系统时，在考虑功能完整性和操作简便性的同时，还应重点考虑构建的Web系统的安全性。

只有在保证了安全性的前提下，功能的完整性和操作的简便性才变得有意义。

1.2RBAC模型概述

1.2.1RBAC原理简介

1992年，美国国家标准与技术研究所（NIST）的DavidFerraiolo和RickKuhn在综合了大量的实际研究之后，率先提出基于角色的访问控制模型框架，并给出了RBAC模型的一种形式化定义。

该模型第一次引入了角色的概念并给出其基本语义，指出RBAC模型实现了最小权限原则（theleastprivilege）和职责分离原则（separationofduty）。

该模型中给出了一种集中式管理的RBAC管理方案。

1995年他们以一种更直观的方式对该模型进行了描述。

RaviSandhu和他领导的位于GeorgeMason大学的信息安全技术实验室（LIST）于1996年提出了著名的RBAC96模型，将传统的RBAC模型根据不同需要拆分成四种嵌套的模型并给出形式化定义，极大的提高了系统灵活性和可用性。

1997年他们更进一步，提出了一种分布式RBAC管理模型DRBAC97，实现了在RBAC模型基础上的分布式管理。

这两个模型清晰的表征了RBAC概念并且蕴涵了他人的工作，成为RBAC的经典模型。

绝大多数基于角色的访问控制研究都以这两个模型作为出发点。

在RBAC中，涉及到的基本概念如下：

用户（User）：

系统的使用者。

可以是人、计算机、机器人等，一般指人。

角色（Role）：

一定数量的权限的集合。

权限分配的单位与载体，目的是隔离用户与权限的逻辑关系。

对应于组织中某一特定的职能岗位，代表特定的任务范畴。

角色的例子有：

经理、采购员、推销员等。

权限（Permission）：

表示对系统中的客体进行特定模式访问的操作许可，例如对数据库系统中关系表的选择、插入、删除。

在应用中，许可受到特定应用逻辑的限制。

用户指派（UserAssignment）：

用户与角色之间的关系是多对多的关系。

用户指派指根据用户在组织中的职责和能力被赋为对应角色的成员。

用户通过被指派到角色间接获得访问资源的权限。

权限指派（PermissionAssignment）：

角色与权限之间的关系也是多对多的关系。

权限指派指角色按其职责范围与一组操作权限相关联。

进行权限分配时，应遵循最小特权原则（theLeastPrivilegeRule），即分配的权限集既能保证角色充分行使其职权，又不能超越职权范围。

角色激活（RoleActivation）：

是指用户从被授权的角色中选择一组角色的过程。

用户访问的时候实际具有的角色只包含激活后的角色，未激活的角色在访问中不起作用。

相对于静态的角色授权来说，角色激活是一种动态的过程，提供了相当的灵活性。

会话（Session）：

用户是一个静态的概念，会话则是一个动态的概念。

一次会话是用户的一个活跃进程，它代表用户与系统进行交互，也叫主体（Subject）。

用户与会话是一对多关系，一个用户可同时打开多个会话。

活跃角色集（ARS）：

一个对话构成一个用户到多个角色的映射，即会话激活了用户授权角色集的某个子集，这个子集被称为活动角色集，ARS决定了本次会话的许可集。

在RBAC中，它遵循如下的基本原则：

角色继承（RoleInheritance）

为了提高效率，避免相同权限的重复设置，RBAC采用了“角色继承”的概念，定义了这样的一些角色，他们有自己的属性，但可能还继承其他角色的属性和权限。

角色继承把角色组织起来，能够很自然地反映组织内部人员之间的职权、责任关系。

最小权限原则（theLeastPrivilegeRule）

所谓最小权限原则是指：

用户所拥有的权力不能超过他执行工作时所需的权限。

实现最小权限原则，需分清用户的工作内容，确定执行该项工作的最小权限集，然后将用户限制在这些权限范围之内。

在RBAC中，可以根据组织内的规章制度、职员的分工等设计拥有不同权限的角色，只有角色需要执行的操作才授权给角色。

当一个主体预访问某资源时，如果该操作不在主体当前活跃角色的授权操作之内，该访问将被拒绝。

职责分离（SeparationofDuty）

对于某些特定的操作集，某一个角色或用户不可能同时独立地完成所有这些操作。

职责分离的概念包括：

多路共享资源，用功能分解命名互相区分的权限集，对用户进行强制分类，允许层次性的分解权限。

1.2.2RBAC适用性分析

在RBAC模型中，一个用户通过用户授权获得一个或者几个角色，但角色不能被同时激活；

一个角色可以被同时授予多个用户；

每个角色有一个或多个节点，一个节点也可以被赋予多个角色；

每个节点有一个或者多个功能，一个功能可以被同时挂在不同的节点上，而节点可以有子节点，子节点也可以再有子节点；

一个功能对应一个或多个页面；

一个页面有一个或多个操作。

这样每个用户登录时就可以根据角色得到一棵功能树从而使用系统中的资源。

为更真实的描述现实，RBAC模型还有许多的控制机制。

如对Web页面多维度和细粒度控制，对角色、功能、节点的静态限制和对角色的动态限制。

对页面的限制主要是限制用户在特定时间和特定地点所能看到的功能和所能进行的操作。

其他限制主要是在功能被赋予节点时、节点被赋予角色时和角色被赋予用户时的限制。

模型中有了这些限制才更完整、更真实地反应现实，从而使实际模型细化的过程更加平滑，现实和计算机实现策略达到较好的融合。

页面是Web应用系统中最重要的元素，控制页面访问是整个系统安全的重要条件。

对页面的访问控制可以从时间和空间两个方面来进行，对页面功能和数据的访问，可以通过用户登录后所带session中的信息进行控制。

时间约束分为一般时间约束和周期时间约束两种。

一般时间约束是指从一个时间点持续到另一时间点之间可以访问某个页面，例如，企业商务系统中的商品招标页面，它在某一指定时间段内开放，对这种约束可以在用户访问网页的时候判断访问时间是否在允许范围内。

周期时间约束是指对那些功能和数据周期性开放的页面进行访问控制。

空间约束主要是对用户在不同地方（网段）登录所能看到的页面以及页面能提供的信息进行控制。

例如，管理部门内部事务所对应的页面通常对用户所在的访问位置有较严的限制。

一般系统的高层用户都有一个固定的IP段，就可以对那些重要的页面设置允许访问的IP范围来达到对关键资源的保护。

对页面的空间约束可以分成分网段、分楼层、分房间、分IP地址等不同层次的控制。

对页面功能和数据的访问需要知道用户的大概类型，主要包括管理员、部门管理员、一般职工、游客（企业或单位以外的人员）等。

用户登录后将用户的类型保存到session中，在用户访问页面时就可以根据用户的不同类型，以及他们对时间、空间等硬性约束的满足情况来显示相应的功能和数据。

通过了解RBAC模型的原理和RBAC模型中对访问控制的支持，我们可以看出，RBAC模型可以很好的应用于已有或将要开发的企业商务Web系统中。

通过在系统中使用RBAC模型，可以很好的解决如下的问题：

权限管理混乱的问题。

通过在系统中增加角色这个概念，很好的解决了这个问题。

在RBAC模型中，可以利用角色与系统中的所有权限关联，使得某种角色具有某种特定的权限，从而在为用户设定好相应的角色之后，也就意味着得到了相应的系统权限。

控制逻辑混乱的问题。

通过使用RBAC模型，可以避免在系统中书写负责的控制逻辑来进行访问控制。

尤其当系统设计的用户和角色比较多时，单纯的依靠代码进行访问控制将变得相当困难。

换句话说，RBAC模型为我们提供了良好的访问控制支持。

在企业商务Web系统中利用RBAC模型，可以简便、科学、清晰地进行访问控制，从而在一定程度上提高了整个Web系统的安全性。

1.3RBAC在MVC中的应用现状

网站程序的安全是系统开发人员必须考虑的重要因素之一，因为这涉及到网站的建设者、网站用户的诸多安全问题，如果不处理好，可能会给系统的使用者和管理者带来严重问题。

现在普遍在使用的安全措施有如下几种：

（1）防止SQL注入

比如URL、表单等提交信息时，通过一段防止SQL注入的过滤代码即可防止出错信息暴露，或者通过转向，当系统出错时转到一个提示出错的页面等。

对于文本型输入，如果要进行检查，就得根据字段本身的性质进行。

例如如果是年龄，就得限定必须是数字，大小必须限定在一个范围之间，比如说18-120之间。

对于用户名，应该建立一个集合，这个集合里存放有被允许的字符，或被禁止的字符。

（2）验证码技术

所谓验证码，就是将一串随机产生的数字或符号，生成一幅图片，图片里加上一些干扰象素，由用户肉眼识别其中的验证码信息，输入表单提交网站验证，验证成功后才能使用某项功能。

放在会员注册、留言本等所有客户端提交信息的页面，要提交信息，必须要输入正确的验证码，从而可以防止不法用户用软件频繁注册，频繁发送不良信息等。

（3）MD5加密技术

MD5的全称是Message-DigestAlgorithm5，当用户登录的时候，系统把用户输入的密码计算成MD5值，然后再去和保存在文件系统中的MD5值进行比较，进而确定输入的密码是否正确。

通过这样的步骤，系统在并不知道用户密码的明码的情况下就可以确定用户登录系统的合法性。

这不但可以避免用户的密码被具有系统管理员权限的用户知道，而且还在一定程度上增加了密码被破解的难度。

（4）数据备份

一般采用数据库系统自动定时备份、定时自动删除几天以前的数据等，即可完成数据的备份功能。

而图片、文件一般是不能自动备份，需要手工操作，所以我们必须要定期手工对网站的图片、文件进行备份操作。

访问控制技术是由美国国防部（DepartmentofDefense,DoD）资助的研究和开发成果演变而来的。

这一研究导致两种基本类型访问控制的产生：

自主访问控制（DiscretionaryAccessControl,DAC）和强制访问控制（MandatoryAccessControl,MAC）。

最初的研究和应用主要是为了防止机密信息被XX者访问，近期的应用主要是把这些策略应用到为商业领域。

自主访问控制，允许把访问控制权的授予和取消留给个体用户来判断。

为没有访问控制权的个体用户授予和废除许可。

自主访问控制机制允许用户被授权和取消访问其控制之下的任何客体（object），换句话说，用户就是他们控制下的客体的拥有者。

然而，对于多数组织来说，最终用户对所访问的信息没有拥有权。

对于这些组织，公司或代理机构是事实上的系统客体和处理他们的程序的拥有者。

访问优先权受组织控制，而且也常常基于雇员功能而不是数据所有权。

强制访问控制，在美国国防部TrustedComputerSecurityEvaluationCriteria（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框架，采用BS模式，具体的架构设计如图2-2所示。

图2-2商务管理系统架构图

在图2-2中，系统架构可以细分为以下4个层次：

客户层（ClientLayer）：

运行在用户机器的浏览器中，处理与用户的交互。

表现层（PresentationLayer）：

运行在J2EEWeb容器中，产生系统的表现逻辑，处理用户的请求并做出响应；

整个Web层建立在Struts框架基础上，其中View由HTML和JSP页面组成，其数据表示是ActionFormBean；

Controller由ActionServlet组合Struts-config.xml和Action类组成；

而Model则交由业务逻辑层来实现。

业务逻辑层（BusinessLayer）：

运行在J2EEWeb容器中，完成系统的业务需求，为Web层提供所需的业务方法，由JavaBean构成系统的BusinessObjects（BO），并使用DAO模式把数据访问封装起来，以供在其他应用层中统一调用。

数据源层（DatabaseLayer）：

即数据库层，存放系统的应用数据，系统采用Oracle9i作为数据库服务器。

系统的架构可以表示为JSP+Struts+Database。

使用这种架构一方面便于系统的开发和管理；

另一方面，层与层之间的开发几乎是完全独立的，从而降低了数据在各层之间的耦合性，提高了系统的可维护性和可扩展性。

此外，系统是由Java来开发实现的，Java的跨平台特性实现了系统的可移植性。

2.2RBAC模型的建立

根据上述商务系统对安全性的需求，通过在Web系统中使用RBAC模型可以很好的满足各项需求。

RBAC的核心思想就是：

根据用户需求，给用户分派各种角色，为不同的角色分配各种权限，用户通过自己所属的角色获得操作权限许可。

其核心模型如图2-3所示。

图2-3RBAC模型

核心RBAC模型的组成部分是：

Users：

用户集{u1，u2，u3……，un}；

Roles：

角色集{r1，r2，r3，……，rn}；

OPS：

操作集{op1，op2，op3，……，opn}

OBJ：

客体集{obj1，obj2，obj3，……，objn}

P=