共用方式為

教學課程：使用 Azure Active Directory B2C 設定 Ping 身分識別來進行安全的混合式存取

  • 發行項

在本教學課程中，瞭解如何使用 PingAccess 和 PingFederate擴充 Azure AD B2C (Azure AD B2C) 的功能。 PingAccess 提供應用程式和 API 的存取權，以及授權使用者存取的原則引擎。 PingFederate 是企業同盟伺服器，用於使用者驗證和單一登入，這是允許客戶、員工和合作夥伴從裝置存取應用程式的授權單位。 將它們搭配使用，以在 SHA) (啟用安全的混合式存取。

許多公開至網際網路的電子商務網站和 Web 應用程式都會部署在 Proxy 系統或反向 Proxy 系統後方。 這些 Proxy 系統會預先驗證、強制執行原則，以及路由流量。 一般案例包括保護 Web 應用程式免于輸入 Web 流量，以及跨分散式伺服器部署提供統一會話管理。

一般而言，組態包含驗證轉譯層，可將 Web 應用程式的驗證外部化。 反向 Proxy 會將已驗證的使用者內容提供給 Web 應用程式，例如純文字或摘要格式的標頭值。 應用程式不會使用業界標準權杖，例如 SAML) 、OAuth 或 OpenID Connect (SAML) 、OAuth 或 OpenID Connect (OIDC) 。 相反地，Proxy 會提供驗證內容，並與使用者代理程式維護會話，例如瀏覽器或原生應用程式。 做為中間人執行的服務，Proxy 提供重要的會話控制。 Proxy 服務有效率且可調整，而不是 Proxy 服務背後的應用程式瓶頸。 此圖表是反向 Proxy 實作和通訊流程。

反向 Proxy 實作的圖表。

現代化

如果您想要在這類設定中現代化身分識別平臺，可能會有客戶疑慮：

  • 將應用程式現代化與將身分識別平臺現代化的工作分離
  • 具有現代化和舊版驗證的環境，從現代化身分識別服務提供者取用
    • 推動使用者體驗一致性
    • 跨應用程式提供單一登入體驗

為了回答這些疑慮，本教學課程中的方法是 Azure AD B2C、 PingAccess和 PingFederate 整合。

共用環境

技術上可行且符合成本效益的解決方案是將反向 Proxy 系統設定為使用現代化身分識別系統，並委派驗證。
Proxy 支援新式驗證通訊協定，並使用重新導向型 (被動) 驗證，將使用者傳送至新的識別提供者 (IdP) 。

作為識別提供者的 Azure AD B2C

在 Azure AD B2C 中，您會定義可驅動使用者體驗和行為的原則，也稱為使用者旅程圖。 每個這類原則都會公開通訊協定端點，以 IdP 身分執行驗證。 在應用程式端，某些原則不需要特殊處理。 應用程式會對原則公開的通訊協定特定驗證端點提出標準驗證要求。
您可以設定 Azure AD B2C 跨原則或每個原則的唯一簽發者共用相同的簽發者。 每個應用程式都可以透過發出通訊協定原生驗證要求來指向原則，以驅動使用者行為，例如登入、註冊和設定檔編輯。 此圖顯示 OIDC 和 SAML 應用程式的工作流程。

OIDC 和 SAML 應用程式工作流程的圖表。

繼承應用程式的案例可能很困難，無法正確重新導向使用者。 應用程式的存取要求可能不會包含使用者體驗內容。 在大部分情況下，Proxy 層或 Web 應用程式上的整合式代理程式會攔截存取要求。

PingAccess 反向 Proxy

您可以將 PingAccess 部署為反向 Proxy。 PingAccess 會攔截直接要求，方法是中間人，或從 Web 應用程式伺服器上執行的代理程式重新導向。

使用 OIDC、OAuth2 或 SAML 設定 PingAccess，以向上游驗證提供者進行驗證。 您可以在 PingAccess 伺服器上為此目的設定上游 IdP。 請參閱下圖。

PingAccess 伺服器上的上游 IDP 圖表。

在公開 IdP 原則的一般 Azure AD B2C 部署中，有一項挑戰。 PingAccess 設定了一個上游 IdP。

