SOA 案例研究：安全性和管理場景

CloudSpace發表於2008-07-21

本紅皮書是面向服務的體系結構 (SOA) 系列之一，主要通過名為 JKHL Enterprises (JKHLE) 的虛構公司闡述一個案例研究。本紅皮書中的案例研究重點說明與 SOA 安全性和管理相關的挑戰和解決方案。本紅皮書描述如何使用“SOA 安全性和管理場景”的實現和解決方案模式來解決與該案例研究相關的業務和 IT 挑戰。

我們在本文中介紹的案例研究包括以下人員和角色：

  • Sandy Osbourne-Archer，首席技術架構師
  • Edmund Smythe-Barrett，企業架構師
  • Steve Optman，IT 運營經理
  • Axel Setrust，安全架構師
  • Budi Manmon，管理架構師

帳戶開立專案的挑戰

JKHLE 已經部署了一個成熟的管理環境來管理現有的應用程式。帳戶開立專案中新引入的共享服務、流程和組合應用程式帶來了新的管理挑戰。本文討論與保護和管理應用程式服務以及與用於帳戶開立專案案例研究的支援基礎設施相關的挑戰和解決方案。

IT 運營經理 Steve Optman 與首席技術架構師 Sandy Osbourne-Archer 進行會談，討論帳戶開立專案的安全性和管理挑戰及目標。Steve 提出了對運營團隊當前無法及時瞭解帳戶開立專案設計情況的擔憂。Steve 重點強調了從一開始就參與到流程中的重要性，這樣可以避免他的運營團隊因延遲參與投入執行之前的一些部署而遇到的問題。Sandy 贊同並承諾在開發週期中儘早讓運營團隊參與進來。

Sandy 概述了運營團隊在部署本專案時需要滿足的三個關鍵安全性和管理目標：

  • 發現資源和服務

需要提供一種自動化方法來發現服務註冊中心中定義的應用程式元件、中介軟體和服務。需要將從發現過程中捕獲的資料提供給現有的更改控制流程。

  • 在通用管理控制檯中監視服務

需要以一種與現有管理環境和通用管理控制檯一致的方式監視帳戶開立流程應用程式服務和支援基礎設施。

  • 安全性和遵從性稽核功能

需要端到端的安全性以及能夠提供稽核記錄，以確保滿足遵從性要求。

Sandy 建議 Steve 及其運營團隊直接與企業架構師 Edmund Smythe-Barrett 合作。

Edmund 負責帳戶開立專案應用程式和支援基礎設施的體系結構和設計。

帳戶開立專案的要求

Steve 安排與 Edmund、安全分析人員 Axel Setrust和管理架構師 Budi Manmon 會面，檢查帳戶開立專案體系結構並概述關鍵安全性和管理設計點（請參見圖 1）。


圖 1 SOA 安全性和管理部署體系結構的注意事項

簡而言之，反向代理部署在隔離區 (DMZ) 中。

此處的門戶用於提供表示層和使用 ESB 或直接與流程伺服器及後端應用程式進行互動。客戶端可以是企業內部和外部的使用者或服務使用者。

類似地，應用程式和服務既可以屬於企業內部也可以屬於企業外部。

在部署體系結構中的各個點上強制執行安全性。

在從帳戶開立流程門戶中使用時，Edmund 引用了客戶概要服務（請參見圖 2）。Edmund 解釋說，此事務在應用程式體系結構和支援基礎設施中具有代表意義。簡而言之，在客戶從門戶中輸入概要資訊之後，客戶概要服務（中介）就會與由 CICS® 後端系統承載的帳戶記錄應用程式進行互動，用於儲存客戶概要資訊供進一步處理。


圖 2 帳戶開立流程門戶——客戶概要服務

Steve 介紹了帳戶開立專案 SOA 的採用將如何創造競爭優勢。Steve 強調說，為降低成本和確保遵從性，高效的安全性和管理解決方案非常重要。

他解釋說，成本降低包括更高效地管理 JKHLE 環境的大量資源，從而使運營團隊能夠以同樣的資源提供更多管理支援。

Steve 看到 JKHLE 面臨著無法準確掌控業務和技術資產的挑戰。需要實施足夠的管理才能有效地管理所有資產。缺乏足夠的管理會導致不必要的風險，以及無法有效地滿足遵從性和稽核要求。此外，往往還會出現重大操作中斷。

