围绕各种 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 部分，甚至连中等复杂的应用程序都无法运行。