DCC HTTP 反向代理主機與 OAM 和 OAM

本文探討 11.1.2.2.0 版本中導入的「分離式證明資料收集器 (DCC) HTTP 反向代理主機」功能。

在啟用此功能的部署中，WebGate SSO 代理程式：

在此模式中，使用者 / 從屬端與 OAM 之間的所有互動都是透過 WebGate DCC HTTP 反向代理主機完成：使用者將不再直接存取 OAM 伺服器。

此新的 DCC HTTP 反向代理主機功能與 HTTPBasic/FORM 式登入的先前 DCC 不同，後者不適用於聯合 SSO 流程 (IdP 或 SP 模式)。

概觀

本文不包括任何內含 HTTP 反向代理主機或負載平衡器，且前面有各種 OAM 元件 (OAM 伺服器本身或 WebGate 代理程式) 的拓樸，但前面卻包含說明如何在高可用性部署中使用 DCC HTTP 反向代理主機的使用案例。

無 DCC 認證

不含 DCC 的認證流程是最常見的使用案例，其中會將使用者從保護安全網域中資源的 SSO 代理程式重新導向至 OAM 以進行查問和認證。典型的 OAM 部署是由下列實體組成：

下圖說明此類環境：

local_security_domain.jpg 圖解說明

在測試流程中，使用 LDAPScheme OOTB 作為配置來保護本機安全網域的資源。

使用 LDAPScheme 的本機認證流程包含下列項目：

  1. 使用者要求存取 OAM 中定義的受保護資源，以受 LDAPScheme 保護。

  2. WebGate SSO 代理程式會攔截 HTTP 要求，判斷需要認證使用者，並將使用者重新導向 OAM 伺服器以進行認證。

  3. 使用者存取 OAM 伺服器；伺服器會使用 LDAPScheme 起始認證流程並顯示登入頁面

local_authentication_flow.jpg 圖解說明

使用者輸入其證明資料並按一下登入按鈕後，會發生下列情況：

  1. OAM 伺服器會驗證證明資料、為使用者建立階段作業、在使用者的瀏覽器中設定 Cookie，然後將使用者重導至受保護的資源。

  2. 使用者要求存取資源。這次，「WebGate SSO 代理程式」偵測到使用者已通過認證並授予資源存取權。

local_security_workflow.jpg 圖解說明

以 HTTP-Basic/FORM 為基礎的登入 DCC

舊版的 OAM 11g 引進 HTTP-Basic/FORM 式登入的 DCC，並提供管理員將 WebGate SSO 代理程式指定為實體的方式：

在測試流程中，使用以 LDAPScheme OOTB 為基礎的 DCCLDAPScheme，但「查問 URL」更新為參照 DCC WebGate。此配置是用來保護本機安全網域的資源。

使用該自訂 DCCLDAPScheme 的本機認證流程包含下列項目：

  1. 使用者要求存取 OAM 中定義的受保護資源，以受 DCCLDAPScheme 保護。

  2. WebGate SSO 代理程式會攔截 HTTP 要求，判斷需要認證使用者，並將使用者重新導向至 DCC WebGate 的登入頁面以進行認證。

  3. 使用者存取 DCC WebGate 的登入頁面並提供證明資料。

  4. DCC WebGate 會直接與 OAM 伺服器 (其他 OAM NAP 協定) 互動，以驗證證明資料並建立使用者的階段作業。然後，DCC WebGate 會將使用者重新導向受保護的資源。

  5. 使用者要求存取資源。這次，「WebGate SSO 代理程式」偵測到使用者已通過認證並授予資源存取權。

DCC HTTP 反向代理主機

DCC HTTP 反向代理主機在 OAM 的 11.1.2.2.0 版本中導入，並允許管理員將 WebGate SSO 代理程式設定為 OAM 和 OAM 伺服器的公用端點：

注意：基本上，DCC WebGate 會成為 OAM 和 OAM 的公用端點，並透過 OAM NAP 協定作為 HTTP 反向代理主機。

