test

Sun Java System Application Server Enterprise Edition 8.1 2005Q2 管理指南

關於訊息安全性

訊息安全性概況

在訊息安全性中，安全性資訊會插入到訊息中，以使其透過網路層傳輸並附帶訊息到達訊息目標。訊息安全性與傳輸層安全性 (在「J2EE 1.4 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 以實現訊息安全性。

應用程式部署人員

應用程式部署人員負責：

「Developers’ Guide」中的「Securing Applications」一章將論述這些安全性作業。如需有關指向該章的連結，請參閱詳細資訊。

應用程式開發人員

應用程式開發者可以啟用訊息安全性，但並不是必須要這樣做。訊息安全性可以由系統管理員設定，以便確保所有 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 服務端點或服務參照相關聯，並符合要求以使其套用到相應端點或參照的服務的特定連接埠或方法。

如需有關針對各應用程式定義訊息保護策略的更多資訊，請參閱「Developers’ Guide」中的「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 範例應用程式安裝在以下目錄中：install-dir/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" 

OR 

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" 

OR 

auth-recipient="after-content" 

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

未指定策略。 

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

Procedure配置其他安全性功能

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

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

    配置 JCE 提供者中論述了如何配置 JCE 提供者。

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

    編輯範圍中論述了如何配置使用者資料庫。

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

    關於證書檔案中論述了如何管理憑證和私密金鑰。

接下來的步驟

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

Procedure配置 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/jce14_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。