PingFederate 同盟 Proxy

您可以將 PingFederate 設定為上游 IdP 的驗證提供者或 Proxy。 請參閱下圖。

PingFederate 已針對上游 IDP 設定驗證提供者或 Proxy 的圖表。

使用此函式，以內容方式、動態或以宣告方式將輸入要求切換至 Azure AD B2C 原則。 請參閱下列通訊協定順序流程圖表。

PingAccess、PingFederate、Azure AD B2C 和應用程式的通訊協定順序流程圖表。

必要條件

若要開始，您需要：

  • Azure 訂用帳戶
  • 連結至 Azure 訂用帳戶的 Azure AD B2C 租用戶
  • 在 Docker 容器或 Azure 虛擬機器上部署的 PingAccess 和 PingFederate (VM)

連線能力與通訊

確認下列連線和通訊。

  • PingAccess 伺服器 – 與 Azure AD B2C 服務和 PingFederate 伺服器所發佈的 PingFederate 伺服器、用戶端瀏覽器、OIDC、OAuth 已知和金鑰探索通訊
  • PingFederate 伺服器 – 與 Azure AD B2C 服務發佈的 PingAccess 伺服器、用戶端瀏覽器、OIDC、OAuth 已知和金鑰探索通訊
  • 舊版或標頭型 AuthN 應用程式 – 與 PingAccess 伺服器通訊
  • SAML 信賴憑證者應用程式 – 到達來自用戶端的瀏覽器流量。 存取 Azure AD B2C 服務所發佈的 SAML 同盟中繼資料。
  • 新式應用程式 – 到達來自用戶端的瀏覽器流量。 存取 Azure AD B2C 服務所發佈的 OIDC、OAuth 已知和金鑰探索。
  • REST API – 觸達來自原生或 Web 用戶端的流量。 存取 Azure AD B2C 服務所發佈的 OIDC、OAuth 已知和金鑰探索

設定 Azure AD B2C

您可以使用基本使用者流程或進階 Identity Enterprise Framework (IEF) 原則。 PingAccess 會使用 WebFinger 通訊協定進行探索慣例，根據簽發者值產生中繼資料端點。 若要遵循此慣例，請使用使用者流程原則屬性來更新 Azure AD B2C 簽發者。

[權杖相容性] 對話方塊上主體子宣告 URL 的螢幕擷取畫面。

在進階原則中，設定包含 JWT 權杖簽發者技術設定檔中 AuthorityWithTfp 值的 IssuanceClaimPattern 中繼資料元素。

設定 PingAccess 和 PingFederate

使用下列各節中的指示來設定 PingAccess 和 PingFederate。 請參閱整體整合使用者流程的下圖。

PingAccess 和 PingFederate 整合使用者流程的圖表

將 PingFederate 設為權杖提供者

若要將 PingFederate 設定為 PingAccess 的權杖提供者，請確定從 PingFederate 連線到 PingAccess。 確認從 PingAccess 連線到 PingFederate。

如需詳細資訊，請參閱 Ping 身分識別檔中的 將 PingFederate 設定為 PingAccess 的權杖提供者 。

設定 PingAccess 應用程式以進行標頭式驗證

使用下列指示為目標 Web 應用程式建立 PingAccess 應用程式，以進行標頭型驗證。

建立虛擬主機

重要

為每個應用程式建立虛擬主機。 For more information, see What can I configure with PingAccess? in the Ping Identity documentation.

若要建立虛擬主機：

  1. 移至 [設定>] [存取>虛擬主機]。
  2. 選取 [新增虛擬主機]。
  3. 針對 [主機]，輸入應用程式 URL 的 FQDN 部分。
  4. 針對 [埠]，輸入 443。
  5. 選取 [儲存]。

建立 Web 會話

