保護作業調度程序
IBM WebSphere Application Server V8.5 和更高版本為基於 Java 的批處理應用程序提供了一個實現平台。與豐富的編程模型和眾多復雜特性相結合，比如跳過記錄處理、並行處理、重試步驟處理、COBOL 支持以及與企業調度程序的集成，它還提供了企業級質量，即：
可用性
可恢復性
可伸縮性和性能
安全性。
對於批處理程序的執行，作業調度程序接受作業提交並確定在何處運行它們。作為管理作業的工作的一部分，作業調度程序將作業信息持久保存在一個外部作業數據庫中。由於作業調度程序是批處理作業的 “門檻”，所以對作業的保護可通過作業調度程序的安全機制來實現。因為批處理程序通常處理重要的、敏感的信息，因此擁有較高的安全標准對它們而言至關重要。本文將討論如何保障 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）。
選擇 LDIF Tasks > Import LDIF Data，以導入創建所需的用戶和組的 ldif 文件（圖 2）。
使用 Tivoli Directory Server 配置 WebSphere Application Server
單擊 Security > Global security。
選擇 Enable administrative security，然後選擇 Enable application security。
在 Available realm definitions 下拉列表中選擇 Federated repositories，單擊 Configure…（圖 3）。
單擊 Related Items 部分下的 Manage repositories。
單擊 Add 並選擇 LDAP repository 以添加 LDAP 存儲庫（圖 4）。
輸入 Tivoli Directory Server 的詳細信息。在 Additional Properties 下，單擊 Group attribute definition，然後單擊 Member attributes。單擊 New… 添加並指定：
成員屬性的名稱：uniquemember
對象類：groupOfUniqueNames
單擊 Federated repositories entity types to LDAP object class mapping 並編輯組條目類型。將對象類修改為 groupOfNames;groupOfUniqueNames（圖 5）。
單擊面板頂部的浏覽路徑記錄中的 Federated Repositories，返回到 Federated repositories 頁面。
單擊 Add repositories (LDAP, custom, etc)… 並選擇剛創建的 LDAP1 存儲庫。輸入基類的惟一可識別名稱 dc=mydw,dc=org。
單擊 OK 保存您的配置。
在配置 WebSphere Application Server 安全性後，一定要重新啟動服務器，以便讓更改生效。
這樣，Tivoli Directory Server 和 WebSphere Application Server 的配置就完成了。接下來，您將了解如何實現 3 種類型的安全性，查看 3 種實現之間的區別。
基於角色的安全性是為作業調度程序提供的默認安全性。自定義屬性 JOB_SECURITY_POLICY 用於設置安全性策略。可能的有效值為：
ROLE 表示基於角色的安全模型
GROUP 表示基於組的安全模型
GROUPROLE 表示組-角色組合安全模型。
配置基於角色的安全性：
在 WebSphere Application Server 中，選擇 System administration > Job scheduler > Custom properties。
單擊 New 並指定 JOB_SECURITY_POLICY 作為自定義屬性的名稱，指定 ROLE 作為值（圖 6）。
單擊 OK 保存您的配置。
接下來，要將用戶分配給不同的角色。您將配置 3 個用戶：將 alphaUser 分配給 lradmin 角色，betaUser 分配給 lrmonitor 角色，anotherBetaUser 分配給 lrsubmitter 角色，如表 1 所示。要將用戶分配給角色，可展開 System administration > Job scheduler > Security role to user/group mapping（圖 7）。
選擇角色 lradmin 並單擊按鈕 Map Users…
單擊 Search 以查找並選擇 alphaUser。
對 lrmonitor (betaUser) 和 lrsubmitter (anotherBetaUser) 角色重復此過程。
單擊 OK 並保存配置。
重新啟動服務器，以便讓更改生效。
請記住，基於角色的安全性也可分配給用戶組而不是個人，只需選擇 Map Groups… 並選擇合適的組。
要確認已為作業調度程序啟用了角色安全性，請在 SystemOut.log 文件中查找以下消息：
CWLRB5837I: The WebSphere Application Server Batch Feature is running under [ROLE] security policy.
SampleCI 應用程序下載
要驗證不同的角色有不同的訪問級別，可以采用用戶 anotherBetaUser 身份，使用 Job Management Console 提交一個作業，然後以不同用戶身份登錄。
圖 8 到圖 10 演示了在 anotherBetaUser (lrsubmitter) 使用 xJCL SimpleCIxJCL 提交了作業 SampleCIEar:00301 後，Job Management Console 向不同角色顯示的結果：
alphaUser (lradmin) 用戶可看到和操作所有作業，無論作業歸誰所有（圖 8）。
betaUser (lrmonitor) 用戶可以看到所有作業，無論作業歸誰所有，但不能對作業執行任何操作（圖 9）。
anotherBetaUser (lrsubmitter) 只能對它提交的作業進行操作。請注意，anotherBetaUser 不能看到其他用戶可以看到的作業（圖 10）。
要實現基於組的安全性，您需要更新 JOB_SECURITY_POLICY 屬性並為用戶建立映射：
導航到 System administration > Job scheduler > Custom properties。
將 JOB_SECURITY_POLICY 屬性值更新為 GROUP。
單擊 OK 保存您的配置。
所有經過驗證的用戶都被映射到 lradmin 角色。這可確保與作業組位於同一個組中的所有用戶都可以獲得 lradmin 角色的特權。單擊 System administration > Job scheduler > Security role to user/group mapping。
選擇 lradmin 作為角色。
單擊 Map Special Subjects 並選擇 All Authenticated in Application’s Realm（圖 11）。
保存更新，然後重新啟動服務器。
要驗證組安全性是否已啟用，可在 SystemOut.log 文件中查找以下行：
CWLRB5837I: The WebSphere Application Server Batch Feature is running under [GROUP] security policy.
圖 12 到圖 14 顯示了在 anotherBetaUser（lrsubmitter 角色）使用 xJCL SimpleCIxJCL_a（alpha 組）提交作業 SampleCIEar:00302，anotherBetaUser（lrsubmitter 角色）使用 xJCL SimpleCIxJCL_b（beta 組）提交作業 SampleCIEar:00303 後，Job Management Console 向不同角色顯示的結果：
alphaUser (alpha) 只能看到和管理屬於組 alpha 的任務。這正是 alphaUser 可以看到作業 SampleCIEar:00302 卻看不到 SampleCIEar:00303 的原因（圖 12）。
betaUser (beta) 用戶可看到和管理屬於組 beta 的作業，所以它只能看到 SampleCIEar:00303 作業（圖 13）。
anotherBetaUser (beta) 用戶可以看到和管理屬於組 beta 的作業，所以它們只能看到 SampleCIEar:00303 作業（圖 14）。
要實現基於決策和組的安全性，同樣需要更新 JOB_SECURITY_POLICY 屬性並與用戶建立映射。用戶然後就可以處理作業，只要用戶和作業都屬於同一個組，而且用戶的角色允許執行該操作：
單擊 System administration > Job scheduler > Custom properties。
將 JOB_SECURITY_POLICY 屬性值更新為 GROUPROLE。
單擊 Apply 保存您的配置。
單擊 System administration > Job scheduler > Security role to user/group mapping（圖 15）。
使用表 1 為角色分配不同的用戶。
保存更新並重新啟動服務器，以便讓更改生效。
驗證組和角色安全性已啟用。如果在 SystemOut.log 文件中看到以下消息，則表示組角色安全性已啟用：
CWLRB5837I: The WebSphere Application Server Batch Feature is running under [GROUPROLE] security policy
圖 16 到圖 18 顯示了在 anotherBetaUser（lrsubmitter 角色）使用 xJCL SimpleCIxJCL_b（beta 組）提交作業 SampleCIEar:00304 後，不同角色看到的 Job Management Console：
alphaUser（lradmin、alpha）僅能看到和管理屬於組 alpha 的任務。這正是 alphaUser 可看到作業 SampleCIEar:00302 卻看不到 SampleCIEar:00303 的原因。另請記住，因為 alphaUser 具有角色 lradmin，所以它擁有完整的作業管理權利（圖 16）。
betaUser（lrmonitor、beta）用戶可以看到屬於 beta 組的作業，但無法操作它，因為它僅擁有監視權利（圖 17）。
anotherBetaUser（lrsubmitter、beta）用戶可看到和管理屬於組 beta 的作業。請注意，盡管 betaUser 和 anotherBetaUser 屬於同一個組，但由於它們具有不同的角色，所以它們具有作業上的不同權利（圖 18）。
本文討論了如何在 3 種安全模型下在作業調度程序上實現安全性：基於角色、基於組，同時基於角色和組。您還了解了在不同的模型下對作業的訪問權利有何不同。
