為 LDAP 用戶注冊表中定義的用戶和組配置對 WebSphere Service Registry and Repository 的訪問
簡介
JKHL Enterprises（下文簡稱 JKHLE）是一家虛構的公司，希望使用自己的 外部 LDAP 用戶注冊表配置對 IBM? WebSphere? Service Registry and Repository（下文 簡稱 WSRR）的訪問。JKHLE 使用了 WebSphere Application Server 連鎖存儲庫選項並啟用 了安全性。它還使用了 WSRR Governance Enablement Profile（下文簡稱 GEP）。這個項目 的 6 個 JKHLE 目標已在下面列出，它們的解決方案將在下面 1-6 節中介紹：
在 LDAP 中識別和定義將有權訪問 WSRR 的組。
阻止 WSRR 用戶管理 WebSphere Application Server。
使用戶能夠訪問 WSRR，即使 LDAP 不可用。
將 WSRR Web UI 訪問權限制到 WSRR 組。
將 Business Space 訪問權限制到 WSRR 組，只讓具有 Business Space 超級用戶角色的 用戶能夠在 WSRR 中創建空間和更新 Business Space 小部件。
JKHLE 使用 EJB API 開發了一個 WSRR 客戶端，並需要阻止可運行此 WSRR 客戶端的用 戶登錄到 Business Space 和 WSRR Web UI。
JKHLE 運行時環境
獨立配置中的 WSRR V8.0，使用 DB2 V9.7 Enterprise Server Edition with Fix Pack 4
WebSphere Application Server V8.0 with Fix Pack 3
IBM Tivoli Directory Server LDAP
盡管 JKHLE 使用的是 WSRR V8.0，但本文中的步驟同時適用於 WSRR V7.5 和 V8.0。
1. 在 LDAP 中識別和定義將有權訪問 WSRR 的組
使用 LDAP 管理安全性的最 佳方式是使用組。例如，一種授予 WSRR 管理性訪問權的不錯方式是，從外部 LDAP 用戶注 冊表將預定義的用戶組添加到 WSRR 中。然後當需要更改時，LDAP 管理員可簡單地在其 LDAP 中存在的組中添加或刪除用戶。此過程可確保在 LDAP 內執行的安全維護不需要 WSRR 或 WebSphere Application Server 中的任何額外工作。
因此，第一步是從上面列出 的 JKHLE 需求識別要用於 WSRR 的 LDAP 組。JKHLE 使用的是 GEP，在 WSRR，一個活動 GEP 定義了 6 個角色：
Business
Development
Operations
SOAGovernance
WSRRUser
WSRRAdmin
WSRR Business Space 定義了一個具有管理特權的超級用戶角色。JKHLE 希望將 Business Space 超級用戶角色限制為少數選定的用戶，這可定義一個名為 WSRRBusinessSpaceSuperUsers 的 LDAP 組來實現。
JKHLE 還希望限制那些能夠運行它使用 EJB API 創建的 WSRR 客戶端的用戶登錄到 Business Space 和 WSRR Web UI。與此活動關聯的角色稱為 WSRRBatchUser。與此角色對應 的 WSRR 組將在 LDAP 中定義。
上面確定的角色關系到 WSRR 中的具體活動。因此，每個角色在 LDAP 中應定義一個相應 的組，而且這些 LDAP 組將分配給 WSRR 中一個合適的角色，以與他們將執行的活動協調一 致。表 1 給出了 JKHLE 在 LDAP 中定義的 WSRR 組：
在第一節末， JKHLE 確定並定義了 LDAP 中的 WSRR 組。
2. 阻止 WSRR 用戶管理 WebSphere Application Server
本節首先確定下面列出的 WebSphere Application Server V8 中的 8 個與用戶和組相對應的預定義角色：
Monitor
Configurator
Operator
Administrator
Iscadmins
Deployer
Auditor
Admin Security Manager
表 2 給出 了這些管理角色。
要限制 WSRR 用戶執行 WebSphere Application Server 管理員活動，重要的是這 些用戶所屬的 WSRR 組不得授予 WebSphere Application Server 的 Administrator 角色。 WSRRBuinessSpaceSuperUsers 和 WSRRAdmins 組將被授予 Operator 角色，因為這些組中的 用戶可調用 WSRR MBean 的管理性操作。
觸發 WSRR 中的更新的 MBean 操作需要 WebSphere Application Server Operator 角色或更高級的角色。
LDAP 中的所有其 他 WSRR 組都將分配 WebSphere Application Server 的 Monitor 角色。表 3 給出了 LDAP 中定義的 WSRR 組與相應的 WebSphere Application Server 管理性角色的對應關系。本文 假設 WebSphere Application Server 已配置為使用 LDAP。
圖 1 顯示了 LDAP 中的 WSRR 組與相應的 WebSphere Application Server 管理性角色的對應關系：
圖 1. 分配給 LDAP 中定義的 WSRR 組的 WebSphere Application Server 管理性角色
在第 2 節末，JKHLE 將 WebSphere Application Server 管理性角色分配給了在 LDAP 中定義的 WSRR 組。為此，它已阻止這些 WSRR 組中的用戶管理 WebSphere Application Server。
3. 使用戶能夠訪問 WSRR，即使 LDAP 不可用
用於 WSRR 的 LDAP 組已在 LDAP 中確定、定義並在 WebSphere Application Server 中分配了管理性角色。但 是，在其當前配置中，對 WSRR 的訪問依賴於 LDAP 可用性。為了消除此依賴性，JKHLE 需 要在 WebSphere Application Server 內部安全提供程序（一個基於文件的存儲庫）中定義 本地 WSRR 組，如表 4 所示。
可將有限數量的用戶分配給這些組，以便訪問 WSRR 而不使用 LDAP。
圖 2 展示了 WebSphere Application Server 中本地定義的 WSRR 組與相應的 WebSphere Application Server 管理性角色的對應關系。
圖 2. 分配給在 LDAP 中 定義的 WSRR 組和 WebSphere Application Server 中本地定義的 WSRR 組的 WebSphere Application Server 管理性角色
在第 3 節末，JKHLE 能夠在 LDAP 不可用時使用 WSRR 了。
4. 將 WSRR Web UI 訪問權限制到 WSRR 組
WSRR Web UI 訪問權限通過將用戶和組映射到 ServiceRegistry 企業應用程序 J2EE 角色來控制。ServiceRegistry 企業應用程序為用戶 或組定義了兩個必須具有的 J2EE 角色：
Administrator 只有此角色中的用戶可調用管理性 MBean 操作。觸發 WSRR 中的更新 MBean 操作需要 WebSphere Application Server Operator 或更高級的角色，如第 2 節中所述。 User 此角色中的用戶在 WSRR 中執行非管理性操作。所有需要訪問 WSRR 的非管理性用戶都 必須映射到此角色。此角色中的用戶可在 WebSphere Application Server Administrator、 Operator、Configurator 或 Monitor 角色中執行必要的操作（在 WSRR 中）。
首先將 LDAP 中定義的 WSRR 組（第 1 節中）和 WebSphere Application Server 的內 部安全提供程序中定義的 WSRR 組（第 3 節中）映射到上面討論的兩個 J2EE 安全角色。表 5 給出了這些 WSRR 組與 ServiceRegistry 應用程序 J2EE 角色的對應關系。
通過完成 WSRR 組 與 ServiceRegistry 應用程序 J2EE 角色的映射，JKHLE 實現了兩個目標：
屬於 WSRR 組且已分配了 J2EE Administrator 角色的用戶可登錄到 WSRR Web UI，使用 Configuration 透視圖設置細粒度訪問控制。
屬於其他（非管理性）WSRR 組且已分配了一種 J2EE 用戶角色的用戶現在可在 WSRR Web UI Configuration 透視圖中看到，以便於分配給 GEP 角色。表 6 給出了 WSRR 組與 GEP 角色的映射。
查看本欄目
將WSRR 組映射到 ServiceRegistry 應用程序的 J2EE 角色並為它們分配 GEP 訪問控制角色，可確保這些組的 用戶可登錄到 WSRR Web UI 並執行與其 GEP 角色相關的活動。但是，在當前配置中， WebSphere Application Server 連鎖存儲庫中的所有經過驗證的用戶都可訪問 WSRR 中受這 些角色保護的資源，包括用戶能夠登錄到 WSRR Web UI。這是因為上面確定的 ServiceRegistry 應用程序的兩個 J2EE 角色默認映射到特殊主體 All authenticated in application's realm。JKHLE 需要將 Web UI 訪問權限制到在第 1 和 3 節中定義的 WSRR 組的成員。要將 WSRR Web UI 訪問權限制到 WSRR 組，需要更改 ServiceRegistry 應 用程序的 J2EE 角色的特殊主體映射關系。以下是更新 ServiceRegistry 企業應用程序的用 戶/組映射的步驟：
選擇 Applications => Application Types => WebSphere enterprise applications，然後選擇 ServiceRegistry 應用程序。
在右側面板的 Detail Properties 下，選擇 Security role to user/group mapping。
首先刪除特殊主體，從 ServiceRegistry 應用程序重新映射 All authenticated in the application's realm 角色。
選擇角色 User 和 Administrator。
單擊 Map special subjects 並選擇 None。
重新啟動服務器。
圖 3 顯示了 WSRR 組到與 ServiceRegistry 應用程序關聯的兩個 J2EE 角色的映射。從 該圖還可以看到，特殊主體配置為 None。在該圖中，映射的用戶 lWSRRAdminUser 表示一個 具有 RunAs 角色的用戶。第 5 節將討論將 J2EE Administrator 角色分配給組的 lWSRRBusinessSpaceSuperUsers 和 WSRRBusinessSpaceSuperUsers。
圖 3. WSRR 組 到與 ServiceRegistry 應用程序關聯的 J2EE 角色的映射
在第 4 節末，JKHLE 已經將 WSRR Web UI 訪問權限制到在 LDAP 中定義的 WSRR 相關組 和在 WebSphere Application Server 的內部安全提供程序中定義的 WSRR 組。
5. 將 Business Space 訪問權限制到 WSRR 組，只讓超級用戶能夠在 WSRR 中創建空間和更新 Business Space 小部件
對 WSRR 中 Business Space 的訪問，通過在 ServiceRegistry 企業應用程序中將用戶和組映射到 J2EE 角色 mm.was_node_server （Network Deployment 環境中的 mm.was_cluster）進行控制。mm.was_node_server 定義了 兩個必須是用戶或組主角的 J2EE 角色：
Admin 僅此角色中的用戶可查看、編輯和刪除所有空間和頁面，管理和創建模板，通過更改 所有者 ID 來更改空間的所有權。這些用戶稱為 Business Space 超級用戶或 Business Space 管理員。 Allauthenticated 僅此角色中的用戶可登錄到 Business Space。
首先阻止用戶創建業務空間。完成此步驟，以確保只讓擁有 Superuser 角色的用戶能夠 創建業務空間。接下來，將 LDAP 中定義的 WSRR 組（第 1 節中）和 WebSphere Application Server 內部安全提供程序中定義的 WSRR 組（第 3 節中）映射到上面介紹的 ServiceRegistry 應用程序 mm.was_node_server 的兩個 J2EE 安全角色。表 7 給出了這些 WSRR 組到 mm.was_node_server 應用程序的 J2EE 角色的映射。
完成 WSRR 組到 mm.was_node_server 應用程序的 J2EE 角色的映射，可實現兩個目標：
屬於該組且分配了 J2EE Admin 和 Allauthenticated 角色的用戶可以 Superuser 身份 登錄到 Business Space。這些用戶擁有 Superuser 訪問權，可在 Business Space 中創建 新空間。
屬於其他（非管理性）WSRR 組且分配了 J2EE Allauthenticated 角色的用戶可登錄到 Business Space。
請注意，WSRRAdminUsers 和 lWSRRAdminUsers 組未映射到 mm.was_node_server 應用程 序的 J2EE 角色。因此，JKHLE 通過將不同的用戶分別映射到這些組，能夠區分 Business Space 管理員和 Web UI 管理員。下一步是將 WSRR 組映射到以下 J2EE 角色，以確保這些 WSRR 組可在 Business Space 中執行與其 GEP 角色相關的活動：
BSpaceEAR_node_server （Network Deployment 環境中的BSpaceEAR_cluster）企業應用 程序的 J2EE 角色 businessspaceusers。
BSpaceForms_node_server（Network Deployment 環境中的BSpaceForms_cluster）企業 應用程序的 J2EE 角色 WebFormUsers。
將 WSRR 組映射到 mm.was_node_server 應用程序 J2EE 角色並向它們分配 GEP 訪問控 制角色（第 4 節中），可確保這些組中的用戶可登錄到 Business Space 並在 Business Space 中執行與它們的 GEP 角色相關的活動。但是，在當前配置中，WebSphere Application Server 連鎖存儲庫中所有已驗證的用戶，都可訪問 WSRR 中受這些角色保護的 資源，包括用戶能夠登錄到 Business Space 並在 Business Space 中執行與 Superuser 角 色關聯的活動。這是因為上面確定的 mm.was_node_server 應用程序的兩個 J2EE 角色默認 映射到特殊主體 All authenticated in application's realm。JKHLE 需要將 Business Space 訪問權限制到第 1 和 2 節中定義的 WSRR 組的成員，因此更改 mm.was_node_server 應用程序的 J2EE 角色的特殊主體映射至關重要。以下是更新 mm.was_node_server 企業應用程序的用戶/組映射的步驟：
選擇 Applications => Application Types => WebSphere enterprise applications 並選擇 mm.was_node_server 應用程序。
在右側面板的 Detail Properties 下，選擇 Security role to user/group mapping。
首先刪除特殊主體，從 mm.was_node_server 應用程序重新映射 All authenticated in the application's realm 角色。
選擇角色 Allauthenticated 和 Administrator。
單擊 Map Special Subjects 並選擇 None。
重新啟動服務器。
對 BSpaceEAR_node_server 和 BSpaceForms_node_server 企業應用程序都重復 1-6 步 。通過將特殊主體設置為 None，JKHLE 將 Business Space 訪問權限制到 LDAP 中定義的 WSRR 相關組和 WebSphere Application Server 內部安全提供程序中定義的 WSRR 組。 JKHLE 還確保了 Superuser 角色現在限制為 lWSRRBusinessSpaceSuperUsers 和 WSRRBusinessSpaceSuperUsers 組中的用戶。
圖 4 顯示了 WSRR 組到與 mm.was_node_server 應用程序關聯的兩個 J2EE 角色的映射。從中還可看到，特殊主體配置 為 None：
圖 4. WSRR 組到與 mm.was_node_server 應用程序關聯的 J2EE 角色的映 射
圖 5 顯示了 WSRR 組到與 BSpaceEAR_node_server 應用程序關聯的 J2EE 角色的映射。 從中還可以看到，特殊主體配置為 None：
圖 5. WSRR 組到與 BSpaceEAR_node_server 應用程序關聯的 J2EE 角色的映射
圖 6 顯示了 WSRR 組到與 BSpaceForms_node_server 應用程序關聯的 J2EE 角色的映射 。從中還可以看出，特殊主體配置為 None。
圖 6. WSRR 組到與 BSpaceForms_node_server 應用程序關聯的 J2EE 角色的映射
在第 4 節中，Business Space 超級用戶組（也就是 WSRRBusinessSpaceSuperUsers 和 lWSRRBusinessSpaceSuperUsers）已分配了 ServiceRegistry 應用程序的 J2EE Administrator 角色。授予此 J2EE 角色，可確保這些組中的用戶可檢索 Business Space 配置設置（編輯新創建的空間需要用到這些設置）且可更新 Business Space 小部件。
在第 5 節末，JKHLE 將 Business Space 訪問權限制到了 WSRR 組並確保只讓 Business Space Superuser 角色能夠創建新空間和更新 Business Space 小部件 。
6. 阻止可運行 WSRR 客戶端的用戶登錄到 Business Space 和 WSRR Web UI
首先使用 Web UI 在 WSRR 中創建新角色 WSRRBatchUser。按照 向角色添加權限 中的說明 ，將合適的權限添加到此角色中。授予此角色的權限必須與 WSRR 客戶端的目標用途一致。
在第 4 節中，已為 WSRR 組 WSRRBatchUsers 和 lWSRRBatchUsers 分配 ServiceRegistry 應用程序的 J2EE User 角色，以確保 WSRRBatchUsers 和 lWSRRBatchUsers 可在 Web UI 中用於細粒度的訪問控制。接下來，在 Web UI 中將這兩個 組都與 WSRRBatchUser 角色關聯。JKHLE 現在可配置它的 WSRR 客戶端以配合這些組的成員 使用。
但是，這些用戶登錄 WSRR Web UI 的任何嘗試都將遇到消息 There are no perspectives defined for the specified user. Please contact your system administrator.。此消息表明，新創建的角色 WSRRBatchUser 不允許查看 WSRR Web UI 中 定義的任何透視圖，因此可阻止此角色的用戶成功登錄到 WSRR Web UI。
在第 5 節 中，組 WSRRBatchUsers 和 lWSRRBatchUsers 沒有分配 mm.was_node_server 企業應用程序 的 Allauthenticated 角色，這可阻止這些組中的用戶登錄到 Business Space。
在 第 6 節末，能夠運行 WSRR 客戶端（使用 EJB API）的用戶被阻止登錄到 Business Space 和 WSRR Web UI。
結束語
簡介中列出了 JKHLE 希望通過使用它的外部用戶注 冊表 LDAP 配置對 WSRR 的訪問而實現的 6 個目標。本文采用循序漸進的方法逐個介紹了每 個需求的解決方案，進而幫助 JKHLE 理解：
如何基於用戶需求，確定要在 LDAP 中定義的 WSRR 組。
如何將 WebSphere Application Server 管理性角色分配給 WSRR 組，以及 JKHLE 在阻 止這些組的用戶管理 WebSphere Application Server 的過程中所發揮的作用。
如何使用 WebSphere Application Server 內部安全提供程序（一個基於文件的存儲庫） ，確保在 LDAP 不可用時訪問 WSRR。
WSRR J2EE 角色在建立對 Business Space 和 Web UI 的訪問控制過程中的作用。
如何使用 WSRR 角色和權限（細粒度訪問控制）阻止 WSRR EJB 客戶端的用戶登錄到 Business Space 和 Web UI。