若要建立 Web 會話：

  1. 流覽至 [設定>存取>Web 會話]。
  2. 選取 [新增 Web 會話]。
  3. 輸入 Web 會話的 [名稱 ]。
  4. 選取 Cookie 類型： 已簽署的 JWT 或 加密的 JWT。
  5. 輸入 物件的唯一值。
  6. 針對[用戶端識別碼]，輸入Microsoft Entra應用程式識別碼。
  7. 針對[用戶端密碼]，在 [Microsoft Entra識別碼] 中輸入您為應用程式產生的金鑰。
  8. (選擇性) 建立和使用自訂宣告與 Microsoft 圖形 API：選取 [進階]。 取消選取 要求設定檔 並 重新整理使用者屬性。 深入瞭解自訂宣告：具有Microsoft Entra應用程式 Proxy 的內部部署應用程式標頭型單一登入。
  9. 選取 [儲存]。

建立身分識別對應

注意

如果身分識別對應在標頭中預期相同資料，您可以使用多個應用程式。

若要建立身分識別對應：

  1. 移至[設定>] [存取>身分識別對應]。
  2. 選取 [新增識別對應]。
  3. 指定 *名稱。
  4. 選取標頭識別對應的識別對應 類型。
  5. 在 [屬性對應] 資料表中，指定所需的對應。 例如
屬性名稱 標頭名稱
'upn' x-userprincipalname
'email' x-email
'oid' x-oid
'scp' x-scope
'amr' x-amr
  1. 選取 [儲存]。

建立網站

注意

在某些設定中，月臺可以包含多個應用程式。 如有需要，您可以搭配多個應用程式使用網站。

若要建立網站：

  1. 移至主要>網站。
  2. 選取 [新增網站]。
  3. 輸入網站 名稱。
  4. 輸入網站 [目標]。 目標是裝載應用程式的伺服器主機名稱：連接埠配對。 請勿在此欄位中輸入應用程式路徑。 例如，的應用程式 https://mysite:9999/AppName 具有 mysite：9999 的目標值。
  5. 指出目標是否預期有安全連線。
  6. 如果目標需要安全連線，請將 [信任的憑證群組] 設定為 [信任任何]。
  7. 選取 [儲存]。

建立應用程式

若要針對您想要保護的 Azure 中每個應用程式，在 PingAccess 中建立應用程式。

  1. 移至 [主要]>[應用程式]

  2. 選取 [新增應用程式]

  3. 指定設備的 [名稱]

  4. 選擇性輸入應用程式的 [描述]

  5. 指定應用程式的 [內容根目錄]。 例如，應用程式 https://mysite:9999/AppName 的內容根目錄會是 /AppName。 內容根目錄的開頭必須是斜線 (/)、不能以斜線 (/) 結尾，並且層級深度可以是一個以上，例如 /Apps/MyApp。

  6. 選取您所建立的虛擬主機

    注意

    虛擬主機和內容根目錄的組合在 PingAccess 中必須是唯一組合。

  7. 選取您建立的 Web 工作階段

  8. 選取您建立的 [網站]，其中包含應用程式

  9. 選取您所建立的身分識別對應

  10. 選取 [已啟用] 以在儲存時啟用網站

  11. 選取 [儲存]。

設定 PingFederate 驗證原則

設定 PingFederate 驗證原則，以與 Azure AD B2C 租用戶所提供的多個 IdP 同盟

  1. 建立合約以橋接 IdP 與 SP 之間的屬性。 除非 SP 需要來自每個 IdP 的不同屬性集，否則您只需要一份合約。 如需詳細資訊，請參閱 Ping 身分識別檔中的 同盟中樞和驗證原則合約 。

  2. 針對每個 IdP，在 IdP 和 PingFederate 之間建立 IdP 連線，做為 SP 的同盟中樞。

  3. 在 [目標工作階段對應] 視窗中，將適用的驗證原則合約新增至 IdP 連線。

  4. 在 [選取器] 視窗中，設定驗證選取器。 例如，請參閱識別碼第一個配接器的實例，以將每個 IdP 對應至驗證原則中對應的 IdP 連線。

  5. 在 PingFederate、作為 IdP 的同盟中樞和 SP 之間建立 SP 連線。

  6. 將對應的驗證原則合約新增至 [驗證來源對應] 視窗上的 SP 連線。

  7. 使用每個 IdP 來連線到 PingFederate，做為 SP 的同盟中樞。

  8. 使用每個 SP 來連線到 PingFederate，做為 IdP 的同盟中樞。

後續步驟

如需其他資訊，請檢閱下列文章