test

Sun Java System Application Server 9.1 管理指南

第 10 章 配置訊息安全性

本章中的某些內容假設您對安全性和 Web 服務概念已有基本的瞭解。本章說明如何在 Application Server 中為 Web 服務配置訊息層安全性。本章包含以下主題：

訊息安全性概況

在訊息安全性中，安全性資訊會插入到訊息中，以使其透過網路層傳輸並附帶訊息到達訊息目標。訊息安全性與傳輸層安全性 (在「Java EE 5.0 Tutorial」中的「Security」一章中討論) 不同，因為訊息安全性可用於將訊息保護機制與訊息傳輸機制分離，從而使訊息在傳輸後仍保持受保護狀態。

Web 服務安全性：SOAP 訊息安全性 (WS-Security) 為互通 Web 服務安全性的國際標準，是由 Web 服務技術的所有主要提供者 (包括 Sun Microsystems) 在 OASIS 中協作開發的。WS-Security 是一種訊息安全性機制，它使用 XML 加密和 XML 數位簽名來確保經由 SOAP 傳送的 Web 服務訊息的安全。WS-Security 規格定義了多種安全性記號 (包括 X.509 證書、SAML 指定和使用者名稱/密碼記號) 的使用，以認證和加密 SOAP Web 服務訊息。

您可透過 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security -1.0.pdf 檢視 WS-Security 規格。

瞭解 Application Server 中的訊息安全性

Application Server 在其 Web 服務用戶端和伺服器端容器中提供對 WS-Security 標準的整合式支援。整合此功能後，Web 服務安全性可由代表應用程式之 Application Server 的容器來強制執行，並且可以用於保護任何 Web 服務應用程式，無需變更應用程式的實作。Application Server 透過提供可將 SOAP 層訊息安全性提供者和訊息保護策略連結到容器和容器中部署的應用程式之功能，來達到此效果。

指定訊息安全性職責

在 Application Server 中，系統管理員 和 應用程式部署人員 角色應負起配置訊息安全性的主要責任。儘管通常其他的角色都不需要開發者且無需變更其實作，就可以確保現有應用程式的安全，但在某些情況下，應用程式開發人員 也可以發揮作用。以下小節定義了各種角色的職責：

系統管理員

系統管理員負責：

系統管理員使用管理主控台來管理伺服器安全性設定，並使用指令行工具來管理憑證資料庫。在 Platform Edition 中，憑證和私密金鑰均儲存在金鑰庫中，並透過 keytool 進行管理。Standard Edition 和 Enterprise Edition 將憑證和私密金鑰儲存在 NSS 資料庫中，並使用 certutil 對其進行管理。本文件主要適用於系統管理員。如需有關訊息安全性作業的簡介，請參閱配置 Application Server 以實現訊息安全性。

應用程式部署人員

應用程式部署人員負責：

應用程式開發人員

應用程式開發者可以啟用訊息安全性，但並不是必須要這樣做。訊息安全性可以由系統管理員設定，以便確保所有 Web 服務的安全；如果連結到應用程式的提供者或保護策略不同於連結到容器的提供者或保護策略，訊息安全性則由應用程式部署人員設定。

應用程式開發者或組譯者負責：

關於安全性記號和安全性機制

WS-Security 規格為使用安全性記號來認證和加密 SOAP Web 服務訊息提供了可延伸機制。與 Application Server 一起安裝的 SOAP 層訊息安全性提供者可用於採用使用者名稱/密碼和 X509 憑證安全性記號，以認證和加密 SOAP Web 服務訊息。採用其他安全性記號 (包括 SAML 指定) 的其他提供者將與 Application Server 的後續發行版本一起安裝。

關於使用者名稱記號

Application Server 使用 SOAP 訊息中的使用者名稱記號來建立訊息傳送者的認證身份。包含使用者名稱記號 (在內嵌式密碼中) 的訊息接收者透過確認傳送者是否知道使用者的秘密 (即密碼)，來驗證訊息傳送者是否經過授權成為使用者 (在記號中識別)。

使用使用者名稱記號時，必須在 Application Server 中配置有效的使用者資料庫。