在此測試中，為 DCC HTTP 反向代理主機設定 OAM 和 WebGate 之後，並使用 LDAPScheme OOTB 作為配置來保護本機安全網域的資源 (配置不會變更)。

注意：此 DCC 模式 (例如 FederationScheme) 可使用任何「查問 URL」包含相對路徑的認證配置。此外，IdP 功能與該 DCC 模式相容

使用 LDAPScheme 的本機認證流程包含下列項目：

  1. 使用者要求存取 OAM 中定義的受保護資源，以受 LDAPScheme 保護。

  2. WebGate SSO 代理程式會攔截 HTTP 要求，判斷需要認證使用者，並將使用者重新導向至 DCC WebGate 以進行認證。

  3. 使用者存取 DCC WebGate 並將要求轉送至 OAM 伺服器；伺服器使用 LDAPScheme 起始認證流程，傳回要對 DCC WebGate 顯示的登入頁面，而 DCC WebGate 則會將登入頁面顯示給使用者。

local_authentication_flow_LDAP.jpg 圖解說明

使用者輸入證明資料並按一下登入按鈕後，會發生下列情況：

  1. DCC WebGate 會將包含證明資料的 HTTP 要求傳送至 OAM 伺服器以進行驗證、為使用者建立階段作業、建立 Cookie 並傳回含 Cookie 的 HTTP 回應以及 DCC WebGate 的重新導向命令；DCC WebGate 會在使用者的瀏覽器中設定 Cookie，並將使用者重新導向至受保護的資源。

  2. 使用者要求存取資源。這次，「WebGate SSO 代理程式」偵測到使用者已通過認證並授予資源存取權。

local_security_LDAPworkflow.jpg 圖解說明

設定 DCC HTTP 反轉代理主機

起始設定

設定「DCC HTTP 反向代理主機」之 OAM 建置所需的步驟分為：

若要將特定的 WebGate SSO 代理程式設定為 DCC WebGate，請執行下列步驟：

  1. 前往「OAM 管理主控台」：http(s)://oam-admin-host:oam-adminport/oamconsole。

  2. 瀏覽至 Access Manager 、 SSO 代理程式。

  3. 搜尋您已經註冊的 WebGate 項目。

  4. 按一下並開啟 WebGate 項目。

  5. 勾選允許證明資料收集器作業 (Allow Credentials Collector Operation) 方塊。

  6. 在「使用者定義參數」方塊中，新增下列行：TunneledUrls=/oam,/oamfed。

  7. 按一下套用。

Setting_DCC.jpg 圖解說明

若要更新 OAM 和 OAM 服務的認證原則，請執行以下步驟：

  1. 前往「OAM 管理主控台」：http(s)://oam-admin-host:oam-adminport/oamconsole。

  2. 瀏覽至 Access Manager 、 Application Domains 。

  3. 搜尋與 DCC WebGate 相關的應用程式網域。

  4. 開啟應用程式網域。

  5. 按一下「資源」標籤。

  6. 將資源標示為「未受保護」，並設定公用認證原則和公用授權原則，以將下列資源設為公用資源：

  7. 按一下套用

Authentication_Policies.jpg 圖解說明

更新 OAM 組態以指定 DCC WebGate 作為 OAM 的新公用端點

  1. 前往「OAM 管理主控台」：http(s)://oam-admin-host:oam-adminport/oamconsole。

  2. 瀏覽至 Configuration 、 Access Manager 設定值。

  3. 在「OAM 伺服器主機」中，輸入用來透過瀏覽器存取 DCC WebGate 的主機名稱。

  4. 在「OAM 伺服器連接埠」中，輸入用來透過瀏覽器存取 DCC WebGate 的連接埠。

  5. 在「OAM 伺服器協定」中，輸入用來透過瀏覽器存取 DCC WebGate 的 http 協定。

  6. 完成之後，這三個欄位應該參照 DCC WebGate HTTP/HTTPS 端點。

  7. 按一下套用。

