Security Weaver原型研究.pdfVIP

维普资讯 2006年第3期 《贵州电力技术) (总弟81期) SecurityWeaver原型研究 天津大学 李寓星 [30oo72] 问题，安全问题 ，它体现的一种对访问的控制。访问 l 前言 控制模型在学术界有广泛的研究和讨论。基于角色 安全是企业应用中一个很重要的因素，虽然有 的访问控制模型已经在linux操作系统中得到成功 诸如JAAS等技术，但在企业应用的实现中，关于安 的应用。图1是一个被广泛引用的访问控制模型。 全的大部分代码还是硬编码的，更重要的是，这些代 其中角色具有层次性和继承性的。角色可以授予某 码是凌乱地散布在系统地各个层面，难以理解和维 种权限(Permission)。权限是角色对某种资源 (如功 护，当企业的安全策略发生变化时，对程序的修改是 能模块、系统组件、系统数据等)的一种操作(如对数 一 件让人很苦恼的事情。本文从企业对安全的实际 据的添加、删除、修改、读取等操作，对组件和接口的 需求出发，试图提供一种可复用的能快速适用企业 访问操作)用户属于某个角色，自然拥有了该角色所 需求变化的安全实现模型，它的名字叫Security 有的权限。权限是有约束的(Constraints)，约束和当 Weavero 前的会话(session)有关。会话是在用户登陆系统时 建立的一个状态信息，包含用户 ID、角色、系统时间 2 需求分析 等。分析可以看出，这个模型对于企业级别的应用 首先来看一组与安全有关的场景。 来说，已经够用了。之所以在此给出这样一个抽象 场景 1：用户只能操作自己权限范围内的数据。 的模型，是为了加深对问题本质的理解，在下文我们 例如ERP系统中“采购计划的制定”中，有计划的查 还将用到这一模型。 询功能。用户要求在查询的结果中都是自己权限范 围内的采购计划。如：负责非金属器材的计划员查 不到负责有色金属的计划员制定的计划，也不能修 改和删除其它计划员制定的计划。 场景2：用户只能操作权限范围内的实体的属 性。例如在ERP系统中，器材实体有很多属性(字 段)，不同的角色能够操作的字段是不同的。例如： 计划员能够修改器材的基本属性，不能修改诸如采 购限价等属性。 场景3：用户的操作权限随条件改变而改变。 例如：在ERP系统中，计划员能够制定计划，在计划 被审批之前，能够修改计划的内容。但当计划已经 进入审批状态，则无法修改，或者无法修改某些字 段。 图1 基于角色的访问控制模型 场景4：对组件的访问是有限制的。对于一些 3 安全的常用实现 敏感组件或者组件的敏感方法。往往需要设置访问 安全的实现似乎再也简单不过。 的权限，只有特定的角色才能够访问这些方法。 例如：对组件的访问 场景 5：不同角色拥有不同的系统模块。不同 角色登陆系统，能够操作的模块是功能模块是不同 If(get．Role(uscrld)．equ~ (“someRole”)) { 的。 ／／invokebusinessmethod 其它的场景还很多。它们都涉及到一个共同的 · 36 ·