關於數位簽名

Application Server 使用 XML 數位簽名將認證身份連結到訊息內容。用戶端使用數位簽名來建立呼叫者身份，其方法與使用傳輸層安全性時用基本認證或 SSL 用戶端證書認證建立呼叫者身份的方法相似。訊息接收者將驗證數位簽名以認證訊息內容的來源 (可能與訊息傳送者不同)

使用數位簽名時，必須在 Application Server 中配置有效的金鑰庫和信任庫檔案。如需有關該主題的更多資訊，請參閱關於證書檔案。

關於加密

加密的目的是將資料修改為只有目標讀者才能理解的形式。加密程序透過用加密元素替換原始內容來完成。與公開金鑰加密指出的那樣，可以使用加密來建立能夠閱讀訊息的一方或多方身份。

使用加密時，必須先安裝支援加密的 JCE 提供者。如需有關該主題的更多資訊，請參閱配置 JCE 提供者。

關於訊息保護策略

訊息保護策略是針對請求訊息處理和回應訊息處理而定義的，並根據對源和/或收信人認證的需求來進行表示。來源認證策略代表一個需求，即必須在訊息中建立已傳送訊息或已定義訊息內容的實體之身份，以使其可以由訊息收件者進行認證。接收者認證策略代表一個需求，即必須傳送訊息，以使可接收訊息的實體之身份可 由訊息傳送者建立。提供者套用特定的訊息安全性機制，以使訊息保護策略在 SOAP Web 服務訊息的上下文中實現。

請求和回應訊息保護策略是在將提供者配置到容器時定義的。特定於應用程式的訊息保護策略 (細緻程度為 Web 服務連接埠或作業) 也可以在應用程式或應用程式用戶端的特定於 Sun 的部署描述元中進行配置。在任何情況下，如果定義了訊息保護策略，則用戶端的請求和回應訊息保護策略必須與伺服器的請求和回應訊息保護策略相符 (即二者等效)。如需有關針對各應用程式定義訊息保護策略的更多資訊，請參閱「 Developers Guide」中的「Securing Applications」一章。

訊息安全性術語字彙表

以下內容描述本文件中所使用的術語。配置 Application Server 以實現訊息安全性中也討論了這些概念。

確保 Web 服務的安全

透過將 SOAP 層訊息安全性提供者和訊息保護策略連結到部署有應用程式的容器或連結到應用程式提供的 Web 服務端點，來確保在 Application Server 中部署的 Web 服務的安全。透過將 SOAP 層訊息安全性提供者和訊息保護策略連結到用戶端容器或連結到由用戶端應用程式宣告的可攜式服務參照，從而在 Application Server 的用戶端容器中配置 SOAP 層訊息安全性功能。

安裝 Application Server 後，將在 Application Server 的用戶端和伺服器端容器中配置 SOAP 層訊息安全性提供者，其中這些提供者可由容器或者由容器中部署的個別應用程式或用戶端進行連結使用。在安裝程序中，這些提供者配置簡單的訊息保護策略，即如果連結到容器或者連結到容器中的應用程式或用戶端，則將導致所有請求和回應訊息中內容的源均由 XML 數位簽名進行認證。

可以採用 Application Server 的管理介面，從而連結現有提供者以供 Application Server 的伺服器端容器使用，修改由提供者強制執行的訊息保護策略，或使用替代的訊息保護策略來建立新的提供者配置。您可以在應用程式用戶端容器的 SOAP 訊息層安全性配置上執行類似的管理作業，如啟用應用程式用戶端的訊息安全性中所定義。

依預設，Application Server 中的訊息層安全性處於停用狀態。若要配置 Application Server 的訊息層安全性，請執行配置 Application Server 以實現訊息安全性中列出的步驟。如果您要將 Web 服務安全性用於保護在 Application Server 上部署的所有 Web 服務應用程式，請執行啟用訊息安全性的提供者中的步驟。

完成以上步驟 (可能需要重新啟動 Application Server) 後，Web 服務安全性將套用於在 Application Server 上部署的所有 Web 服務應用程式。

配置特定於應用程式的 Web 服務安全性

