Java权限模型的缺陷 - 编程入门网

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 and Authorization Service (JAAS) 的新特性，用于将基于用户的权限项整合到安全策略中。现在，堆栈上某个特殊代码框架的权限既基于代码的源（其 CodeSource），又基于验证时分配给用户的身份、组和角色。

当前的问题

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

Java权限模型的缺陷(2)

管理功能

通常，一般当涉及管理安全性，尤其是管理访问控制时，唯一的最大障碍就是缺少直接而且强大的管理模型。以下列出了 Java 基于权限的模型的明显缺陷。

权限扩散

Java 本身自带了很多标准权限，它们由其自己的代码调用（请参阅 Permission 及其 子类）。但是，这些权限不适合那些试图保护自己的组件的应用程序，所以这些应用程序中相当多的一部分必须定义其自己的类。

例如，考虑一个工作流应用程序，如图 2 所示：

图 2. 访问控制的用户界面屏幕

不计算标准 SE 和 EE 权限，它们由应用程序和容器调用（但是仍然需要在该策略内管理），该页面需要定义一些单独的权限。首先，该应用程序需要定义一个专门的权限（称之为 TransferPermission）来验证该用户被授权执行工作流的这一

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!