Steve 解釋說，IBM® Service Management 跨業務和技術資產提供了整合的可見性、控制和自動化，可幫助您克服業務和技術整合方面的障礙，以及妨礙創新的因素。IBM Service Management 產品組合包括與 ITIL® 保持一致的工作流、基於標準的配置管理資料庫、與基礎設施保持一致的自動化任務、最佳實踐以及實現支援。

注意：您可以在以下位置找到有關 IBM Service Management 的更多資訊：

http://www.ibm.com/itsm

運營團隊計劃利用 IBM Service Management 解決方案和產品來支援帳戶開立專案和其他活動。帳戶開立專案的安全性和管理解決方案將重點關注圖 3 中所示的 IBM Service Management Operational Management 和 Service Management。


圖 3 IBM Service Management 上下文中帳戶開立專案重點關注的內容

SOA Management 的要求

運營團隊瞭解到 JKHLE 業務流程將越來越多地依賴於構成跨越多個體繫結構層（包括服務使用者、業務流程、服務、服務元件和作業系統）的多層組合應用程式的共享服務。Steve 和 Budi 知道，此管理解決方案需要包括用於管理和監視 SOA 組合應用程式和用於支援跨多個體繫結構層的基礎設施的軟體和解決方案。



Steve 概述了在整個管理生命週期中需要執行的關鍵任務。圖 4 重點介紹了這些任務的關鍵輸入、使用者角色和這些任務的構件輸出。雖然這些任務是採用自頂向下的方法顯示的，但是這些任務中許多都具有迭代性。

Budi 重點介紹了部署體系結構的關鍵 SOA 管理要求（請參見圖 1）。

REQ-01：標識要管理的服務和資源

標識需要通過帳戶開立流程門戶管理的服務和資源。JKHLE 已經部署了許多現有的系統和資源。一項關鍵管理要求是瞭解如何標識或發現應管理哪些服務和支援資源。

REQ-02：自動發現資源

提供了一種自動化方法可以發現服務註冊中心中定義的應用程式元件、中介軟體和服務。從發現過程中捕獲的資料將提供給現有的更改控制流程。

REQ-03：將服務作為資源對其進行管理和監視

為達到業務定義的服務質量，每個服務終端都需要作為一項資源來管理，包括呼叫服務（使用者）和將應用程式功能公開為服務（提供者）。解決方案必須能夠提供實時可用性和效能指標，以及定義的服務水平協議。

管理基礎設施需要提供一種監視和故障排除方法，若能在故障發生之前發出警報則更好。監視包括實際使用者通訊量，以確保 SLA 一致性和監視綜合事務。綜合事務用於確保環境以一致的方式處理一組受控互動，這一點作為根本原因分析的基準是非常有用的。

Budi 重點介紹了幾個有代表性的監視示例：

  • 監視客戶概要服務事務以確保其響應時間不超過 5 秒。
  • 監視客戶概要服務（服務使用者和提供者，應用伺服器和後端系統）所用的基礎設施的可用性。

REQ-04：在整合控制檯中監視端到端檢視

在孤立的應用程式體系結構中，資源通常是由不同的操作人員或專家在多個不同的管理控制檯中管理的。帳戶開立流程門戶代表了需要轉變管理方法的 SOA 組合應用程式。需要通過以下方式監視和管理基礎設施：既涵蓋組合應用程式的端到端檢視，又提供有關各資源的效能和可用性標準的詳細資訊。

SOA 安全性的要求

Axel 負責安全基礎設施。Axel 得出了兩項與安全性相關的觀測結果：

  • 因為部署體系結構中的每個元件都強制實施了安全性的某一方面，所以可能存在多種標識、身份驗證、授權和稽核機制。整合安全機制將成為一項挑戰。
  • 特定的產品有多個管理島，這往往會導致錯誤、不一致和缺乏協作。管理可能會以資源為中心，策略管理可能會獨立於業務單元、應用程式或產品。

安全性管理在需要跨多個元件實施一致策略的 SOA 環境中會是一項挑戰。

Axel 重點介紹了 SOA 部署體系結構的關鍵安全性要求（請參見圖 1）。

REQ-05：標識提供

在 JKHLE 環境中，開立了一個新帳戶之後，標識將提供給多箇中介軟體和後端系統。解決方案需要提供和管理標識，從中央系統到外部系統。