OAM_configuration.jpg 圖解說明

完成三個組態變更之後，OAM 和 OAM 會設定為透過 NAP 協定使用 DCC WebGate 作為 HTTP 反向代理主機。

在測試中，如果已在 OAM 管理主控台的 Configuration Available Services 區段中啟用同盟，您可以透過 DCC WebGate URL：http(s)://dcc-webgatehost:dcc-webgate-port/oamfed/idp/metadata 存取 OAM 描述資料，它應該顯示 OAM 的 SAML 2.0 描述資料。在我的設定中，「描述資料」顯示無須重新啟動任何服務，而聯合服務的 URL 會參照 DCC WebGate 位置，而不是 OAM 伺服器。

注意：如果需要更新聯合 ProviderID，您可以透過 OAM 管理主控台、組態、聯合來進行更新，而變更會反映在中繼資料的 entityID 屬性中。

描述資料的範例為 (entityID 是衍生自 OAM 管理主控台、組態、聯合區段 )：

<md:EntityDescriptor entityID="hUp://oam.acme.com
/oam/fed" ...>
  ...
  <md:IDPSSODescriptor>
    ...
    <md:ArtifactResolutionService ...
Location="hUp://dcc-webgate.acme.com:7777
/oamfed/idp/soap"/>
    <md:SingleLogoutService ... Location="hUp://dccwebgate.acme.com:7777/oamfed/idp/samlv20"/>     <md:SingleSignOnService ... Location="hUp://dccwebgate.acme.com:7777/oamfed/idp/samlv20"/>
    ...
  </md:IDPSSODescriptor>
  ...
</md:EntityDescriptor>

本機認證

在我的測試部署中，我已部署下列項目：

LDAPScheme 是 OOTB 1，尚未修改，特別是「查問 URL」參數未參照 WebGate DCC：

Local_Authentication.jpg 圖解說明

設定 OAM、OAM 以及 WebGate2 for DCC HTTP Reverse Proxy 之前，要求存取 OHS1 上的 /cgi-bin/printenv 受保護資源，導致 WebGate1 攔截要求，並將瀏覽器重新導向至 OAM 伺服器以進行認證：

Access_Manager_Screen.jpg 圖解說明

輸入正確的證明資料時，OAM 會驗證使用者名稱 / 密碼，並將瀏覽器重新導向至受保護的資源。

設定 OAM、OAM 和 WebGate2 for DCC HTTP Reverse Proxy 之後，要求存取 OHS1 上的 /cgi-bin/printenv 受保護資源，現在 WebGate1 會攔截要求並重新導向將 HTTP 要求透過 NAP 協定轉送至 OAM 伺服器 (傳送回 DCC WebGate 的頁面) 進行認證的瀏覽器：

Protected_Access_Screen.jpg 圖解說明

輸入正確的證明資料時，會發生下列情況：

OAM 作為 SP

這個模式與本機認證使用案例略有不同。唯一的差異是：

注意：使用 FederationScheme 與 DCC HTTP 反向代理主機時不需要特殊組態！

FederationScheme 是 OOTB 1，尚未修改，特別是「查問 URL」參數未參照 WebGate DCC：

Authentication_Schemes.jpg 圖解說明

要求受保護資源時，會發生下列情況：

  1. 使用者要求存取 OAM 中定義的受保護資源，以受 FederationScheme 保護。

  2. WebGate SSO 代理程式會攔截 HTTP 要求，判斷需要認證使用者，並將使用者重新導向至 DCC WebGate 以進行認證。

  3. 使用者存取 DCC WebGate，將 HTTP 要求封裝並透過 NAP 傳送至 OAM 伺服器；伺服器會判斷使用者需要透過 FederationScheme 進行挑戰，並呼叫 OAM/SP 模組。

  4. OAM/SP 會建立 SAML 要求，並建構含有 SAML 訊息的 302 重新導向 URL；OAM 會封裝資料並將回應傳回給使用者瀏覽器的 DCC WebGate。

  5. 使用者的瀏覽器已使用 SAML 要求重新導向至 IdP

