test

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

關於 Application Server 的安全性

安全性簡介

安全性實質上就是資料保護：如何在儲存或傳輸資料時防止對資料進行未授權的存取或紐a。Application Server 具有基於 J2EE 標準的動態可延伸安全性架構。它內置的安全性功能包括密碼學、認證與授權以及公開金鑰基礎架構。Application Server 是基於 Java 安全性模型建置的，該安全性模型使用了一個沙箱，應用程式可以在沙箱中安全地執行，而不會給系統或使用者帶來潛在的危險。本節論述以下主題：

瞭解應用程式和系統安全性

從廣泛意義上講，應用程式安全性有兩種：

除了應用程式安全性以外，還有影響 Application Server 系統中所有應用程式的系統安全性。

程式安全性受應用程式開發者的控制，因此本文件不對其進行論述；宣告性安全性受應用程式開發者的控制要少一些，本文件中只偶爾涉及到宣告性安全性。本文件主要針對系統管理員，因此主要論述系統安全性。

管理安全性的工具

Application Server 提供了以下用於管理安全性的工具：

Java 2 Platform, Standard Edition (J2SE) 提供了兩個用於管理安全性的工具：

如需有關使用 keytool、policytool 和其他 Java 安全性工具的更多資訊，請參閱位於以下位置的「Java 2 SDK Tools and Utilities」：http://java.sun.com/j2se/1.4.2/docs/tooldocs/tools.html#security。

在 Enterprise Edition 中，還可以使用另外兩個實作網路安全服務 (NSS) 的工具來管理安全性。如需有關 NSS 的更多資訊，請至 http://www.mozilla.org/projects/security/pki/nss/。用於管理安全性的工具包括：

如需有關使用 certutil、pk12util 和其他 NSS 安全性工具的更多資訊，請參閱位於以下位置的「NSS Security Tools」：http://www.mozilla.org/projects/security/pki/nss/tools。

管理密碼安全性

在 Application Server 的此發行版本中，包含特定網域規格的 domain.xml 檔案最初包含純文字形式的 Sun Java System Message Queue 代理程式密碼。domain.xml 檔案中包含此密碼的元素為 jms-host 元素的 admin-password 屬性。由於在安裝期間不能變更此密碼，因此它不會對安全性產生很大的影響。

但是，您可以使用 管理主控台 增加使用者和資源，並為這些使用者和資源指定密碼。部分密碼將以純文字形式寫入 domain.xml 檔案，例如用於存取資料庫的密碼。將這些純文字形式的密碼保存在 domain.xml 檔案中可能會破壞安全性。透過執行以下程序，您可以加密 domain.xml 中的任何密碼，包括 admin-password 屬性或資料庫密碼。

Procedure加密 domain.xml 中的密碼

  1. 在 domain.xml 檔案常駐的目錄 (依預設，此目錄為 domain-dir/config) 中，執行以下 asadmin 指令：


    asadmin create-password-alias --user admin alias-name

    例如，


    asadmin create-password-alias --user admin jms-password

    螢幕將顯示輸入密碼提示 (在本範例中為 admin)。請參閱 create-password-alias、list-password-aliases 和 delete-password-alias 指令的線上手冊，以取得更多資訊。

  2. 移除並替代 domain.xml 中的密碼。使用 asadmin set 指令可以完成此作業。使用 set 指令實現此目的的範例如下：


    asadmin set --user admin server.jms-service.jms-host.
default_JMS_host.admin-password=${ALIAS=jms-password}

  3. 重新啟動相關網域的 Application Server。

保護具有編碼密碼的檔案

某些檔案包含需要使用檔案系統許可權進行保護的編碼密碼。這些檔案包括：

Procedure變更主密碼

主密碼 (MP) 是全局性的共用密碼。它從不用於認證，也從不會在網路上傳輸。此密碼是全局安全性的要塞點；使用者可以選擇在需要時手動輸入此密碼，也可以將其隱藏在檔案中。它是系統中最敏感的資料。使用者可以透過移除此檔案強制系統提示輸入 MP。變更主密碼後，系統會將其重新儲存到主密碼金鑰存放區中。

  1. 停止網域的 Application Server。使用 asadmin change-master-password 指令會提示輸入舊密碼和新密碼，然後重新加密所有附屬項目。例如，


    asadmin change-master-password>