REQ-06：標識傳播

當使用者與門戶進行互動時，使用者標識需要在整個事務中進行傳播，無需多次登入即可傳播到後端系統。在某些情況下，現有的系統將擁有並不完全相同的使用者 ID，或者外部使用者將使用不同的協議繫結與門戶進行互動。在這些情況下，保護業務資料和為標識、資料等建立業務信任關係是非常重要的。請求可能來自外部實體，因此安全域可能是交叉的。

需要在整個事務中傳播標識，無論體系結構中有多少個躍點。

REQ-07：身份驗證

當使用者或系統與門戶進行互動時，需要對標識進行身份驗證。在對使用者進行身份驗證之前，需要設定一個代理來首先對使用者標識進行質詢。在代理上派生的標識需要到處傳播，以便可以強制執行更多安全檢查（如授權和稽核）。此解決方案需要提供身份驗證服務，能夠通過單點登入功能從門戶登入到多個後端系統。

REQ-08：授權

安全解決方案需要確保使用者能夠訪問基於使用者或系統標識確定的許可資訊。許多元件可能都需要授權，其中包括粗粒度的基於服務的授權到細粒度的資料級訪問控制。

REQ-09：稽核

JKHLE 必須確保採用了適當的控制來滿足法規遵從性要求。需要沿著事務路徑將稽核資訊從每個元件中收集起來。稽核資訊將被記錄，並可用於實時、法律審查和報告，從而能夠滿足法規遵從性要求。

REQ-10：傳輸和訊息級安全性

需要保證資訊和業務資料在傳輸以及儲存過程中的安全。需要提供機密性保護來確保訊息資料不可訪問且無法被其他人修改，從而確保訊息的完整性。資料保護策略往往會指明需要在傳輸和訊息級別採用哪種型別的保護。

注意：有關解決方案的詳細資訊，請參閱“傳輸和訊息級別安全性”。

將 SOA 場景模式應用於案例研究

本部分描述瞭如何使用“SOA 安全性和管理場景”實現模式來解決與帳戶開立專案案例研究的安全性和管理相關的業務和 IT 挑戰。

Steve 安排與 Sandy 和運營團隊的主要成員會面，介紹用於支援帳戶開立流程門戶應用程式部署的安全性和管理解決方案。

SOA 管理

Steve 有一個目標，希望通過此次與 Sandy 的會面實現以下兩個目的：

  • 確保 Sandy 對支援定義的目標和要求的高階別管理解決方案有個大體瞭解。
  • 深入瞭解有關帳戶開立流程應用程式服務和支援基礎設施的發現和監視的更多詳細資訊。

為深入分析目的，Steve 建議使用客戶概要服務（請參見圖 2），因為該服務是部署體系結構和管理解決方案的代表。

建議的解決方案

Steve 讓 Budi 向 Sandy 詳細介紹管理解決方案，並從說明如何標識要管理的資源開始。Budi 解釋說，可以採用兩種基礎方法來確定要管理的資源，即在分析和設計過程中確定資源和在執行時通過發現確定資源。這兩種方法常常一起使用，但是也可以獨立使用。

在分析和設計過程中確定資源

在分析和設計時基於非功能性需求和 SLA 確定要管理的資源。此方法需要了解應用程式體系結構和支援基礎設施。

此方法包括以下幾項高階任務：

  • 標識服務和端到端事務

包括標識關鍵服務、事務和流程。分析非功能性需求和 SLA 在確定應管理哪些服務過程中起到關鍵作用。在帳戶開立流程門戶中，客戶概要服務與 CICS 後端系統進行互動。IBM Tivoli® Service Level Advisor 將記錄並報告服務水平協議。例如，SLA 規定事務的響應時間不應超過 5 秒，IBM Tivoli Composite Application Manager for SOA 將對服務的響應時間進行監視，以確保達到 SLA 要求。

  • 確定 SOA 基礎參考體系結構中的資源

在多個體繫結構層中，帳戶開立應用程式的服務、流程和支援基礎設施將作為資源被管理。

Budi 解釋瞭如何分解多個體繫結構層中的客戶概要事務（請參見圖 5）。這些資訊用於對適當的管理軟體建立對映以管理資源。

  • 確定監視確定的資源所需的標準