Protected_Resource_Request.jpg 圖解說明

使用者在 IdP 輸入其證明資料之後，會發生下列情況：

  1. IdP 會建立「SAML 宣告」，並將含有 SAML 訊息的使用者瀏覽器重新導向至 DCC WebGate (發佈於「SAML 2.0 描述資料」中的 OAM 同盟端點)。

  2. 使用者的瀏覽器會將「SAML 宣告」呈現給 DCC WebGate，這會封裝 HTTP 要求並透過 NAP 傳送至 OAM 伺服器，進而呼叫 OAM/SP 模組來處理「SAML 宣告」。

  3. OAM/SP 會驗證「SAML 宣告」，OAM 會建立使用者階段作業，建立 302 重新導向至受保護資源，並將回應傳回 DCC WebGate，以將 HTTP 回應傳回給使用者的瀏覽器。

  4. 使用者被重導至受保護的資源

  5. WebGate SSO 代理程式授予存取權

local_security_Webgatedomain.jpg 圖解說明

OAM 做為 IdP

在此使用案例中，OAM 會作為身分識別提供者，而 DCC WebGate 是 IdP 的公用端點。在此設定中：

注意：將 IdP 與 DCC HTTP Reverse Proxy 搭配使用並不需要特殊組態！

當使用者從遠端 SP 起始同盟 SSO 時，會發生下列情況：

  1. 使用者在遠端 SP 啟動「同盟 SSO」作業。

  2. 遠端 SP 會建立 SAML 要求，並使用 SAML 要求將使用者重新導向至 IdP SAML 2.0 端點：此端點是 DCC WebGate HTTP 反向代理主機，如 IdP SAML 2.0 描述資料中所發布。

  3. 使用者使用 SAML 要求在 DCC WebGate 存取 IdP 公用 SAML 2.0 端點；DCC WebGate 會封裝 HTTP 要求和 SAML 訊息，並透過 OAM NAP 協定將它轉送至 IdP 伺服器。

  4. IdP 伺服器會處理 SAML 要求，判斷使用者必須透過 LDAPScheme 進行認證，在內部呼叫 OAM 進行認證，進而返回 DCC WebGate 要顯示的登入頁面；DCC WebGate 會解碼透過 NAP 傳送的 OAM 回應，並將 HTTP 回應傳回給使用者的瀏覽器。

local_security_FedSSO.jpg 圖解說明

顯示登入頁面之後，會發生下列情況：

  1. 使用者輸入其證明資料，然後按一下登入按鈕。

  2. DCC WebGate 會收集內送資料、封裝並透過 NAP 傳送至 OAM 伺服器。

  3. OAM 會驗證證明資料、為使用者建立階段作業，並在內部將使用者的識別傳回 IdP；「聯合」伺服器會建立「SAML 宣告」，並建立包含「宣告」的回應、將它封裝並傳回 DCC WebGate，進而解碼資料，並將「SAML 宣告」的「HTTP 回應」傳送至使用者的瀏覽器。

  4. 使用者的瀏覽器會將 SAML 回應張貼至 SP，以順利驗證宣告。

local_security_DCCWebgate.jpg 圖解說明

DCC HTTP 反向代理主機和 HA

在 HA 部署中，設定各種元件 (負載平衡器、OAM...) 所需的步驟仍適用於使用 DCC HTTP 反向代理主機功能時。

以下列部署範例為例 (其他類型的 HA 拓樸使用類似的方法)：

此範例中的拓樸看起來如下：

local_security_Topology.jpg 圖解說明

此範例中所需的步驟是根據：

其他學習資源

探索 docs.oracle.com/learn 上的其他實驗室，或存取 Oracle Learning YouTube 頻道上的更多免費學習內容。此外，瀏覽 education.oracle.com/learning-explorer 成為 Oracle Learning Explorer。

如需產品文件，請造訪 Oracle Help Center 。