基于mvc架构的网站rbac访问控制框架设计与实现_毕业设计(论文)(编辑修改稿)

基于mvc架构的网站rbac访问控制框架设计与实现_毕业设计(论文)(编辑修改稿)内容摘要：

较主体和客体的敏感标记来决定一个主体是否能 够访问某个客体。 用户的程序不能改变他自己及任何其它客体的敏感标记，从而系统可以防止特洛伊木马的攻击。 强制访问控制一般与自主访问控制结合使用，并且实施一些附加的、更强的访问限制。 一个主体只有通过了自主与强制性访问限制检查后，才能访问某个客体。 用户可以利用自主访问控制来防范其它用户对自己客体的攻击，由于用户不能直接改变强制访问控制属性，所以强制访问控制提供了一个不可逾越的、更强的安全保护层以防止其它用户偶然或故意地滥用自主访问控制。 以上访问控制策略对于处理一些无需保密但又敏感的信息的政府和行业组织的需求并不 是特别的适合。 在这样的环境下，安全目标支持产生于现有法律、道德规范、规章、或一般惯例的高端组织策略。 这些环境通常需要控制个体行为的能力，而不仅仅是如何根据信息的敏感性为其设置标签从而访问这一信息的个人能力。 8 就基于角色访问控制而言，访问决策是基于角色的，个体用户是某个组织的一部分。 用户具有指派的角色（比如医生、护士、出纳、经理）。 定义角色的过程应该基于对组织运转的彻底分析，应该包括来自一个组织中更广范围用户的输入。 访问权按角色名分组，资源的使用受限于授权给假定关联角色的个体。 例如，在一个商务管理系统中，经 理角色可能包括人事管理、工资管理、分配项目等；而一般员工的角色则被限制为仅能浏览自己的一些信息，如基本信息、工资信息和工程项目信息等。 基于角色的访问控制模型 RBAC 比传统的自主访问控制和强制访问控制更优越，同时也提供了更高的灵活性和扩展性。 RBAC 访问控制模型实现了用户与访问权限的逻辑分离，减少了授权管理的复杂性，降低了管理开销和管理的复杂度。 对于现在规模日益增大的基于 MVC 架构的商务信息管理系统来说，采用 RBAC 访问控制模型的访问控制模块将会起到越来越大的作用。 综上分析，控制访问角色的运用是一种开发和 加强企业特殊安全策略，进行安全管理过程流程化的有效手段。 运用 RBAC 模型可以很好的解决 Web 系统中提出的访问控制要求，而 DAC、 MAC 等等访问控制技术由于各种各样的局限性和特性，都不是 WEB 系统下实现访问控制的最好选择。 从目前的应用现状来看，以 MVC 为架构而建成的 WEB 网站特别是商务网站的数量较为庞大，而由于其自身的管理特性，对安全措施的要求也越来越高，这就要求我们找到一种更为有效的权限管理方法去适应网站对访问控制技术的要求。 而 RBAC 作为一种科学、合理、灵活、成熟的访问控制技术，最适合于在 WEB 环境下使 用，所以如何使它应用到那些基于 MVC 架构的网站中去，会是一个具有相当研究价值的课题。 9 第二章 系统框架分析与设计 基于 MVC 架构的 Web 系统 在当前开发的商务系统中，一般都会包括部门管理功能模块，员工管理功能模块，工程项目管理功能模块和员工薪水管理功能模块，以及包括针对员工使用的信息查看模块。 先下面给出一个已经设计完善的基于 MVC 架构的 WEB 网站，系统的功能模块图如图 21所示。 图 21 系统功能模块图 部门管理模块：针对公司内部的所 有的部门进行管理，用户可以方便地添加部门、修改部门信息、删除某一部门和查询某一部门的信息。 员工管理模块：针对公司内部的所有的员工进行管理，用户可以方便地添加员工信息、修改员工信息、删除某一员工信息和查询某一部门的所有员工信息。 工程项目管理模块：针对公司的工程项目进行管理，用户可以方便地添加工程项目信息、修改某一工程项目的信息、删除某工程项目的信息和查询某一工程项目信息。 员工工资管理模块：针对公司内部的所有的员工的薪酬进行管理，用户可以方便地添加工资信息、修改工资信息、删除工资信息和查询某一员工在某段时 间内的所有工资信息。 信息查看模块：针对公司员工设计的功能模块，通过该模块员工可以方便的查看自己的基本信息，工资信息以及所负责的工程项目信息。 系统的功能模块 部门管理模块 员工管理模块 工程项目管理模块 员工工资管理模块 信息查看模块 系统功能管理模块 系统用户管理模块 系统角色管理模块 10 系统功能管理模块：用户可以通过该模块管理系统中涉及到的所有功能，可以添加、删除和修改。 系统用户管理模块：用户可以通过该模块管理系统中涉及到的所有用户，可以添加、删除和修改。 系统角色管理模块：用户可以通过该模块为系统中的不同的用户设置不同的权限，并能够修改某一用户所赋予的权限。 在上述的商务系统中，在安全性上一般会有如下的要求： 能够很好的实现访问控制。 在一个企业 中，存在着很多种不同的用户，如经理、董事长、一般职工，系统维护人员等。 当所有的用户面对同一个系统时，就应该做到用户之间要有区分，即进入系统后不同的用户只能实行自身拥有的权限，不可以越权。 部分信息的保密。 公司中存在着一些决定企业利益的信息，这些信息只能由公司的管理人员来查看和管理，任何非法的侵入都有可能造成不良的后果。 现代主流的 Web 系统的体系架构设计基于 J2EE 平台上的 MVC 设计模式，应用 Struts 框架，采用 B/S 模式，具体的架构设计如图 22 所示。 图 22 商务管理系统架构图 在图 22中，系统架构可以细分为以下 4个层次： 客户层（ Client Layer）：运行在用户机器的浏览器中，处理与用户的交互。 表现层（ Presentation Layer）：运行在 J2EE Web 容器中，产生系统的表现逻辑，处理用户的请求并做出响应；整个 Web 层建立在 Struts 框架基础上，其中 View 由 HTML 和 JSP 页面组成，其数据表示是 ActionForm Bean； Controller由 ActionServlet 组合 和 Action 类组成；而 Model 则交由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 View Java Bean Business Objects Database Layer Business Layer Client Layer Oracle 9i Browser 11 业务逻辑层来实现。 业务逻辑层（ Business Layer）：运行在 J2EE Web 容器中，完成系统的业务需求，为 Web 层提供所需的业务方法，由 JavaBean 构成系统的 Business Objects（ BO），并使用 DAO 模式把数据访问封装起来，以供在其他应用层中统一调用。 数据源层（ Database Layer）：即数据库层，存放系统的应用数据，系统采用 Oracle9i 作为数据库服务器。 系统的架构可以表示为 JSP+Struts+Database。 使用这种架构一方 面便于系统的开发和管理；另一方面，层与层之间的开发几乎是完全独立的，从而降低了数据在各层之间的耦合性，提高了系统的可维护性和可扩展性。 此外，系统是由Java 来开发实现的， Java 的跨平台特性实现了系统的可移植性。 RBAC 模型的建立 根据上述商务系统对安全性的需求，通过在 Web 系统中使用 RBAC 模型可以很好的满足各项需求。 RBAC 的核心思想就是：根据用户需求，给用户分派各种角色，为不同的角色分配各种权限，用户通过自己所属的角色获得操作权限许可。 其核心模型如图23 所示。 图 23 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} 12 R olesU sersUA * ：用户 — 角色分配关系：多对多； Assignedusers： ，角色与用户的映射，将一个角色与一组用户相映射； ：权限 角色分配关系，多对多； Assigned privileges ： ，角色与权限的映射，将一个角色与一组权限相映射； Session ：会话集 {s1， s2， s3，„„， sn } User_sessions ： ，用户与会话的映射，将一个用户与一个会话相映射； Session_roles ： ，会话与角色的映射，将一个会话与一组角色相映射； Avail_session_privilege ： ，在一次会话中一个用户允许的权限； 用户：不仅指人，也可以指机器，网络或智能代理。 角色：管理员依据安全策略划分出来的操作集合，表示该角色 成员所授予的职权和责任。 客体：指系统需要保护的资源。 权限：对系统中的客体进行特定存取的许可。 权限是与客体紧密相关的，不同的系统，其权限规定是不同的，既可以指网络的应用，如对某个子网的访问权限，也可以指对数据库的表单等的访问。 权限的粒度大小取决于实际系统的定义。 会话：为了对系统资源进行操作，用户需要建立会话，每个会话将一个用户与他所对应的角色集中的一部分建立映射关系，这一角色子集成为被会话激活的角色，在这次会话中，用户可以执行的操作就是该会话激活的角色对应的权限所允许的操作。 上述 RBAC 模型是 RBAC 核心模型，此模型保留了 RBAC 的最小特征集，是每个 RBAC 系统都需要的元素。 RBAC 模型在 MVC 网站中的应用 由需求分析可知，需要为企业内部网管理系统设计一个用户权限管理的功能模块，从而达到对用户权限进行管理的目的。 当今的大型的信息管理系统都具有 13 功能复杂，用户众多的特点，如果仍采用传统的权限管理方式，直接将权限分配给用户，对具有相同权限的一类用户同样的授权操作将被重复很多遍，一旦用户工作岗位有变化，则对其权限的调整将非常复杂，而基于 RBAC 模型的权限控制方法则大大简化了这种授权管理的复杂度，降低了 系统管理的开销。 RBAC 模型描述了一种良好的访问控制方法和原理。 通过在商务 Web 系统中使用 RBAC 模型可以方便、科学、合理地进行访问控制，有了良好的访问控制，不同的用户在使用系统的时候仅能访问自身被赋予的权限，用户之间不能越权访问，从而保证了信息的安全性和一致性，从而提高了系统的安全性。 通过以下几个步骤，可以将 RBAC 模型应用在 MVC 网站中。 （ 1）建立功能的概念。 功能，即操作。 在系统中，如对员工的添加、删除和修改的操作，都可以描述为一个功能。 （ 2）建立权限节点的概念。 权限节点，顾名思义，它对应着一个 或一组功能操作菜单，表示了该节点可以进行系统操作的范围。 （ 3）建立角色的概念。 将角色与节点对应起来，一个角色可以对应多个节点，一个节点也可以对应多个角色，这是一个多对多的关系。 角色与节点对应好之后，也就意味着角色与某一个或某一组功能操作菜单建立了关联。 系统中存在不同类型的用户，也即不同的用户隶属于不同的角色。 （ 4）将系统的用户和角色关联起来。 一旦一个用户被设置了某个角色，那么也就意味着该用户具有了某些权限。 具有了某些权限，也就意味着拥有了某些功能（对系统的操作和管理）。 举例来说，假设系统中存在两个权限 节点 1和 2，两个角色 A 和 B，用户有甲（经理）和乙（部门经理），很显然甲和乙在登陆系统后应该具有不同的权限，甲可以管理整个公司的信息，而乙仅能管理所在部门的信息。 这时，设定权限节点 1 下包含了管理整个公司信息的所有功能，权限节点 2下包含了管理某个部门信息的所有功能；将角色 A 与节点 1进行关联，将角色 B与节点 2 进行关联。 最后，将用户甲的角色设定为角色 A，用户乙的角色设定为角色 B。 在用户甲和乙登陆系统后，就会看到自己所具有的功能菜单，其他用户的功能菜单是非可见的，从而实现了访问控制。 简言之，通过在系统中设置功能、权 限和角色的概念，就可以在系统中实现RBAC 模型，并让它很好地为 Web 系统提供访问控制功能。 14 第三章 设计实现 RBAC 框架实现 数据存储是个非常重要的功能需求。 系统中很多的地方都要存储数据，并且其格式要求也不相同，数据量也差别较大。 良好的设计不但能减少因数据保存不当造成的对系统的损害，而且能显著地提高系统的性能。 在考虑数据存储方案时，有三种可行的选择。