在確定了服務事務和管理產品的資源型別之後，企業架構師和管理架構師能夠與 IT 管理人員和 SME 一起根據已定義的特定標準來監視資源。SLA 通常包括監視資源所需的關鍵標準。


圖 5 在 SOA 基礎體系結構層中確定要管理的資源

發現資源

在定義了標準之後，運營團隊計劃執行資源的自動發現來獲取管理資源所需的附加資訊。資源的發現包括應用程式元件和服務、基礎設施資源，以及在服務註冊中心中定義的服務。

現有的 IBM Tivoli Monitoring Server 提供了一個用於與其他監視產品整合的基本管理框架，以及一個被稱為 Tivoli Enterprise Portal 的通用監視介面。Tivoli Composite Application Manager 系列產品用於發現和監視特定型別的應用程式元件、服務和支援基礎設施的資源。Tivoli Composite Application Manager 產品配置了 Tivoli Monitoring Server，可以在通用 Tivoli Enterprise Portal (TEP) 控制檯中發現此類資源並在其中對這些資源進行管理。

Tivoli Composite Application Manager for SOA 將用於發現和監視 Web 服務和 ESB。Tivoli Composite Application Manager for SOA 會安裝到 Tivoli Monitoring Server 環境中。當 Tivoli Composite Application Manager for SOA Agent 在目標應用伺服器上執行後，可以執行此應用程式。在使用 Web 服務或 ESB 中介的情況下，Tivoli Composite Application Manager for SOA 的發現元件將檢測服務的名稱和操作，並在 Tivoli Enterprise Portal 中顯示這些資訊。在配置用於監視響應時間和使用率這樣的度量服務的 Tivoli Enterprise Portal 境況時需要這些資訊。還可以通過與 IBM WebSphere® Service Registry and Repository 整合發現服務。

監視

圖 6 描述了將用於監視執行時環境的管理邏輯體系結構。環境中有許多其他後端系統；但是，應用程式體系結構代表了部署環境。


圖 6 用於帳戶開立流程門戶的 SOA 管理解決方案

現有的環境包括圖 6 中顯示的許多管理元件。主要新增了以下元件：

  • 新增了 Tivoli Composite Application Manager for SOA，用於管理和監視服務使用者和提供者，包括監視 ESB 中介和 Web 服務。
  • 需要新增 Tivoli Composite Application Manager for Response Time Tracking 來管理端到端的事務效能，從客戶端一直到後端 CICS。
  • Tivoli Composite Application Manager for Response Time 用於進行使用者監視（使用者響應時間、記錄和回放綜合事務）。

表 1 列出了將用於監視帳戶開立部署環境的資源的自定義 Tivoli Enterprise Portal 工作區。

表 1 Tivoli Enterprise Portal 工作區摘要

TEP 工作區 工作區描述
Main 用於監視跨 SOA 體系結構層的資源的檢視。
Services 用於管理服務的檢視。
Transactional 用於管理端到端事務效能的檢視。
Middleware 用於管理中介軟體資源的檢視。
Operational 用於管理操作資源的檢視。

工作區可以連結在一起，這對於進行根源分析來說可能非常有用。

考慮服務響應時間超過監視的境況的事件。根源是承載服務的應用伺服器停止。可以將工作區連結在一起以深入研究從 Situations Event Console 中的服務響應時間事件到 WebSphere Application Server—Log Analysis 檢視 Middleware 工作區。

在分析、設計和發現過程中從資源的標識中收集到的資訊和標準用於建立 Tivoli Enterprise Portal 境況。Tivoli Enterprise Portal 境況是根據閾值對一組屬性進行測試的條件。該境況按照預先定義的間隔對條件進行評估，並呼叫 Tivoli Enterprise Portal 中相應的自動響應和通知方法，如事件訊息或採取措施。隨多種 IBM 監視產品提供了許多預先定義的境況，可以按“原樣”使用這些境況也可以對其進行自定義。

Budi 列出了將用作觸發事件的一些主要境況（請參見表 2）。

表 2 用於觸發事件的主要境況

監視層/產品 用於監視事件的境況
使用 ITCAM for SOA 監視服務
  • 服務（中介）平均響應時間超過 5 秒
  • 訊息大小超出範圍
  • 中介不能連線到 CICS Gateway (CTG)
監視事務效能 ITCAM RTT
  • 通過將事務的每個段與 CICS 後端關聯起來監視端到端事務效能。

