保护作业调度程序
简介
IBM WebSphere Application Server V8.5 和更高版本为基于 Java 的批处理应用程序提供了一个实现平台。与丰富的编程模型和众多复杂特性相结合，比如跳过记录处理、并行处理、重试步骤处理、COBOL 支持以及与企业调度程序的集成，它还提供了企业级质量，即：
可用性
可恢复性
可伸缩性和性能
安全性。
对于批处理程序的执行，作业调度程序接受作业提交并确定在何处运行它们。作为管理作业的工作的一部分，作业调度程序将作业信息持久保存在一个外部作业数据库中。由于作业调度程序是批处理作业的 “门槛”，所以对作业的保护可通过作业调度程序的安全机制来实现。因为批处理程序通常处理重要的、敏感的信息，因此拥有较高的安全标准对它们而言至关重要。本文将讨论如何保障 WebSphere Batch 解决方案的安全。
WebSphere Batch 的安全模型
WebSphere Batch 特性的安全性可通过以下模型来管理：
角色
安全性通过使用这个预定义的角色集来提供，在 WebSphere Application Server 中提供这些角色是为了进行批处理：
lradmin：分配给此角色的用户有权在所有作业上执行与作业调度程序相关的所有操作，无论作业归谁所有。
lrsubmitter：这个角色中的用户有权在提交者拥有的所有作业上执行与作业调度程序相关的所有操作。
lrmonitor：这些用户只能查看所有用户的作业和作业日志。
组
在组安全模型中，所有与作业相关的安全决策都仅以组成员关系为基础。只有在用户和作业是同一个组的成员时，用户才能完成针对该作业的操作。例如，如果有两个或更多用户是同一个组的成员，而且每个用户提交一个分配给同一个组作业，那么所有这些用户都可以查看和处理彼此的作业。出现这种情形是因为，WebSphere Application Server 在作业调度程序操作上执行基于组的检查。
角色和组的组合
在这个组合了组和角色的安全模型中，组成员关系和角色都规定了作业安全性。这意味着，只有在用户和作业都是同一个组中的成员，而且用户的角色有权限执行与作业相关的操作时，用户才能执行作业操作。
例如，如果两个或更多用户是同一个组的成员，而且每个用户提交了一个分配给该组的作业，那么所有用户都可以查看彼此的作业并执行操作 - 但受其作业分配的限制：
lradmin 角色中的用户可查看所有组成员的作业并执行作业操作。
lrsubmitter 角色中的用户仅可查看它们所提交的作业并执行作业操作。
lrmonitor 角色中的用户禁止提交作业，但允许查看 lradmin 和 lrsubmitter 角色中的其他用户所提交的作业。
对作业调度程序安全性有了基本的了解后，我们尝试通过示例强化这些概念，这些示例使用了各种安全角色，包含用户、角色和组，如表 1 和表 2 所示。
为了进行测试，我们使用 IBM Tivoli Directory Server V6.3 作为 LDAP 存储库，创建了所需的用户和组。（用于创建上述用户和组的 ldif 脚本文件可从本文的下载部分获得。）然后，我们为这个 Tivoli Directory Server 配置了 WebSphere Application Server，以便作业调度程序可利用我们创建的用户和组。请注意，您必须将 Tivoli Directory Server 存储库配置为一个连锁存储库，即使 WebSphere Application Server 配置仅使用单个存储库。
下面简单介绍了配置步骤。
在 Tivoli Directory Server 中创建用户和组
创建目录树的根条目 dc=mydw,dc=org。要创建它，可以使用 Tivoli Directory Server Instance Administration Tool。单击 Manage > Manage suffixes。
输入后缀 dc=mydw,dc=org 并单击 Add，然后单击 OK（图 1）。
图 1. 在 Tivoli Directory Server 中创建新后缀