Please enter the master password>
Please enter the new master password>
Please enter the the new master password again>

  2. 重新啟動 Application Server。

    注意 – 注意 –

    此時，不能啟動正在執行的伺服器實例並且不能重新啟動正在執行的伺服器實例，除非已變更這些實例所對映的節點代理程式上的 SMP。如果在變更伺服器實例的 SMP 之前重新啟動了該伺服器實例，它將無法啟動。

  3. 一次停止一個節點代理程式及其相關伺服器。再次執行 asadmin change-master-password 指令，然後重新啟動節點代理程式及其相關伺服器。

  4. 繼續對下一個節點代理程式執行這些步驟，直到對所有節點代理程式均已執行這些步驟。這樣可以完成輪替變更。

Procedure變更管理員密碼

管理密碼安全性中論述了如何加密管理員密碼。強烈建議您加密管理員密碼。若要在加密管理員密碼之前變更管理員密碼，請使用 asadmin set 指令。使用 set 指令實現此目的的範例如下：


asadmin set --user admin 
server.jms-service.jms-host.default_JMS_host.admin-password=new_pwd

還可以使用 管理主控台 變更管理員密碼，如以下程序所示。

  1. 在 管理主控台 樹形元件中，展開 [配置] 節點。

  2. 選取要配置的實例：

    • 若要配置特定實例，請展開該實例的配置節點。例如，對於預設實例 server，請展開 [server-config] 節點。

    • 若要為所有實例配置預設設定，請展開 [default-config] 節點。

  3. 展開 [安全性] 節點。

  4. 展開 [範圍] 節點。

  5. 選取 [admin-realm] 節點。

  6. 在 [編輯範圍] 頁面中，按一下 [管理使用者] 按鈕。

  7. 選取名為 admin 的使用者。

  8. 輸入新密碼並確認密碼。

  9. 按一下 [儲存] 以儲存新密碼，或者按一下 [關閉] 以關閉頁面而不儲存新密碼。

指定安全性職責

將為以下角色指定安全性職責：

應用程式開發人員

應用程式開發者負責：

應用程式部署者可以使用 deploytool 等工具編輯應用程式部署描述元。「The J2EE 1.4 Tutorial」中的「Security」一章詳細論述了這些安全性作業，您可以從以下 URL 中檢視該指導文件：http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html。

應用程式部署人員

應用程式部署人員負責：

應用程式部署者可以使用 deploytool 等工具編輯應用程式部署描述元。「The J2EE 1.4 Tutorial」中的「Security」一章詳細論述了這些安全性作業，您可以從以下 URL 中檢視該指導文件：http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html。

系統管理員

系統管理員負責：

系統管理員使用 管理主控台 管理伺服器安全性設定，並使用 certutil 管理憑證。本文件主要適用於系統管理員。

關於認證與授權

認證與授權是應用程式伺服器安全性的核心概念。以下主題論述了與認證和授權相關的內容：

認證實體

認證是實體 (使用者、應用程式或元件) 用於確定其他實體是否是其宣告的實體的方法。實體使用安全性憑證對其自身進行認證。憑證可以是使用者名稱和密碼、數位證書或其他憑證。

通常，認證表示使用者使用使用者名稱和密碼登入某個應用程式；也可以指 EJB 從伺服器請求資源時，提供安全性憑證。通常，伺服器或應用程式要求使用者端進行認證；另外，使用者端也可以要求伺服器對其自身進行認證。如果認證是雙向的，則稱為相互認證。

當實體嘗試存取受保護的資源時，Application Server 將使用為該資源配置的認證機制來確定是否授予存取權。例如，使用者可以在 Web 瀏覽器中輸入使用者名稱和密碼，如果應用程式順利完成了對這些憑證的驗證，則表示該使用者已通過認證。在此階段作業的剩餘時間內，該使用者將始終與這個經過認證的安全性身份相關聯。

Application Server 支援四種類型的認證，如認證實體所示。應用程式在其部署描述元中指定所使用的認證類型。如需有關使用 deploytool 配置應用程式認證方法的更多資訊，請參閱位於以下位置的「The J2EE 1.4 Tutorial」：http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html。

表 9–1 Application Server 認證方法

認證方法 

通訊協定 

說明 

使用者憑證加密 

基本 

HTTP (SSL 選取性) 

使用伺服器的內建快顯式登入對話方塊。 

無，除非使用 SSL。 

基於表單 

HTTP (SSL 選取性) 

應用程式提供它自己的自訂登入頁面和錯誤頁面。 

無，除非使用 SSL。 

使用者端證書 

HTTPS (基於 SSL 的 HTTP) 