圖 7 顯示了 Main Tivoli Enterprise Portal 工作區，該工作區提供了管理的資源的整合檢視。當觸發了一種境況後，Situation Event Console 檢視中將顯示事件。


圖 7 Main Tivoli Enterprise Portal 工作區——資源的整合監視檢視

SOA 安全性

Sandy 已請求與 Steve 和 Axel 會面來檢查支援定義的要求的安全性解決方案設計。

建議的解決方案

Axel 說明了團隊如何應用 IBM SOA 安全參考模型（請參見圖 8）來滿足帳戶開立應用程式和支援基礎設施的安全要求。IBM SOA 安全參考模型更廣泛的上下文是用於保證服務、應用程式和資源安全的 IBM Service Management 的子元件。


圖 8 IBM SOA 安全參考模型

高度概括地講，此模型定義如下：

  • 業務安全服務（Business Security Services）包括管理業務的需求，如信任、標識和訪問管理，資料保護，遵從性和報告，不可否認性，安全系統以及網路。
  • IT 安全服務（IT Security Services）描述用於保證服務安全的 SOA 基礎結構的基礎構造塊。安全服務包括標識、身份驗證和授權、機密性、完整性，以及稽核服務。
  • 安全支援（Security Enablers）包括 IT 安全服務使用的加密、目錄和金鑰儲存庫等技術。安全策略管理包括管理、強制執行和監視安全策略。
  • 治理和風險管理（Governance and Risk Management）提供實現和強制執行安全策略的機制。治理可幫助客戶在整個組織中管理 SOA。風險管理用於處理評估風險並制定管理這些風險的策略的流程。
  • 安全策略管理（Security Policy Management）是總體策略管理的一部分，用於清楚表述、管理、強制執行和監視安全策略。

標識提供

帳戶開立流程門戶包括許多後端系統。出於參考目的，可以考慮呼叫客戶概要服務與 CICS 後端系統進行互動的帳戶開立流程門戶應用程式。

簡而言之，由帳戶開立流程門戶使用的 WebSphere Portal、WebSphere Application Server 和 WebSphere Process Server 共享一個由 IBM Tivoli Directory Server 實現的通用 LDAP 使用者儲存庫。CICS 將 RACF® 用於安全服務。在帳戶開立流程門戶中建立了一個新帳戶之後，LDAP 使用者儲存庫中會建立一個新標識，並且會在 RACF 中通過 IBM Tivoli Identity Manager 建立一個新標識。在有些情況下，IBM Tivoli Directory Integrator 用於建立標識。在企業環境中，不同的系統強制執行不同的標識命名約定和策略是很普遍的。例如，使用者標識 jsmith 是在 LDAP 目錄中建立的，而 joesmith 是在 RACF 中建立的。

標識傳播

作為從門戶到後端系統的請求流的一部分，服務使用者可以通過 ESB 與提供者進行互動。使用者的可信標識需要在整個應用程式中流動。應考慮標識的格式可能需要進行轉換。此外，表示使用者的標識在多個系統中可能不同，可能需要在多個系統間進行對映。

能夠使用幾種解決方案模式來傳播標識。該團隊決定使用通過 IBM Tivoli Federated Identity Manager 實現的安全令牌服務來執行格式轉換和標識對映。需要 WebSphere（Application Server、Portal Server 和 Process Server）來攜帶 RACF 使用者 ID 和傳遞票證。在將請求傳送到 CICS（或其他後端系統）之前，需要使用安全令牌服務對 WebSphere 中的身份驗證標識進行對映和轉換，安全令牌服務可以將傳入使用者名稱 jsmith (WebSphere/LDAP) 對映為 CICS 所用的 RACF 使用者 ID joesmith。安全令牌服務還會為該使用者生成 RACF 傳遞憑證。

根據 WS-Trust 規範，到安全令牌服務的介面也是一項服務。從 LDAP ID 到 RACF ID 的標識對映是通過在 LDAP 中查詢此 ID 完成的。

身份驗證服務

需要使用身份驗證服務來與不同的域、不同的平臺和不同的服務進行整合。運營團隊確定使用者識別符號和密碼身份驗證。參照由 IBM Tivoli Directory Server 和 IBM Tivoli Access Manager 實現的基於 LDAP 的使用者儲存庫對使用者標識進行檢查。

