Java 权限模型的缺点.doc

Java 权限模型的缺点 围绕各种permission类和基于代码的安全性构建的Java SE Access Control模型没能紧跟Java平台的发展步伐，因而无法满足当今企业系统的需求。本文将分析该问题的根源，并给出一些建议的替代方案。 Java SE模型概述 该模型的本质是使用代码中的permission类来认可执行某些操作的正确性。当某个操作要在特定的类/页面/等中执行时，该代码将调用SecurityManager的(或AccessController的)方法checkPermission(Permission)，向其传递一个由基础Permission类派生的某个类的实例。然后AccessController将负责对整个调用堆栈执行迭代，验证堆栈中的每个帧是否包含所需的权限。图1显示了这种过程。 图1.checkPermission调用中的堆栈遍历 需要重点了解的是，在这个模型中，permission类将自己负责执行评估逻辑，以及定义资源结构和可用权限的任务。每个代码框架的权限来自于对当前线程及其CodeSource执行Java Principal。对于堆栈中的每个代码框架，计算任务由已安装的Policy提供程序来完成，而提供程序将负责对结果集中的每个permission类调用评估逻辑，以确定其中是否有潜在的sought permission。 当代码运行成功时，整个checkPermission(Permission)调用要么返回，要么抛出SecurityException表示违反了安全性规则。 Java SE模型的历史 Java的安全模型可以追溯到该平台的早期时代，当时人们主要将它看作一种增强用户体验的浏览器扩展机制。执行的Java代码可以从各种源派生，而其中一些的来源是未知的或者不可靠的。相应地，该平台的安全性最初主要关注的是解决验证被执行的代码可信任的问题，而且整个游戏围绕着在浏览器中执行applet。但是，这个模型只是简单地划分为trusted和untrusted部分，甚至连中等复杂的应用程序都无法运行。 从1.2版开始，Java作为一个编程平台逐渐得到了人们的认可，而不再只是一个浏览器扩展，Sun开始提供更加灵活的安全功能，首先是可配置安全策略的概念。Java文档介绍了它的发展情况。 当Java平台开始进入企业环境时，很快就会明显地感觉到，纯粹基于代码的功能无法管理大型应用程序的安全性。Java平台的1.4版引入了一种叫做Java Authentication andAuthorization Service(JAAS)的新特性，用于将基于用户的权限项整合到安全策略中。现在，堆栈上某个特殊代码框架的权限既基于代码的源(其CodeSource)，又基于验证时分配给用户的身份、组和角色。 当前的问题 即使经历了如此漫长的发展，Java的安全模型仍然最适合代码访问安全。但是，这个模型未能应对高层企业应用程序的需求，这需要能够执行比简单权限检查更多的访问控制功能。以下部分将讨论其中的一些问题。 管理功能通常，一般当涉及管理安全性，尤其是管理访问控制时，唯一的最大障碍就是缺少直接而且强大的管理模型。以下列出了Java基于权限的模型的明显缺陷。 权限扩散Java本身自带了很多标准权限，它们由其自己的代码调用(请参阅Permission及其子类)。但是，这些权限不适合那些试图保护自己的组件的应用程序，所以这些应用程序中相当多的一部分必须定义其自己的类。 例如，考虑一个工作流应用程序，如图2所示： 图2.访问控制的用户界面屏幕 不计算标准SE和EE权限，它们由应用程序和容器调用(但是仍然需要在该策略内管理)，该页面需要定义一些单独的权限。首先，该应用程序需要定义一个专门的权限(称之为TransferPermission)来验证该用户被授权执行工作流的这一步流程。其次，它要检查用户在此屏幕上是否可以看到和使用文本框和按钮，这需要一些其他UI权限(称之为AccountEditButtonUIPermission、AccountTextUIPermission和AmountTextUIPermission)。第三，此页面中的一些数据(比如账号)可能需要隐藏；不幸的是，Java没有提供任何机制来满足该需求(请参阅数据和功能安全的一致性部分)。 考虑到大型应用程序(尤其是在金融和医疗行业)通常拥有数千个元素，这很快会使已定义权限的总数飙升至数百甚至数千个，使整个权限的集合难以管理。 资源模型每个权限(无论它是标准的还是自定义的)都将其自己的资源解释逻辑整合到评估过程。这意味着permission类要操作不同表现形式的应用程序资源，使安全管理员无法创建一个图3所示类型的一致的应用程序管理图。 图3.资源层次结构 例如，考虑Java