透過在應用程式的特定於 Sun 的部署描述元中定義 message-security-binding 元素，來配置特定於應用程式的 Web 服務安全性功能 (在應用程式組譯時)。這些 message-security-binding 元素用於將特定提供者或訊息保護策略與 Web 服務端點或服務參照相關聯，並符合要求以使其套用到相應端點或參照的服務的特定連接埠或方法。

如需定義特定應用程式訊息防護策略的更多資訊，請參閱 「Sun Java System Application Server 9.1 Developer’s Guide」中的第 5 章「Securing Applications」。

確保範例應用程式的安全

Application Server 隨附名為 xms 的範例應用程式。xms 應用程式具有簡單的 Web 服務功能，可由 J2EE EJB 端點和 Java Servlet 端點共同實作。這兩個端點共用同一個服務端點介面。服務端點介面定義了單一作業 (sayHello)，此作業可取得字串引數，並傳回由呼叫引數加前置的 Hello 所組成的 String。

xms 範例應用程式用於說明如何使用 Application Server 的 WS-Security 功能來確保現有 Web 服務應用程式的安全。範例隨附的指令說明了如何啟用 Application Server 的 WS-Security 功能，以將其用於確保 xms 應用程式的安全。範例還說明了 WS-Security 功能與應用程式的直接連結 (如配置特定於應用程式的 Web 服務安全性中所述)。

xms 範例應用程式安裝在以下目錄中：as-install/samples/webservices/security/ejb/apps/xms/。

如需有關編譯、封裝和執行 xms 範例應用程式的資訊，請參閱「Developers’ Guide」中的「Securing Applications」一章。

配置 Application Server 以實現訊息安全性

請求策略配置和回應策略配置的動作

下表列出了訊息保護策略配置，以及由該配置的 WS-Security SOAP 訊息安全性提供者所執行的最終訊息安全性作業。

表 10–1 訊息保護策略與 WS-Security SOAP 訊息安全性作業對映

訊息保護策略 

最終的 WS-Security SOAP 訊息保護作業 

auth-source="sender" 

此訊息包含 wsse:Security 標頭，此標頭包含 wsse:UsernameToken (帶有密碼)。

auth-source="content" 

對 SOAP 訊息內文的內容進行簽名。此訊息包含 wsse:Security 標頭，此標頭包含以 ds:Signature。

auth-source="sender" 

auth-recipient="before-content" 

或 

auth-recipient="after-content" 

SOAP 訊息內文的內容已加密，並由最終的 xend:EncryptedData 替代。此訊息包含 wsse:Security 標頭，此標頭包含 wsse:UsernameToken (帶有密碼) 和 xenc:EncryptedKey。xenc:EncryptedKey 包含用於加密 SOAP 訊息內文的金鑰。此金鑰在收信人的公開金鑰中加密。

auth-source="content" 

auth-recipient="before-content" 

SOAP 訊息內文的內容已加密，並由最終的 xend:EncryptedData 替代。xenc:EncryptedData 已簽名。此訊息包含 wsse:Security 標頭，此標頭包含 xenc:EncryptedKey 和 ds:Signature。xenc:EncryptedKey 包含用於加密 SOAP 訊息內文的金鑰。此金鑰在收信人的公開金鑰中加密。

auth-source="content" 

auth-recipient="after-content" 

SOAP 訊息內文的內容已簽名和加密，並由最終的 xend:EncryptedData 替代。此訊息包含 wsse:Security 標頭，此標頭包含 xenc:EncryptedKey 和 ds:Signature。xenc:EncryptedKey 包含用於加密 SOAP 訊息內文的金鑰。此金鑰在收信人的公開金鑰中加密。

auth-recipient="before-content" 

或 

auth-recipient="after-content" 

SOAP 訊息內文的內容已加密，並由最終的 xend:EncryptedData 替代。此訊息包含 wsse:Security 標頭，此標頭包含 xenc:EncryptedKey。xenc:EncryptedKey 包含用於加密 SOAP 訊息內文的金鑰。此金鑰在收信人的公開金鑰中加密。

未指定策略。 

模組未執行任何安全性作業。 