在 JKHLE 環境中，第一個身份驗證質詢在使用者訪問門戶時發生。IBM Tivoli Access Manager—WebSEAL 元件用於實現反向代理，反向代理充當門戶和其他 Web 應用程式的聯絡人的聯合單一登入點。使用上述反向代理，由於身份驗證邏輯存在於 Tivoli Access Manager WebSEAL 層中，因此可以在將來支援更復雜的身份驗證機制，而無需修改 Web 應用程式。

注意：運營團隊正在評估使用 IBM WebSphere DataPower® 來實現增強的處理能力。WebSphere DataPower 可用作處理 XML 通訊、提供訊息保護和中介標識的安全代理。

ESB 在將服務請求傳遞給服務提供者之前，使用身份驗證服務對服務使用者提供的憑據進行身份驗證。服務提供者包括中介軟體應用程式、後端系統和資料服務。

授權服務

在對使用者的標識進行了身份驗證之後，可以使用授權服務來確定對資源的適當訪問權。

授權決策取決於授權策略和身份驗證標識。在 JKHLE 環境中，在針對服務使用者和提供者、應用程式和資料的整個解決方案中使用了多種授權服務。

帳戶開立流程門戶是服務使用者。IBM WebSphere Portal 為門戶頁面和 Portlet 提供了其自己的授權模式。對於門戶和 J2EE. 應用程式，授權可以是基於角色的。此外，WebSphere Portal 能夠使門戶的授權服務外部化以供 IBM Tivoli Access Manager 管理。

JKHLE 環境中有大量需要授權服務的服務提供者型別。J2EE 應用程式利用 Tivoli Access Manager 的授權服務。許多後端系統和應用程式都有其自己的授權服務或使用 RACF，如基於 CICS 的應用程式。資料和資料庫也需要授權服務。對於 z/OS® 中的資料服務，使用 RACF 進行授權。

稽核服務

部署稽核服務是為了通過收集稽核資訊並報告這些資訊來理解安全環境執行情況的。大多數 IBM 安全性和基礎設施產品都包括可處理用於報告用途的稽核日誌功能。運營團隊使用 IBM Tivoli Compliance Insight Manager 來整理、處理和報告稽核資料。

傳輸和訊息級安全性

運營團隊使用行業標準的傳輸和訊息級安全性。為保證 HTTP 的安全，可以應用傳輸級安全性。傳輸級安全性基於在 HTTP 下執行的安全套接字層 (SSL) 或傳輸層安全性 (TLS)。與訊息級安全性不同，HTTPS 將對整個 HTTP 資料包進行加密。不存在選擇性地對訊息的特定部分應用安全性的選項。SSL 和 TLS 提供身份驗證安全性、資料保護和對安全 HTTP 連線的加密令牌支援。

WS-Security 提供了訊息級安全性，可在構建安全 Web 服務以實現訊息內容完整性、機密性和身份驗證時使用。來自服務使用者和提供者的資料都通過需要保護的 ESB 來中轉。此操作可通過將 WS-Security 和傳輸級安全性與 SSL/TLS 結合使用，利用機密性服務並選擇訊息級安全性來實現。

總結

建議的安全性和管理解決方案體系結構可滿足所確定的需求，同時能夠重用現有基礎設施中的許多元件。此方法提供了一個滿足連續遵從性和稽核要求的環境，同時促進了採用 SOA 為帳戶開立應用程式帶來的業務靈活性。安全性和管理解決方案體系結構為 JKHLE 繼續採用其他 SOA 專案奠定了堅實的基礎，而無需額外的管理開銷。

總的來說，以下 IBM 產品將用於保護和管理部署環境：

  • 管理：
    • IBM Tivoli Monitoring Server
    • IBM Tivoli Composite Application Manager for：
      • SOA
      • WebSphere
      • Response Time
      • Response Time Tracking
      • CICS Transactions
    • IBM Tivoli OMEGAMON® XE
    • IBM Tivoli Service Level Advisor
    • IBM Tivoli Provisioning Manager
  • 安全性：
    • IBM Tivoli Access Manager
    • IBM Tivoli Identity Manager
    • IBM Tivoli Federated Identity Manager
    • IBM Tivoli Directory Server
    • IBM Tivoli Directory Integrator
    • IBM WebSphere DataPower
    • IBM Tivoli Compliance Insight Manager

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-406636/，如需轉載，請註明出處，否則將追究法律責任。

相關文章