伺服器使用公開金鑰證書認證使用者端。 

SSL 

驗證單次登入

單次登入可以讓一個虛擬伺服器實例中的多個應用程式共用使用者認證狀態。使用單次登入，登入到一個應用程式的使用者也會隱式登入到需要相同認證資訊的其他應用程式。

單次登入基於群組。其部署描述元可定義相同的群組並可使用相同認證方法 (基本、表單、摘要、憑證) 的所有 Web 應用程式均共用單次登入。

對於為 Application Server 定義的虛擬伺服器，依預設已啟用單次登入。如需有關停用單次登入的資訊，請參閱配置單次登入 (SSO)。

對使用者進行授權

使用者通過認證後，授權層級將決定該使用者可以執行哪些作業。使用者的授權基於其角色。例如，人力資源應用程式可以授權管理者檢視所有員工的個人資訊，但每個員工僅能檢視自己的個人資訊。如需有關角色的更多資訊，請參閱瞭解使用者、群組、角色和範圍。

指定 JACC 提供者

JACC (Java 容器授權合約) 屬於 J2EE 1.4 規格，它定義可插接式授權提供者介面。這可以讓管理員設置協力廠商外掛程式模組以執行授權。

依預設，Application Server 提供符合 JACC 規格並基於檔案的簡單授權引擎。還可以指定其他協力廠商 JACC 提供者。

JACC 提供者使用 Java 認證與授權服務 (JAAS) API。JAAS 可以讓服務對使用者進行認證並強制對使用者進行存取控制。JAAS 實作了 Java 技術版本的標準可插接式認證模組 (PAM) 框架。

稽核認證與授權決策

Application Server 可以透過稽核模組提供對所有認證與授權決策的稽核追蹤。Application Server 提供預設的稽核模組，還提供了自訂稽核模組的功能。如需有關開發自訂稽核模組的資訊，請參閱「Application Server Developer's Guide」。

配置訊息安全性

訊息安全性可以讓伺服器在訊息層執行 Web 服務呼叫和回應的點對點認證。Application Server 使用 SOAP 層上的訊息安全性提供者實作訊息安全性。訊息安全性提供者提供以下資訊，例如請求訊息和回應訊息所需的認證類型。受支援的認證類型包括：

此發行版本包括兩個訊息安全性提供者。可以為 SOAP 層的認證配置訊息安全性提供者。可以配置的提供者包括 ClientProvider 和 ServerProvider。

訊息層安全性支援以 (可插接式) 認證模組的形式整合在 Application Server 及其用戶端容器中。依預設，Application Server 中的訊息層安全性處於停用狀態。

您可以為整個 Application Server 或者為特定的應用程式或方法配置訊息層安全性。第 10 章, 配置訊息安全性中論述了如何配置 Application Server 層級的訊息安全性。Developer’s Guide 中的「Securing Applications」一章論 述了如何配置應用程式層級的訊息安全性 。

瞭解使用者、群組、角色和範圍

Application Server 對以下實體強制執行其認證與授權策略：

備註 –

儘管使用者和群組是為整個 Application Server 指定的，但是每個應用程式都需要定義自己的角色。封裝和部署應用程式時，應用程式會指定使用者/群組和角色之間的對映，如下圖所示。

圖 9–1 角色對映

此圖顯示為群組指定使用者的方式、為角色指定使用者和群組的方式，以及應用程式使用群組和角色的方式。

使用者

使用者是已在 Application Server 中定義的個人 (或應用程式) 身份。使用者可以與群組關聯。Application Server 認證服務可以管理多個範圍中的使用者。

群組

J2EE 群組 (或簡稱群組) 是依循一般特性 (例如職務或用戶設定檔) 進行分類的使用者類別。例如，假定電子商務應用程式的使用者屬於 customer 群組，但是大用戶可以屬於 preferred 群組。將使用者進行群組分類可以簡化有大量使用者時的存取控制。

角色

角色定義使用者可以存取哪些應用程式以及每個應用程式的哪些部分，以及使用者可以執行的作業。亦即，角色決定了使用者的授權層級。

例如，假定在人事應用程式中，所有員工均可以存取電話號碼和電子郵件位址但只有管理者才能存取薪水資訊。該應用程式至少可以定義兩個角色：employee 和 manager；僅允許 manager 角色中的使用者檢視薪水資訊。

角色與使用者群組的不同之處在於，角色在應用程式中定義功能，而使用者群組是以某一方式相關的一組使用者。例如，假定在人事應用程式中有 full-time、part-time 和 on-leave 幾個群組，但所有這些群組中的使用者仍是 employee 角色。