配置其他安全性功能

Application Server 使用 SOAP 處理層中整合的訊息安全性提供者來實作訊息安全性。訊息安全性提供者取決於 Application Server 的其他安全性功能。

  1. 如果使用的 Java SDK 版本早於 1.5.0，而且使用了加密技術，請配置 JCE 提供者。

  2. 配置 JCE 提供者中討論了如何配置 JCE 提供者。

  3. 如果使用了使用者名稱記號，請在必要時配置使用者資料庫。使用使用者名稱/密碼記號時，必須配置適當的範圍，並為該範圍配置適當的使用者資料庫。

  4. 管理證書和私密金鑰 (如有必要)。

完成之後

如果已將 Application Server 的功能配置為供訊息安全性提供者使用，則可能會啟用隨 Application Server 一起安裝的提供者，如啟用訊息安全性的提供者中所述。

配置 JCE 提供者

J2SE 1.4.x 中包含的 Java 加密延伸 (JCE) 提供者不支援RSA 加密。由於由 WS-Security 定義的 XML 加密通常是基於 RSA 加密，因此，若要使用 WS-Security 來加密 SOAP 訊息，您必須下載並安裝支援 RSA 加密的 JCE 提供者。

備註 –

RSA 是 RSA Data Security, Inc. 開發的公開金鑰加密技術。RSA 的首字母縮略分別代表該技術的三位發明者：Rivest、Shamir 和 Adelman。

如果您是在 Java SDK 1.5 版中執行 Application Server，則 JCE 提供者已進行正確配置。如果您是在 Java SDK 1.4.x 版中執行 Application Server，請執行以下步驟，以靜態方式將 JCE 提供者增加為 JDK 環境的一部分：

  1. 下載並安裝 JCE 提供者 JAR (Java 歸檔) 檔案。

    透過以下 URL 可以獲得支援 RSA 加密的 JCE 提供者之清單：http://java.sun.com/products/jce/javase_providers.html。

  2. 將 JCE 提供者 JAR 檔案複製到 java-home/jre/lib/ext/。

  3. 停止 Application Server。

    如果未停止 Application Server 而後來又在該程序中將其重新啟動，則 Application Server 將無法識別 JCE 提供者。

  4. 在任何一種文字編輯器中編輯 java-home/jre/lib/security/java.security 特性檔案。將剛下載的 JCE 提供者增加至此檔案。

    java.security 檔案包含用於增加該提供者的詳細說明。通常，您需要在具有類似特性的某個位置處增加一行，其格式如下：


    security.provider.n=provider-class-name

    在此範例中，n 是 Application Server 計算安全性提供者時所使用的喜好設定順序。將剛才增加的 JCE 提供者的 n 設定為 2。

    例如，如果下載的是「The Legion of the Bouncy Castle JCE」提供者，則應增加以下行。


    security.provider.2=org.bouncycastle.jce.provider.
   BouncyCastleProvider

    確定將 Sun 安全性提供者保持在最高的喜好設定順序，其值為 1。


    security.provider.1=sun.security.provider.Sun

    將其他安全性提供者的層級調低，從而使每個層級上只有一個安全性提供者。

    以下是提供必要 JCE 提供者並將現有提供者保持在正確位置的 java.security 檔案範例。


    security.provider.1=sun.security.provider.Sun
security.provider.2=org.bouncycastle.jce.provider.
   BouncyCastleProvider
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.rsajca.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider

  5. 儲存並關閉檔案。

  6. 重新啟動 Application Server。

訊息安全性設定

為使用訊息安全性而對 Application Server 設定的大多數步驟都可以透過使用管理主控台、asadmin 指令行工具或透過手動編輯系統檔案來完成。通常，不建議編輯系統檔案，因為它可能會做出無意識的變更而使 Application Server 無法正常工作，因此，如有可能，建議優先選擇使用管理主控台來配置 Application Server，然後選擇使用 asadmin 工具指令。僅在無管理主控台或等效的 asadmin 時，才手動編輯系統檔案。

