专利名称：用于软件应用程序的自动配置的方法和系统的制作方法
技术领域：
本发明涉及信息技术领域。更具体地，本发明涉及软件应用程序的配置。
背景技术：
软件应用程序的配置是非常复杂的任务。典型的情况(scenario )是用于 软件应用程序的正确操作的安全需求的定义。
例如，软件应用程序可用Java语言编写。Java应用程序运行于Java虚 拟机(JVM)中，该虚拟机由提供独立于底层(硬件和软件)平台的运行时 环境的抽象计算机器组成。这允许在任何类型的计算机(假设要求的JVM可 用)上虚拟地运行Java应用程序。由于这个原因，Java应用程序在因特网中 已经找到了广泛使用。每当Java应用程序必须对受保护资源执行特定操作(例 如，读或写文件)时，必须为该操作授权相应权限。在Java环境中，所有可 用的权限在称为策略文件(或更多)中定义。因此，当部署新的Java应用程 序(或其新版本)时，有必要确保其正确操作要求的权限在策略文件中定义。
然而，策略文件的组成显然不平常。实际上，为了这个目的，操作者必 须(根据相应的语法)为每个要求的权限将特定的条目添加到策略文件。
一些图形工具(如装载JSDK的"策略工具")可用来便利编辑策略文件 的任务，而不需要知道它的语法。
无论如何，这种任务实质上保留手动(然后强烈地依赖于操作者的技术 并且倾向于错误)。
此外，非常难以(如果不是不可能的)先验地(apriori)识别Java应用 程序要求的的所有权限。因此，可能发生一些权限丢失；这种情况下，当在 运行时调用需要丢失权限的操作时，启动(throw)相应的异常。典型地，该 异常到达执行栈的底部(因为它不能在Java应用程序自身内管理)，因此， 导致整个Java应用程序中的故障。然后，操作者必须停止该Java应用程序， 将丢失^J艮添加到策略文件，然后重启Java应用程序。
然而，上述"反复试验(trial and error)"步骤非常耗时。此外，这对Java 应用程序的可靠性具有有害作用。
US-B-6，526,513公开了用于动态管理权限的解决方案。这种情况下，当 Java应用程序需要在策略文件中没有定义的权限时，在运行时提示用户授权 或拒绝要求的权限；授权的或拒绝的权限还可以保存，以便遍及不同对话 (session)生效。该引用文献在策略文件中还引入了拒绝权限的概念，以便 允许授权权限给受保护资源的大量集合，除了它们的少数。
然而，提出的技术需要定制安全管理器的定义(代替用于在Java环境中 管理权限的标准安全管理器)。无论如何，在策略文件中静态地定义大量权限 的问题还没有解决(具有上面指出的缺点)。
发明内容
概括地说，本发明基于软件应用程序的自动配置的思想。 具体地，本发明提供了如在独立权利要求中提出的解决方案。在从属权 利要求中描述了本发明的优选实施例。
更具体地，本发明的 一方面提供了 一种用于配置软件应用程序的方法。 该方法从在数据处理系统上运行软件应用程序的步骤开始。该软件应用程序 的多个操作被调用；每个操作的执行需要软件应用程序的配置特征。该方法 通过验证用于每个操作的配置特征的可用性继续。每个不可用配置特征的指 示日志记录。同时，模拟每个不可用配置特征的可用性，以便使能相应操作 的执行。然后，执行每个操作。最后，该软件应用程序根据日志记录的不可 用配置特征被配置。
优选地，提出的解决方案被应用于权限定义以执行要求的操作。 这种情形下，任何被拒绝的要求的权限被日志记录；同时，强制授权相 同要求的权限。
例如，提出的解决方案可用于定义存储可用的权限的安全结构。 典型地，日志记录的被拒绝的权限然后添加到安全结构。 例如，设计的技术被用来构成用于Java应用程序的策略文件。 作为进一步改进，通过安全管理器的打包器获得该结果。 典型地，上述处理在测试环境中执行。
本发明的另 一方面提出 一种用于执行上述方法的计算机程序。 本发明的另 一方面提出 一种相应系统。
参照以下详细的、要结合附图阅读的描述(给出完全作为非限制性指示)，
将最好地理解本发明自身及其进一步特征和优势，在附图中
图1是数据处理系统的示意性方框图，在该数据处理系统中可应用根据
本发明实施例的解决方案；
图2a-2b图示了根据本发明实施例的解决方案的示例性应用程序；
图3是表示实现根据本发明实施例的解决方案的不同组件的角色的合作
图；以及
图4a-4b显示了描述涉及实现根据本发明实施例的解决方案的各活动 流程的图。
具体实施例方式
具体参照图1,图示了计算机100。例如，计算机100包括因特网中的服 务器。服务器100为各客户端提供共享资源，各客户端通过电信网络(未在 图中示出)访问它们；例如，服务器100运行一个或多个web应用程序(如 用Java语言编写的)。
更具体地，服务器100由并联连接到系统总线105的几个单元形成。详 细地，多个微处理器(jaP) 110控制服务器100的操作；RAM 115由微处理 器110直接用作工作存储器，以及ROM 120存储用于服务器100的自举 (bootstrap)的基本代码。几个外围单元(通过各自的接口 )群集在局部总 线130周围。详细地，大存储器由硬盘135的库和用于读取CD-ROM 145的 驱动器140组成。此外，服务器100包括输入单元150 (例如，键盘和鼠标) 和输出单元155(例如，显示器和打印机)。网络适配器160用于将服务器100 连入因特网。桥单元165将系统总线105与局部总线120接口。每个微处理 器110和桥单元165能作为主代理操作，请求访问系统总线105来传送信息。 仲裁器170管理互斥访问系统总线105的授权。
现在考虑图2a,上述服务器必须运行普通的软件应用程序205 (由讨论 的示例中的Java应用程序组成)。应用程序205可要求对受保护资源执行操 作，如读或写文件、打开插口 (socket)等(如由讨论的示例中的相应的Java API的调用定义的)。为了这个目的，用于该操作的权限必须授予应用程序
205。
用于所有受保护资源的可用权限(通常以Peraii表示)存储在安全结构 210 (在Java应用程序的情况下由策略文件组成)中；安全结构210必须用 应用程序205要求的所有权限来预定义，以允许它的正确操作。
如以下详细描述的，在根据本发明实施例的解决方案中，通过运行应用 程序205 (例如，在测试环境中)自动构成安全结构205。
简单地说，每当应用程序205需要对受保护资源执行特定操作时，相应 的权限被要求。如果要求的权限在安全结构210中可用，则该权限照常授权 给应用程序205。相反地，丢失的权限被添加到输出结构215 (如日志文件)； 总之，所需权限被授权给应用程序205 (在安全结构210中模拟它的可用性)。 因此，在应用程序205运行的最后，输出结构210将包括所有丢失权限(通 常以PemV表示)，其由应用程序205要求，但在安全结构210中不可用。
移到图2b,将输出结构215中的丢失权限Peraii，添加到安全结构210。 这样，安全结构210包括应用程序205要求的所有权限。因此，假定访问受 保护资源的应用程序205的所有操作都被调用，安全结构210现在包括用于 应用程序205正确操作要求的所有权限(或至少它们的大多数)。这样获得的 具有安全结构210的应用程序205,现在能部署到生产环境用于它的实际使 用。
提出的解决方案有力地便利安全结构210的定义。
具体地，构成安全结构210的任务目前(至少部分)是自动的；因此， 得到的结果实质上独立于任何操作员的技巧，然后减少错误的倾向。
这样，可以确保确定安全结构210包括应用程序205要求的所有4又限(或 至少它们的大部分)。这有利地限制了运行时应用程序205的故障(由于丟失 权限)，以及操作者的介入来解决各问题。
所有上述内容显著地减少了配置应用程序205 (用要求的安全结构210 )、 用于它的正确操作的整个处理的长度；此外，这对应用程序205的可靠性具 有有益的影响。
现在参照附图3,运行在服务器上的主要软件部件以参考标记300表示 为整体。当程序运行时，信息(程序和数据)典型地存储在硬盘上，并加载 (至少部分地)到服务器的工作存储器中。程序最初从例如CD-ROM安装到 硬盘上。具体地，该图描述了系统的静态结构(通过相应的各模块)和它的动态行为(通过一连串交换消息，每条消息表示以符号"A"开头的序列号 表示的相应动作)。
具体地，操作系统303 (如Linux )为服务器提供软件平台，在该系统之 上能运行其它程序。具体地，Java运行时环境(JRE) 305安装在操作系统303 上。JRE 305定义用于运行Java应用程序310的标准平台。
JRE 305包括不同的模块，如JVM、 Java核心类和支持文件(未在图中 示出)；更具体地参照涉及描述的本发明实施例的各模块，JRE 305包括负责 控制对服务器受保护资源的任何访问的安全管理器315;具体地，安全管理 器315从Java应用程序310接收对各权限(对受保护资源执行操作所需)的 所有要求，并返回相应结果(即，授权或拒绝权限)。为此目的，安全管理器 315加载策略文件320 (或更多)的内容。根据默认，JRE 305包括单个系统 范围的策略文件；可选地，用户策略文件也可动态地增加或指定。
策略文件320静态地定义所有可用于对受保护资源执行特定操作的权 限。这样，只有在策略文件320中用于该操作的相应权限是可用的，才能执 行每个操作(访问受保护资源)；唯一的异常是每个Java应用程序310总是 自动地授权从Java应用程序310的相同位置(即，它的URL)读取文件，而 不需要任何明确的权限。
策略文件320可包括密钥存储(keystore )条目以及任意数目的授权条目。 密钥存储条目(以关键词"密钥存储，，开头)用来指定私有密钥、以及认证 相应的公共密钥的相关联的数字证书的数据库，其被用于验证授权条目的签 名者；数据库通过它的位置(即，URL)和它的类型(如"JKS")来定义。 当被它们的代码源(由类"代码源"的对象表示)识别时，每个授权条目(以 关键词"授权"开头)替代指示一组对被授权给特定Java应用程序的受保护 资源的操作。通过Java应用程序的位置("代码基础(CodeBase )"名称/值对) 和/或通过它的签名者("签名由(signedBy)"名称/值对)，在授权条目中指 定代码源；具体地，通过别名(或更多)识别签名者，用于存储在密钥存储 条目的数据库中的证书(意味着在该证书中，Java应用程序的JAR文件必须 用对应于公共密钥的私有密钥签名)。结果，可以授权权限给来自特定位置和 /或由特定签名者签名的Java应用程序(当它们都没有被指定时，用授于每个 人的权限)。于是，授权条目包括一个或多个权限条目(包围在"{"和"}" 之间)。每个权限条目(以关键词"权限"开头)指定被授权的特定操作。为此目的，权限条目通过权限类(如I/O操作)、该操作的可能动作(如读取)、 以及可选地权限类自身的签名者("签名由"名称/值对)，指示操作类型。
在根据本发明实施例的解决方案中，用于安全管理器315的打包器 (wrapper) 325被添加(在测试环境中)。打包器325遮蔽外界保护安全管理 器315,从而用作安全管理器315和Java应用程序310之间的接口。在这种 特定的上下文中，打包器325暴露与安全管理器315相同的接口 (使得它的 存在对于Java应用程序310完全不透明)；因此，打包器325接收来自Java 应用程序310的所有权限请求，并且返回相应的结果(代替安全管理器315 )。
打包器325被用来自动地构成用于通常Java应用程序310的策略文件 320。为此目的，运行Java应用程序310;每当必须对受保护资源执行特定操 作时，Java应用程序310提交相应的权限请求给打包器325(动作"A1.提交")。 打包器325将该权限请求转发给安全管理器315 (动作"A2.转发")。安全管 理器315验证要求的权限在策略文件320中是否可用(动作"A3.验证")；验 证结果(即，授权或拒绝)由安全管理器315返回到打包器325 (动作"A4. 返回")。如果要求的权限因为它在策略文件320中不可用而被拒绝，则打包 器325将丟失的权限添加到日志文件330 (动作"A5.添加")；同时，权限请 求的响应被强制授权(动作"A6.授权")。这样获得的对权限请求的响应，然 后从打包器325返回到Java应用程序310 (动作"A7.返回")；这样，Java应 用程序310总是授权给要求的权限(通过安全管理器315或打包器325 ),使 得其操作能继续而没有任何问题。在Java应用程序310运行的最后，比较工 具335将丢失的权限(在日志文件330中)添加到策略文件320，以便(在 生产环境中)包括Java应用程序310的正确操作要求的所有权限(或至少它 们的大部分)。
这样，无需替代安全管理器315就达到期望的结果。实际上，提出的技 术只需在测试环境中(用打包器325 )打包安全管理器315,用于构成策略文 件320;然而， 一旦期望的策略文件320已经定义，(标准)安全管理器315 (不用打包器325 )能照常使用。
转到图4a-4b,用方法400表示了示例性处理的逻辑流程，其能够在上 述系统中实现以定义用于一般Java应用程序的策略文件。
该方法从Java应用程序的浮动通路(swim-lane)中的启动块403开始。 转到块406, Java应用程序开始。在该阶段，创建了要求的JVM,并且初始化相应的JRE。具体地，这包括类"策略"的对象的创建，该类执行对访问
服务器的受保护资源的控制。在根据本发明实施例的解决方案中，该对象由 依次创建实际的安全管理器的打包器组成。通常，安全管理器然后从策略文
件中读取可用的权限(使得它们保持不变直到其重新加载或外在刷新)；同时， 安全管理器将类"保护域"的对象(如果它还不存在)关联到加载的Java应 用程序的每个类，以便将授权权限与相应的代码源耦合，内核异常和信任类 不需要任何明确权限。
Java应用程序的运行继续到块409。对于Java应用程序要求的每个操作， 该方法然后在块412分支。如果操作调用受限于安全约束的Java API,则执 行块413-442，然后活动流程传到块445;相反，(从块412)直接到达块445。
现在考虑块413,当Java应用程序需要对受保护资源执行操作时，相应 的权限请求提交给打包器(通过用要求的权限作为自变量(argument)调用 方法"获得权限")。在块415，打包器将权限请求转发到安全管理器(通过 对其调用相同方法)。
响应于此，安全管理器在块418验证要求的权限在策略文件中是否可用 (如在与相应代码源相关联的对象中指示的)。然后，根据验证结果处理在块 421分支。具体地，当来自该位置和/或由Java应用程序的签名者签名的代码 源的授权条目存在时，安全管理器在块424授权要求的权限；该授权条目必 须依次包括在权限请求中指定的操作类型的权限条目(具有操作的动作以及 权限类的签名者的可能指示)。相反，在块427安全管理器拒绝要求的权限。 在两种情况中，验证结果在块430返回给打包器；具体地，当要求的权限被 授权时，安全管理器启动正常返回，否则启动异常。
现在回来参照打包器的浮动通路，活动流程根据权限请求的结果在块 433分支。如果权限请求;陂拒绝，则该方法进行到块436;在该阶段中，丢失 权限的授权条目(具有符合策略文件语法的相应权限条目的说明和Java应用 程序源代码的说明)被添加到日志文件。同时，在块439,对权限请求的响 应被强制授权。然后，处理转入块442中；当要求的权限被授权时，从块433 也直接达到同样的目标。现在参照块442,打包器将这样获得的权限请求的 响应(即，总是授权要求的权限)返回给Java应用程序。然后，在块445能 够执行(与要求的权限相关联的)期望的操作。
现在在块448进行测试以确定Java应用程序的运行是否已完成。如果没
有完成，则活动流程返回到块409以执行下一个操作。在Java应用程序运行 的最后，在比较工具的浮动通路中处理继续到块451;在该阶—敬，将日志文 件与策略文件比较，以确定任何新的代码源和先前存在的代码源的任何新的 权限。然后，策略文件在块454相应地更新；这意味着添加之前不存在的任 何新的代码源的权限的授权条目，以及在涉及先前存在的代码源的任何新的 权限的各自授权条目中添加权限条目。这样获得的策略文件现在在块457能 够(例如，由具有要求的授权的系统管理员)部署到生产环境(不用任何打 包器)，用于支持Java应用程序的正确操作。然后，处理在同心的白/黑停止 圆环460处结束。
自然地，为了满足本地和特定的需求，本领域技术人员可以将许多修改 和替代应用到上述解决方案。具体地，尽管本发明已经参照其(各)优选实 施例用某种程度的细节描述，但是应当理解的是，各种形式和细节的省略、 替代和变化以及其它实施例是可能的；此外，清楚地意谓结合本发明的任何 公开的实施例描述的各特定元件和/或各方法步骤，可以并入任何其它实施例 作为设计选择的 一般主题。
更具体地，强调的是尽管提出的解决方案已经对定义软件应用程序的正 确操作要求的权限问题重点描述，但这不可以以限定的方式解释；实际上， 同样的技术还可用于将要求的资源(如登记条目、文件、端口等)，更一般地 添加到涉及软件应用程序配置的任何活动。
同样，相同构思还应用于软件应用程序的任何其它操作，该操作要求用 于它们执行的特定配置特征(如特定路径或端口数的说明)。
此外，可以使用不同的解决方案用于截取软件应用程序操作的调用和/ 或用于模拟丟失配置特征的可用性(如，通过钩挂(hooking)技术)。
当然，根据提出的方法的结果，可以执行任何其它活动用于配置软件应 用程序。例如，可以在运行时直接更新策略文件，可能用它的立刻刷新。
如果权限以不同的方式定义(例如，处于软件应用程序的当前用户的水 平)，则适用相似的考虑。
或者，可以实现用于授权/拒绝要求的权限的任何其它算法(例如，基于 更复杂的安全策略)。
当权限存储在任何其它安全结构(如数据库)中时，本发明的构思也可适用。
无论如何，日志文件可以简单提供当前安全策略的间隔尺寸(granularity ) 程度的指示(用作用于改进可用权限的建议)。
即使在之前的描述中已经参照Java应用程序的策略文件，但这不要以限 制方式解释；实际上，同样的技术可用于构成以任何其他语言编写的软件应 用程序的等效的安全结构(或更一般地用于它们的配置)。
没有什么阻止以任何其它适于提供相同的效果的人工制品(artifact)来 替代打包器；例如，可以添加专用的用户出口到安全管理器(其在测试环境 中使能，并在生产环境中无效)。
无论如何，不排除在生产环境中直接应用相同的解决方案(例如，即使 在软件应用程序部署之后也监视要求的权限)。
如果程序(其可用于实现本发明的每个实施例)以不同方式构造、或如 果提供了另外的模块或功能，则适用相似的考虑；同样地，存储器结构可以 是其它类型或可用等效实体替代(不必由物理存储介质组成)。此外，提出的 解决方案有助于用等效方法实现(通过使用相似的步骤、移除一些不是基本 的步骤、或添加另外的可选的步骤，甚至以不同顺序)。无论如何，该程序可 采取适于由或结合任何数据处理系统使用的任何形式，如外部或驻留软件、 固件或微代码(在对象代码中或在源代码中)。此外，可以在任何计算机可使 用的介质上提供程序；该介质能够是适用于包括、存储、传达、传播或传送 程序的任何元件。例如，该介质可以是电、磁、光、电磁、红外或半导体类 型；该介质的示例是硬盘(其中程序能被预加载)、可移除盘、带、卡、线、 光纤、无线连接、网络、广播波等。无论如何，根据本发明的解决方案有助 于用硬件结构(例如，集成在半导体材料的芯片中)、或用软件和硬件的接合 实现。
或者，提出的方法可以在具有不同架构或包括等效单元(如临时存储程 序或其部分、以在执行期间减少对大存储器的访问的高速緩冲存储器)的服 务器上执行；同样地，相同的解决方案也可适用于客户端、或单机计算机。 更一般地，可以用任何代码执行实体(如PDA、移动电话等)来替代计算机。
权利要求
1.一种用于配置软件应用程序的方法(403-460)，该方法包括以下步骤在数据处理系统上运行(406)软件应用程序，调用(409)软件应用程序的多个操作，每个操作的执行需要软件应用程序的配置特征，验证(413-430)每个操作的配置特征的可用性，日志记录(436)每个不可用配置特征的指示，模拟(439-442)每个不可用配置特征的可用性，以使能相应操作的执行，执行(445)每个操作，以及根据日志记录的不可用配置特征，配置(451-454)软件应用程序。
2. 根据权利要求1所述的方法(403 -460),其中每个配置特征包括用 于执行相应操作的权限的指示。
3. 根据权利要求2所述的方法(403 -460)，其中验证步骤(413 - 430 ) 包括验证该权限以执行每个操作，其中响应于每个权限的否定，日志记录步 骤(436)包括日志记录被拒绝权限的指示，以及其中模拟步骤(439 )包括 响应于该权限的否定，强制授权每个权限。
4. 根据权利要求3所述的方法(403 -460),其中可用的权限存储在安 全结构中，配置步骤(451 -454)包括根据日志记录的被拒绝权限，更新(454)安全结构。
5. 根据权利要求4所述的方法(403 -460),其中更新安全结构的步骤 (454 )包括添加(454)日志记录的被拒绝的权限到安全结构。
6. 根据权利要求4或5所述的方法(403 -460)，其中软件应用程序是 Java应用程序，且安全结构是策略文件。
7. 根据权利要求2至6的任一所述的方法(403 -460)，其中通过安全 模块授权或拒绝权限，验证步骤(413 -430)包括将用于验证权限以执行每个操作的请求提交(413 )到打包安全模块的辅 助模块，将来自辅助模块的请求转发(415 )到安全模块，以及将指示权限的授权或拒绝的响应从安全模块返回(418 -430)到辅助模 块，日志记录(436 )和模拟(439)步骤在辅助模块的控制下执行。
8. 根据权利要求1至7的任一所述的方法(403 - 460)，其中运行(406)、 提交(409)、验证(413 -430)、日志记录(436)、模拟(439)和配置(451 -454)步骤在测试环境中执行，该方法还包括以下步骤在生产环境中，部署(457)配置的软件应用程序。
9. 一种系统(100 )，包括用于执行根据权利要求1至8的任一的方法(430 —460)的各步骤的装置(300)。
全文摘要
提出了一种解决方案(300)，用于在Java环境中自动地构成策略文件(320)。为此目的，为负责控制任何对受保护资源的访问的安全管理器(315)提供了打包器(325)。一般的Java应用程序(310)运行于测试环境中。每当必须对受保护资源执行特定操作时，Java应用程序提交相应的权限请求给打包器(A1)。该打包器将权限请求转发到安全管理器(A2)，其验证策略文件(A3-A4)中要求的权限是否可用。打包器日志记录任何被拒绝的权限(A5)；无论如何，打包器总是将要求的权限授权给Java应用程序(A6-A7)，使得其操作能够继续而没有任何问题。在Java应用程序运行的最后，日志记录的丢失权限被添加到策略文件(A8)。
文档编号G06F21/22GK101196974SQ200710186809
公开日2008年6月11日 申请日期2007年11月14日 优先权日2006年12月6日
发明者克劳迪奥·摩吉亚, 曼纽拉·巴萨尼, 盖塔诺·费拉里, 马科·塞奇 申请人:国际商业机器公司