角色是在應用程式部署描述元中定義的。相反，群組是針對整個伺服器和範圍而定義的。應用程式開發者或部署者在每個應用程式的部署描述元中將角色對映至一個或多個群組。

範圍

範圍 (也稱為安全策略網域或安全網域)，是伺服器定義和強制執行一般安全策略的範圍。在實際應用中，範圍是伺服器儲存使用者和群組資訊的儲存庫。

Application Server 預先配置了三個範圍：file (初始預設範圍)、certificate 和 admin-realm。您還可以設定 ldap、solaris 範圍或自訂範圍。應用程式可以在其部署描述元中指定要使用的範圍。如果應用程式不指定範圍，Application Server 將使用其預設範圍。

在 file 範圍中，伺服器將使用者憑證儲存在本地名為 keyfile 的檔案中。您可以使用 管理主控台 來管理 file 範圍中的使用者。如需更多資訊，請參閱管理 file 範圍使用者。

在 certificate 範圍中，伺服器將使用者憑證儲存在憑證資料庫中。使用 certificate 範圍時，伺服器結合使用憑證和 HTTPS 通訊協定認證 Web 用戶端。如需有關憑證的更多資訊，請參閱證書和 SSL 簡介。

admin-realm 也是一個 FileRealm，它將管理員使用者憑證儲存在本地名為 admin-keyfile 的檔案中。您可以使用 管理主控台 管理此範圍中的使用者，其方法與您管理 file 範圍中的使用者的方法相同。如需更多資訊，請參閱管理 file 範圍使用者。

在 ldap 範圍中，伺服器將從簡易資料存取協定 (LDAP) 伺服器 (例如 Sun Java System Directory Server) 中取得使用者憑證。LDAP 是一種可以讓任何人在網路 (無論是公共網際網路還是企業內部網路) 中尋找組織、個人和其他資源 (例如檔案和裝置) 的協定。如需有關管理 ldap 範圍中的使用者和群組的資訊，請參閱您的 LDAP 伺服器文件。

在 solaris 範圍中，伺服器將從 Solaris 作業系統中取得使用者憑證。Solaris 9 OS 和更高版本支援此範圍。如需有關管理 solaris 範圍中的使用者和群組的資訊，請參閱您的 Solaris 文件。

自訂範圍是使用者憑證的任何其他儲存庫，例如關聯式資料庫或協力廠商元件。如需更多資訊，請參閱建立自訂範圍。

證書和 SSL 簡介

本節論述以下主題：

關於數位證書

數位憑證 (或簡稱憑證) 是在網際網路上唯一識別人員和資源的電子檔案。證書還可以使兩個實體之間能夠進行安全、機密的通訊。

證書有很多種類型，例如個人證書 (由個人使用) 和伺服器證書 (用於透過安全套接字層 [SSL] 技術在伺服器和使用者端之間建立安全階段作業)。如需有關 SSL 的更多資訊，請參閱關於安全套接字層。

憑證以公開金鑰密碼學為基礎，公開金鑰密碼學使用數位金鑰 (很長的數位) 對資訊進行加密或編碼，從而使資訊只能被指定的接收者讀取。然後，接收者對資訊進行解密 (解碼)，即可讀取該資訊。

一個金鑰對包含一個公開金鑰和一個私密金鑰。所有者對公開金鑰進行發放並使任何人都可以使用該公開金鑰。但是所有者永遠不會發放私密金鑰；私密金鑰始終是保密的。由於金鑰與數學相關，因此使用了金鑰對中的一個金鑰進行加密的資料只能透過金鑰對中的另一個金鑰進行解密。

證書就好像一本護照：它可以識別持有者並提供其他重要資訊。憑證由稱為憑證授權單位 (CA) 的可信任的協力廠商發行。CA 類似於護照申領辦公室：它將驗證憑證持有者的身份並對憑證進行簽名，以使他人無法偽造或竄改憑證。CA 對證書進行簽名之後，持有者可以提供該證書做為身份證明並建立加密的機密通訊。

最重要的是，憑證會將所有者的公開金鑰連結至所有者身份。與護照將照片連結至其持有者的個人資訊類似，證書將公開金鑰連結至有關其所有者的資訊。

除了公開金鑰以外，證書通常還包括以下資訊：