訊息層安全性支援以 (可插接式) 認證模組的形式整合在 Application Server 及其用戶端容器中。依預設，Application Server 中的訊息層安全性處於停用狀態。以下小節提供用於啟用、建立、編輯和刪除訊息安全性配置和提供者的詳細資訊。

大多數情況下，在執行以上管理作業後應重新啟動 Application Server。此步驟尤其適用於作業完成後，您要將管理變更的效果套用至 Application Server 上已部署應用程式中的情況。

啟用訊息安全性的提供者

若要為在 Application Server 中部署的 Web 服務端點啟用訊息安全性，則必須指定要在伺服器端依預設使用的提供者。若要啟用訊息安全性的預設提供者，您還需要啟用由 Application Server 中部署的 Web 服務之用戶端所使用的提供者。啟用應用程式用戶端的訊息安全性中討論了有關啟用用戶端使用的提供者之資訊。

若要啟用源自已部署端點的 Web 服務呼叫之訊息安全性，您必須指定預設用戶端提供者。如果已為 Application Server 啟用了預設用戶端提供者，則您必須確保在 Application Server 中部署的端點所呼叫的所有服務均配置為與訊息層安全性相容。

使用指令行公用程式：

配置訊息安全性提供者

通常應重新配置提供者以修改其訊息保護策略 (儘管提供者類型、實作類別和提供者特定的配置特性可能也需要修改)。

使用指令行公用程式來設定回應策略，以 response 取代下列指令中的 request。

建立訊息安全性提供者

若要使用管理主控台配置現有的提供者，請選取 [配置] 節點 > 要配置的實例 > [安全性] 節點 > [訊息安全性] 節點 > [SOAP] 節點 > [提供者] 標籤。

如需有關建立訊息安全性提供者的詳細說明，請參閱管理主控台線上說明。

啟用應用程式用戶端的訊息安全性

必須配置用戶端提供者的訊息保護策略，以使其等效於將與其進行互動式操作的伺服器端提供者的訊息保護策略。在安裝 Application Server 時已配置 (但未啟用) 的提供者符合此情況。

若要啟用用戶端應用程式的訊息安全性，請修改特定於 Application Server 的應用程式用戶端容器配置。

設定應用程式用戶端配置的請求策略和回應策略

請求策略和回應策略定義與認證提供者執行的請求處理和回應處理相關的認證策略需求。按照訊息寄件者的順序表示這些策略，從而使內容之後出現的加密請求意味著訊息收件者將在驗證簽名之前先要對訊息進行解密。

若要獲得訊息安全性，必須同時在伺服器和用戶端中啟用請求策略和回應策略。在用戶端和伺服器中配置策略時，請確定應用程式層級訊息連結之請求/回應保護的用戶端策略與伺服器策略相匹配。

若要設定應用程式用戶端配置的請求策略，請依循啟用應用程式用戶端的訊息安全性中的說明，修改特定於 Application Server 的應用程式用戶端容器配置。在應用程式用戶端配置檔案中，增加以下所示的 request-policy 和 response-policy 元素，以設定請求策略。

提供的其他代碼可用做參照。其他代碼在安裝中可能略有不同。請勿變更這些代碼。


<client-container>
  <target-server name="your-host" address="your-host"
      port="your-port"/>
  <log-service file="" level="WARNING"/>
  <message-security-config auth-layer="SOAP"
      default-client-provider="ClientProvider">
    <provider-config
        class-name="com.sun.enterprise.security.jauth.ClientAuthModule"
        provider-id="ClientProvider" provider-type="client">
      <request-policy auth-source="sender | content"
        auth-recipient="after-content | before-content"/>
      <response-policy auth-source="sender | content"
        auth-recipient="after-content | before-content"/>
       <property name="security.config"
           value="as-install/lib/appclient/wss-client-config.xml"/>
    </provider-config>
  </message-security-config>
</client-container>

auth-source 的有效值包括 sender 和 content。auth-recipient 的有效值包括 before-content 和 after-content。請求策略配置和回應策略配置的動作中提供了用於說明這些值的各種組合結果的表。

如果不想指定請求策略或回應策略，請將該元素保留為空白，例如：


<response-policy/>

詳細資訊