|
当前页面: JAVA 编程资料牛鼻论坛 → Java & J2SE 技术区→Java认证与授权：Java 授权内幕 |
Java认证与授权：Java 授权内幕
Java认证与授权：Java 授权内幕
[IT168技术文档]
在信息安全性领域，授权是世界的的中心，因为它是控制个体（即人、进程和计算机）对系统资源的访问权限的过程。直到最近，在 Java 安全体系结构中相关的问题都是“这段运行中的代码的访问权限是什么？” 随着 Java 认证和授权服务（Java Authentication and Authorization Service，JAAS）的引入，这种情况改变了。JAAS 首先是作为 JDK 版本 1.3 的平台扩展，之后作为 JDK 1.4 及以后版本的核心部分。在 JAAS 中，相关问题变成了“运行这段代码的认证用户的访问权限是什么？”
在本文中，将同时介绍老的以代码为中心的 Java 授权体系结构和新的以用户为中心的体系结构。我将首先对 Java 2 平台安全体系结构作一概述，重点放在这个体系结构如何利用两个基本概念 -- 安全策略和保护域 -- 来定义、组织和聚集静态和/或动态访问权限。然后详细分析 Java 2 平台安全体系结构的运行时访问检查功能的底层机制，包括堆栈检查和确定是否授予权限的遍历（traversal）机制。在了解了以代码为中心的授权模型是如何工作的后，我将转向 Java 授权和认证服务（JAAS）的以用户为中心的授权模型。在这里，我将重点放到基于 subject 的访问控制这一概念上，并展示在 JAAS 中，它是如何在原来 Java 2 平台安全体系结构的堆栈检查机制之上实现的。
注意，本文假定读者熟悉 Java 平台（J2SE SDK 1.4）上的应用程序编程，以及企业应用程序安全性的基本概念。与 Java 平台的以代码为中心和以用户为中心的授权体系结构的所有概念都只作为介绍。
以代码为中心的授权
Java 平台传统上是用来运行移动代码的，如 applet。为了保护系统资源不被这些从网络上下载到用户浏览器中的任意代码片段所破坏，applets 被限制到一个沙箱中，它们在这里以有限的一组权限运行 。另一方面，对于本地 Java 应用程序，很少会（如果会的话）安装将提供类似沙箱环境的安全管理器。因此，本地应用程序通常受到信任可以访问所有系统资源。
JDK 1.x 模型和 Java 2 平台 SDK 版本 1.2 的新安全结构之间的最大区别是引入了新的、可配置的安全策略，这样就可以实现细化的和可管理的访问控制。所有代码（不管是本地还是下载的，不管是签名或者没有签名的）都可以受到定义良好的安全策略的约束，它为不同的代码授予（可能是重叠的）权限。同时，随着在 JVM 中引入了多进程能力（请参阅 参考资料），出现了对基于用户的访问控制的要求。
Java 2 平台安全体系结构背后的基本原理可以总结如下：一个系统级的 安全策略定义了按 保护域组织的执行代码的 访问权限(按照应用程序的需要）。安全策略用于访问控制检查，这是由 JVM 在运行时执行的。在本次导游中，我将逐一详细阐述这些概念。
访问权限作为类型化（typed）对象
在 Java 2 平台安全体系结构中，所有访问权限都是类型化的并且有层次结构，其根是抽象类 java.security.Permission 。通常一个 Permission 包含一个目标（“由这个权限控制的操作将对谁执行？”）和一个操作（“如果这个权限允许的话，对这个目标将执行什么操作？”）。
在允许一段运行的代码对特定的“目标”执行特定的“操作”这一上下文中，一个重要的概念是代码不一定被授予与所需要完全一样的 Permission 。相反，只要可以从实际授予这段代码的 Permission 中推断出或者隐含了所需要的 Permission 就可以。例如，如果一段运行代码授予了读目录 /x 中所有文件的权限，那么它就不需要对目标文件 /x/in.xtx 执行 读操作的显式权限，因为前一个权限隐含了后者。
显然，某个 Permission 是否隐含另一个 Permission 的定义将取决于这两个 Permission 是如何定义的。至少，这两个 Permission 必须为同一类型。不过，不能指望运行时进行进一步的判断，并且必须将这种隐含推断逻辑指派给所涉及的 Permission 类。运行时通过调用一个恰当地取名为 implies 的方法来查询 Permission 类的隐含推断逻辑。
聚集的权限
新安全体系结构也引入了 聚集（aggregation）的概念。在 Java 2 平台上，可以聚集同一类型的 Permission 对象的多个实例。一组这种类型称为 PermissionCollection 。例如，一个 PermissionCollection 可能包含两个 java.io.FilePermission 实例，表示读取两个不同文件的特权。
这样的类型化对象干净地封装了创建和维护一个集合并遍历这一集合的功能。不用在每次要检查权限时对每一个对象分别调用 implies() 方法，Java 运行时只是调用由 PermissionCollection 对象提供的 implies() 方法并等待其响应。可以为所创建的每一个自定义 Permission 对象定义一种新的 PermissionCollection 类型。当然， PermissionCollection 中 implies() 方法的具体实现取决于给定 Permission 对象的特性。
Permissions 对象
除了对特定的 Permission 类型有多个实例，任何给定的一段运行代码都将得到不同类型的 Permission 。 Java 2 平台安全体系结构为此以 Permissions 对象的形式提供了一组 PermissionCollection 对象。一个 Permissions 对象是单个 Permission 实例的 集合的 集合。 Permissions 类还提供了一个 implies() 方法。不过，要记住为了让一个 Permission 隐含另一个，它们必须是同一类型的。因此，调用 Permissions 对象的 implies() 方法会使后者首先在其内部集合中定位正确的 PermissionCollection 实例（那个包含一组正确类型的 Permission 对象的实例），然后调用由此获得的 PermissionCollection 对象的 implies() 方法，并向它传递要检查的 Permission 。