這很重要
自 2025 年 5 月 1 日起,Azure AD B2C 將不再可供新客戶購買。 在我們的常見問題中深入瞭解。
在本教學課程中,瞭解如何使用 PingAccess 和 PingFederate 擴充 Azure Active Directory B2C (Azure AD B2C) 的功能。 PingAccess 提供應用程式和 API 的存取權,並通過原則引擎控制授權使用者的存取。 PingFederate 是用於使用者驗證和單一登錄的企業同盟伺服器,這是一個授權單位,可讓客戶、員工和合作夥伴從裝置存取應用程式。 將它們一起使用,以啟用安全的混合式存取(SHA)。
許多暴露於互聯網的電子商務網站和網頁應用程式都部署在代理伺服器後方或反向代理伺服器後方。 這些 Proxy 系統會預先驗證、強制執行原則,以及路由流量。 一般案例包括保護 Web 應用程式免於輸入 Web 流量,以及跨分散式伺服器部署提供統一的會話管理。
一般而言,組態包含驗證轉譯層,可將 Web 應用程式的驗證外部化。 反向代理會將已驗證的用戶上下文提供給 Web 應用程式,例如以明文或摘要形式的標頭值。 應用程式不會使用業界標準令牌,例如安全性聲明標記語言(SAML)、OAuth 或 OpenID Connect (OIDC)。 相反地,Proxy 會提供驗證內容,並維持與使用者代理程式 (例如瀏覽器或原生應用程式) 的工作階段。 作為以中間人身分執行的服務,Proxy 會提供重要的會話控制。 代理服務是高效且可擴展的,不會成為代理服務背後應用程式的瓶頸。 此圖表是反向 Proxy 實作和通訊流程。
現代化
如果您希望在這類配置中現代化身份平台,可能會引起客戶的關注:
- 將應用程式現代化與將身分識別平台現代化的努力分離
- 使用新式和舊版驗證的環境,會從現代化身分識別服務提供者取用
- 提升用戶體驗的一致性
- 跨應用程式提供單一登錄體驗
為了回答這些疑慮,本教學課程中的方法是 Azure AD B2C、 PingAccess 和 PingFederate 整合。
共用環境
技術上可行且符合成本效益的解決方案是將反向 Proxy 系統設定為使用現代化身分識別系統,並委派驗證。
Proxy 支援新式驗證通訊協定,並使用以重新導向為基礎的 (被動) 驗證,將用戶傳送至新的識別提供者 (IdP)。
Azure AD B2C 作為識別提供者
在 Azure AD B2C 中,您會定義原則來驅動用戶體驗和行為,也稱為使用者旅程圖。 這類原則會公開可執行驗證的通訊協定端點,如同 IdP。 在應用程式端,特定原則不需要特殊處理。 應用程式會對原則公開的通訊協定特定驗證端點提出標準驗證要求。
您可以設定 Azure AD B2C,使所有原則共用相同的簽發者,或為每個原則使用獨特的簽發者。 每個應用程式都可以透過發出通訊協定原生驗證要求來指向原則,以驅動用戶行為,例如登入、註冊和配置檔編輯。 此圖顯示 OIDC 和 SAML 應用程式工作流程。
在這種場景下,舊版應用程式可能很難將使用者正確重新導向。 應用程式的存取要求可能不會包含用戶體驗內容。 在大部分情況下,Proxy 層或 Web 應用程式上的整合式代理程式會攔截存取要求。
PingAccess 反向代理
您可以將 PingAccess 部署為反向 Proxy。 PingAccess 會攔截直接要求,方法是成為中間人,或是從 Web 應用程式伺服器上執行的代理程式重新導向。
使用 OIDC、OAuth2 或 SAML 設定 PingAccess,以向上游驗證提供者進行驗證。 您可以在 PingAccess 伺服器上為此目的設定上游 IdP。 請參閱下圖。
在具有會公開 IdP 原則的一般 Azure AD B2C 部署中,有一項挑戰。 PingAccess 已設定一個上游 IdP。
PingFederate 同盟代理
您可以將 PingFederate 設定為上游 IdP 的驗證提供者或 Proxy。 請參閱下圖。
使用此函式,以語境、動態或宣告方式將傳入請求切換至 Azure AD B2C 原則。 請參閱通訊協議順序流程的下圖。
先決條件
若要開始,您需要:
- Azure 訂用帳戶
- 如果您沒有帳戶,請取得 Azure 免費帳戶
- 連結至您 Azure 訂用帳戶的 Azure AD B2C 租戶
- 在 Docker 容器或 Azure 虛擬機上部署的 PingAccess 和 PingFederate
連接性與通訊
確認下列連線和通訊。
- PingAccess 伺服器:與 PingFederate 伺服器、用戶端瀏覽器、OIDC、常見 OAuth 以及 Azure AD B2C 服務和 PingFederate 伺服器所發佈的金鑰探索進行通訊
- PingFederate 伺服器:與 PingAccess 伺服器、用戶端瀏覽器、OIDC、常見 OAuth 以及 Azure AD B2C 服務所發佈的金鑰探索進行通訊
- 舊版或標頭式驗證應用程式:與 PingAccess 伺服器往返通訊
- SAML 信賴方應用程式 – 接收來自客戶端的瀏覽器流量。 存取 Azure AD B2C 服務所發佈的 SAML 同盟元數據。
- 新式應用程式 – 處理來自用戶端的瀏覽器流量。 存取 OIDC、常見 OAuth,以及 Azure AD B2C 服務所發佈的金鑰探索。
- REST API – 到達來自原生或 Web 用戶端的流量。 存取 OIDC、常見 OAuth,以及 Azure AD B2C 服務所發佈的金鑰探索
設定 Azure AD B2C
您可以使用基本使用者流程或進階 Identity Enterprise Framework (IEF) 原則。 PingAccess 會使用 WebFinger 通訊協定做為探索慣例,根據簽發者值產生中繼資料端點。 若要遵循此慣例,請使用使用者流程策略屬性來更新 Azure AD B2C 發行者。
在進階原則中,設定的 JWT 簽發者技術設定檔中包含 AuthorityWithTfp 值的 IssuanceClaimPattern 中繼資料元素。
設定 PingAccess 和 PingFederate
使用下列各節中的指示來設定 PingAccess 和 PingFederate。 請參閱整體整合使用者流程的下圖。
將 PingFederate 設定為令牌提供者
若要將 PingFederate 設定為 PingAccess 的令牌提供者,請確定從 PingFederate 連線到 PingAccess。 確認從 PingAccess 連線到 PingFederate。
設定 PingAccess 應用程式以進行標頭型驗證
使用下列指示建立目標 Web 應用程式的 PingAccess 應用程式,以進行標頭型驗證。
建立虛擬主機
這很重要
為每個應用程式建立虛擬主機。
若要建立虛擬主機:
- 移至 [ 設定>存取>虛擬主機]。
- 選取 [新增虛擬主機]。
- 針對 主機,輸入應用程式URL的 FQDN 部分。
- 針對 埠,輸入 443。
- 選取 [ 儲存]。
建立 Web 工作階段
若要建立 Web 工作階段:
- 瀏覽至 [設定]> [存取]> [Web 工作階段]。
- 選取 [新增 Web 會話]。
- 輸入網頁工作階段的 [名稱]。
- 選取 Cookie 類型: 已簽署的 JWT 或 加密 JWT。
- 輸入 受眾的唯一值。
- 針對 [用戶端識別符],輸入 Microsoft Entra 應用程式識別碼。
- 針對 [客戶端密碼],輸入您在 Microsoft Entra ID 中為應用程式產生的 金鑰 。
- (選擇性)使用 Microsoft Graph API 建立及使用自定義宣告:選取 [進階]。 取消選取 [要求設定檔] 並 [重新整理使用者屬性]。 深入了解自訂宣告:具有 Microsoft Entra 應用程式 Proxy 內部部署應用程式的標頭型單一登入 (SSO)。
- 選取 儲存
建立身分識別對應
備註
如果預期應用程式的標頭中會有相同資料,則可以對多個應用程式使用身分識別對應。
若要建立身分映射:
- 移至 [設定]> [存取]> [身分識別對應]。
- 選取 [新增身分識別對應]。
- 指定 *名稱。
- 選取識別對應 [標頭身分識別對應的類型]。
- 在 屬性對應 資料表中,指定必要的對應。 例如,
| 屬性名稱 | 標頭名稱 |
|---|---|
| 'upn' | x-userprincipalname |
| 電子郵件 | x-電子郵件 |
| 'oid' | x-oid |
| 'scp' | x-scope |
| 'amr' | x-amr |
- 選取 儲存
建立網站
備註
在某些配置中,網站包含多個應用程式。 如有需要,您可以搭配多個應用程式使用網站。
若要建立網站:
- 移至 主要>網站。
- 選取 [新增網站]。
- 輸入網站 名稱。
- 輸入網站 目標。 目標是裝載應用程式的伺服器主機名:埠組。 請勿在此欄位中輸入應用程式路徑。 例如,位於 https://mysite:9999/AppName 的應用程式具有 mysite:9999 的目標值。
- 指出目標是否預期有安全連線。
- 如果目標預期有安全的連線,請將 [信任的憑證群組] 設定為 [信任任何]。
- 選取 [ 儲存]。
建立應用程式
在 PingAccess 中針對您要在 Azure 中保護的每個應用程式建立應用程式。
移至 主要>應用程式
選取 [新增應用程式]
指定應用程式的名稱
選擇性地輸入應用程式的描述
指定應用程式的內容根。 例如,位於 https://mysite:9999/AppName 的應用程式會有 /AppName 的內容根目錄。 環境根目錄必須以斜線(/)開頭,不能以斜線結尾,而且可以包含多層結構,例如 /Apps/MyApp。
選取您建立的虛擬主機
備註
虛擬主機和內容根目錄的組合在 PingAccess 中必須是唯一的。
選取您建立的 Web 工作階段
選取 您建立 的網站,其中包含應用程式
選取您所建立的身分識別對應
選取 [已啟用 ] 以在您儲存時啟用網站
選取 儲存
設定 PingFederate 驗證原則
設定 PingFederate 驗證原則,以與 Azure AD B2C 租用戶所提供的多個 IdP 同盟
建立合約來橋接IdP與SP之間的屬性。 除非 SP 需要來自每個 IdP 的不同屬性集,否則您應該只需要一個合約。 如需詳細資訊,請參閱 Ping 身分識別檔中的 同盟中樞和驗證原則合約 。
針對每個 IdP,在 IdP 和 PingFederate 之間建立 IdP 連線,做為 SP 的同盟中樞。
在 [ 目標會話對應 ] 視窗中,將適用的驗證原則合約新增至IdP連線。
在 [ 選取器] 視窗中,設定驗證選取器。 例如,請參閱 標識碼第一配接器 的實例,以將每個 IdP 對應到驗證政策中的 IdP 連線。
在 PingFederate、作為 IdP 的同盟中樞和 SP 之間建立 SP 連線。
將對應的驗證原則合約新增至 [ 驗證來源對應 ] 視窗上的SP連線。
使用每個 IdP 來連線到 PingFederate,做為 SP 的同盟中樞。
使用每個 SP 來連線到 PingFederate,做為 IdP 的同盟中樞。
後續步驟
如需詳細資訊,請檢閱下列文章