數位憑證受 x.509 格式的技術規格約束。若要驗證 certificate 範圍中某個使用者的身份，認證服務將使用 X.509 憑證的一般名稱欄位做為主體名稱對 X.509 憑證進行驗證。

關於證書鏈

Web 瀏覽器已預先配置了一組瀏覽器自動信任的根 CA 憑證。來自其他憑證授權單位的所有憑證都必須附帶憑證鏈，以驗證這些憑證是否有效。憑證鏈是由連續 CA 憑證發行的憑證序列，最終以根 CA 憑證結束。

憑證最初產生時是自簽名憑證。自簽名證書是其發行者 (簽名者) 與主旨 (其公開金鑰由該證書進行認證的實體) 相同的證書。如果所有者向 CA 傳送證書簽名請求 (CSR)，然後輸入回應，自簽名證書將被證書鏈取代。鏈的底部是由 CA 發行的、用於認證主旨的公開金鑰證書 (回覆)。鏈中的下一個證書是認證 CA 公開金鑰的證書。通常，這是一個自簽名證書 (即，來自 CA、用於認證其自身公開金鑰的證書)，並且是鏈中的最後一個證書。

在其他情況下，CA 可能會傳回一個證書鏈。在此情況下，鏈的底部證書是相同的 (由 CA 簽名的證書，用於認證金鑰項目的公開金鑰)，但是鏈中的第二個證書是由其他 CA 簽名的證書，用於認證您向其傳送了 CSR 的 CA 的公開金鑰。然後，鏈中的下一個憑證是用於認證第二個 CA 金鑰的憑證，依此類推，直至到達自簽名的根憑證。因此，鏈中的每個證書 (第一個證書之後的證書) 都需要認證鏈中前一個證書的簽名者的公開金鑰。

關於安全套接字層

安全套接字層 (SSL) 是用於確定網際網路通訊和作業事件保護的最常見標準。Web 應用程式使用 HTTPS (基於 SSL 的 HTTP)，HTTPS 使用數位證書來確保在伺服器和使用者端之間進行安全、機密的通訊。在 SSL 連線中，使用者端和伺服器在傳送資料之前都要對資料進行加密，然後由接受者對其進行解密。

Web 瀏覽器 (用戶端) 需要與某個安全站點建立連線時，則會發生 SSL 交換︰

交握之後，即表示使用者端已驗證了網站的身份，並且只有該使用者端和 Web 伺服器擁有該階段作業金鑰副本。從現在開始，使用者端和伺服器便可以使用該階段作業金鑰對彼此間的所有通訊進行加密。這樣就確保了使用者端和伺服器之間的通訊的安全。

SSL 標準的最新版本稱為 TLS (傳輸層安全性)。Application Server 支援安全套接字層 (SSL) 3.0 和傳輸層安全性 (TLS) 1.0 加密協定。

若要使用 SSL，Application Server 必須擁有接受安全連線的每個外部介面或 IP 位址的憑證。只有安裝了數位證書之後，大多數 Web 伺服器的 HTTPS 服務才能夠執行。請使用使用 keytool 公用程式產生憑證中說明的程序來設定 Web 伺服器可以用於 SSL 的數位憑證。

關於加密算法

加密算法是用於加密或解密的加密演算法。SSL 和 TLS 協定支援用於伺服器和使用者端彼此進行認證、傳輸證書和建立階段作業金鑰的各種加密算法。

某些加密算法比其他加密算法更強大且更安全。使用者端和伺服器可以支援不同的密碼組。從 SSL3 和 TLS 協定中選取加密算法。在安全連線期間，使用者端和伺服器同意在通訊中使用它們均已啟用的最強大的加密算法，因此通常需要啟用所有加密算法。

使用基於名稱的虛擬主機

對安全應用程式使用基於名稱的虛擬主機可能會帶來問題。這是 SSL 協定本身的設計限制。必須先進行 SSL 交握 (使用者端瀏覽器在此時接受伺服器證書)，然後才能存取 HTTP 請求。這樣，在認證之前就無法確定包含虛擬主機名稱的請求資訊，因此也不能將多個證書指定給單一 IP 位址。

如果單一 IP 位址上的所有虛擬主機均需要對照同一證書進行認證，則增加多個虛擬主機將不會影響伺服器上正常的 SSL 作業。但是請注意，大多數瀏覽器會將伺服器的網域名稱與憑證中列示的網域名稱 (如果有，且主要適用於官方 CA 簽名憑證) 進行對照。如果網域名稱不匹配，這些瀏覽器將顯示警告。通常在生產環境中，只將基於位址的虛擬主機與 SSL 配合使用。

