Java权限模型的缺陷

Java权限模型的缺陷2011-07-06 developers.sun.com.cn / Denis Pilipchuk围绕各种 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 and Authorization Service （JAAS）的新特性，用于将基于用户的权限项整合到安全策略中。现在，堆栈上某个特殊代码框架的权限既基于代码的源（其 CodeSource），又基于验证时分配给用户的身份、组和角色。

当前的问题

即使经历了如此漫长的发展，Java 的安全模型仍然最适合代码访问安全。但是，这个模型未能应对高层企业应用程序的需求，这需要能够执行比简单权限检查更多的访问控制功能。以下部分将讨论其中的一些问题。