關於防火牆

防火牆控制兩個或多個網路之間的資料流，並管理網路之間的連結。防火牆可能包含硬體和軟體元素。本節描述了一些一般防火牆架構及其配置。此處的資訊主要針對 Application Server。如需有關特定防火牆技術的詳細資訊，請參閱防火牆供應商提供的文件。

通常，需要對防火牆進行配置，以便使用者端存取所需的 TCP/IP 連接埠。例如，如果 HTTP 偵聽程式正在連接埠 8080 上作業，則將防火牆配置為僅允許處理連接埠 8080 上的 HTTP 請求。同樣地，如果為連接埠 8181 設定了 HTTPS 請求，則必須將防火牆配置為允許處理連接埠 8181 上的 HTTPS 請求。

如果需要從網際網路對 EJB 模組進行直接的 RMI-IIOP (全稱為 Remote Method Invocations over Internet Inter-ORB Protocol [通過網際網路 ORB 交換協定的遠端方法呼叫]) 存取，則還需要開啟 RMI-IIOP 偵聽程式連接埠，但強烈建議您不要這樣做，因為這樣可能會破壞安全性。

在雙防火牆架構中，您必須將外部防火牆配置為允許處理 HTTP 和 HTTPS 作業事件。您必須將內部防火牆配置為允許 HTTP 伺服器外掛程式與防火牆後面的 Application Server 進行通訊。

使用 管理主控台 管理安全性

管理主控台 提供了對安全性的以下方面進行管理的方法：

伺服器安全性設定

在 [安全性設定] 頁面中，設定整個伺服器的特性，包括指定預設範圍、匿名角色和預設的主體使用者名稱和密碼。如需更多資訊，請參閱配置安全性設定。

範圍和 file 範圍使用者

瞭解使用者、群組、角色和範圍中介紹了範圍的概念。

請參閱有關範圍的 管理主控台 作業，以取得有關這些作業的詳細資訊。

JACC 提供者

指定 JACC 提供者中介紹了 JACC 提供者。使用 管理主控台 執行以下作業：

請參閱有關 JACC 提供者的 管理主控台 作業，以取得有關這些作業的詳細資訊。

稽核模組

稽核認證與授權決策中介紹了稽核模組。稽核是記錄重要事件 (例如錯誤或安全性漏洞) 以進行後續檢查的方法。所有認證事件都被記錄到 Application Server 記錄中。完整的存取記錄提供了 Application Server 存取事件的循序追蹤。

使用 管理主控台 執行以下作業：

請參閱有關稽核模組的 管理主控台 作業，以取得有關這些作業的詳細資訊。

訊息安全性

配置訊息安全性中介紹了訊息安全性的概念。使用 管理主控台 執行以下作業：

請參閱第 10 章, 配置訊息安全性，以取得有關這些作業的詳細資訊。

HTTP 和 IIOP 偵聽程式安全性

HTTP 服務中的每個虛擬伺服器都透過一個或多個 HTTP 偵聽程式提供網路連線。如需有關 HTTP 服務和 HTTP 偵聽程式的一般資訊，請參閱什麼是 HTTP 服務？。

Application Server 支援 CORBA (共用物件請求代理程式架構) 物件，這類物件使用網際網路 Orb 交換協定 (IIOP) 在網路上進行通訊。IIOP 偵聽程式接受來自 EJB 的遠端用戶端和其他基於 CORBA 之用戶端的內送連線。如需有關 IIOP 偵聽程式的一般資訊，請參閱IIOP 偵聽程式。

使用 管理主控台 執行以下作業：

請參閱有關偵聽程式和 JMX 連接器的 管理主控台 作業，以取得有關這些作業的詳細資訊。

管理服務安全性

管理服務決定伺服器實例是一般實例、網域管理伺服器 (DAS)，還是兼具兩者。使用管理服務可以配置 JSR-160 相容遠端 JMX 連接器，該連接器處理網域管理伺服器與遠端伺服器實例的節點代理程式 (管理主機電腦上的伺服器實例) 之間的通訊。

使用 管理主控台 執行以下作業：

請參閱配置管理服務之 JMX 連接器的安全性，以取得有關這些作業的詳細資訊。

安全性對映

關於安全性對映中介紹了用於連接器連線池的安全性對映的概念。使用 管理主控台 執行以下作業：

請參閱有關連接器連線池的 管理主控台 作業，以取得有關這些作業的詳細資訊。