チュートリアル: セキュリティで保護されたハイブリッド アクセスのために Azure Active Directory B2C を使用して Ping Identity を構成する

重要

2025 年 5 月 1 日より、Azure AD B2C は新規のお客様向けに購入できなくなります。 詳細については、FAQ を参照してください。

このチュートリアルでは、 PingAccess と PingFederate を使用して Azure Active Directory B2C (Azure AD B2C) の機能を拡張する方法について説明します。 PingAccess は、アプリケーションと API へのアクセス、および承認されたユーザー アクセスのポリシー エンジンを提供します。 PingFederate は、ユーザー認証とシングル サインオンのためのエンタープライズ フェデレーション サーバーであり、顧客、従業員、パートナーがデバイスからアプリケーションにアクセスすることを許可する機関です。 これらを一緒に使用して、セキュリティで保護されたハイブリッド アクセス (SHA) を有効にします。

インターネットに公開されている多くの電子商取引サイトやWebアプリケーションは、プロキシシステムまたはリバースプロキシシステムの背後にデプロイされています。 これらのプロキシ システムは、事前認証、ポリシーの適用、およびトラフィックのルーティングを行います。 一般的なシナリオには、受信 Web トラフィックから Web アプリケーションを保護することや、分散サーバー展開全体で統一されたセッション管理を提供することなどがあります。

一般に、構成には、Web アプリケーションから認証を外部化する認証変換レイヤーが含まれます。 リバースプロキシは、認証されたユーザーコンテキストをWebアプリケーションに提供します(クリア形式またはダイジェスト形式のヘッダー値など)。 アプリケーションは、Security Assertion Markup Language (SAML)、OAuth、OpenID Connect (OIDC) などの業界標準のトークンを使用していません。 代わりに、プロキシは認証コンテキストを提供し、ブラウザやネイティブアプリケーションなどのエンドユーザーエージェントとのセッションを維持します。 中間者として実行されるサービスとして、プロキシは重要なセッション制御を提供します。 プロキシ サービスは効率的でスケーラブルであり、プロキシ サービスの背後にあるアプリケーションのボトルネックになりません。 この図は、リバース プロキシの実装と通信フローを示しています。

近代化

このような構成で ID プラットフォームを最新化する場合、次のようなお客様の懸念事項が発生する可能性があります。

• アプリケーションをモダナイズする取り組みを ID プラットフォームのモダナイゼーションから切り離す
• 最新の認証とレガシー認証を使用する環境は、最新化されたIDサービスプロバイダーのサービスを利用している
  • エンドユーザーエクスペリエンスの一貫性を促進
  • アプリケーション間でシングル サインイン エクスペリエンスを提供する

これらの懸念事項に対する回答として、このチュートリアルのアプローチは、Azure AD B2C、 PingAccess、 PingFederate の統合です。

共有環境

技術的に実行可能で費用対効果の高いソリューションは、リバースプロキシシステムを最新のIDシステムを使用するように構成し、認証を委任することです。
プロキシは、最新の認証プロトコルをサポートし、ユーザーを新しい ID プロバイダー (IdP) に送信するリダイレクトベース (パッシブ) 認証を使用します。

ID プロバイダーとしての Azure AD B2C

Azure AD B2C では、ユーザー エクスペリエンスと行動 (ユーザー体験とも呼ばれます) を推進するポリシーを定義します。 このような各ポリシーは、IdP として認証を実行できるプロトコルエンドポイントを公開します。 アプリケーション側では、特定のポリシーに特別な処理は必要ありません。 アプリケーションは、ポリシーによって公開されるプロトコル固有の認証エンドポイントに対して標準認証要求を行います。
Azure AD B2C は、ポリシー間で同じ発行者を共有するか、ポリシーごとに一意の発行者を共有するように構成できます。 各アプリケーションは、プロトコルネイティブの認証リクエストを行うことでポリシーを参照でき、サインイン、サインアップ、プロファイルの編集などのユーザー行動を促進します。 この図は、OIDC と SAML アプリケーションのワークフローを示しています。

このシナリオは、レガシ アプリケーションにとって、ユーザーを正確にリダイレクトするのが難しい場合があります。 アプリケーションへのアクセス要求には、ユーザー エクスペリエンスのコンテキストが含まれていない可能性があります。 ほとんどの場合、プロキシレイヤー、またはWebアプリケーション上の統合エージェントがアクセスリクエストをインターセプトします。

PingAccess リバース プロキシ

PingAccess をリバース プロキシとしてデプロイできます。 PingAccessは、中間者になることで、またはWebアプリケーションサーバーで実行されているエージェントからのリダイレクトとして、直接の要求をインターセプトします。

アップストリーム認証プロバイダーでの認証のために、OIDC、OAuth2、または SAML を使用して PingAccess を構成します。 この目的のために、PingAccess サーバでアップストリーム IdP を設定できます。 次の図を参照してください。

一般的な Azure AD B2C 配備（IdP を利用するポリシーがある場合）では、課題があります。 PingAccess は、1 つのアップストリーム IdP で構成されます。

PingFederate フェデレーション プロキシ

PingFederate は、アップストリーム IdP の認証プロバイダーまたはプロキシとして構成できます。 次の図を参照してください。

この関数を使用して、コンテキスト、動的、または宣言的に受信要求を Azure AD B2C ポリシーに切り替えます。 プロトコル シーケンス フローの次の図は、次の図を参照してください。

[前提条件]

作業を開始するには、以下が必要です。

• Azure サブスクリプション
  • お持ちでない場合は、Azure 無料アカウントを取得してください。
• Azure サブスクリプションにリンクされた Azure AD B2C テナント
• Docker コンテナーまたは Azure 仮想マシン (VM) にデプロイされた PingAccess と PingFederate

コネクティビティと通信

以下の接続・通信を確認します。

• PingAccess サーバー – PingFederate サーバー、クライアント ブラウザー、OIDC、OAuth の well-known、および Azure AD B2C サービスと PingFederate サーバーによって公開されたキー検出と通信します
• PingFederate サーバー – PingAccess サーバー、クライアント ブラウザー、OIDC、OAuth の well-known、および Azure AD B2C サービスによって公開されたキー検出と通信します
• レガシーまたはヘッダーベースのAuthNアプリケーション – PingAccessサーバーとの間で通信します
• SAML 証明書利用者アプリケーション – クライアントからのブラウザ トラフィックに到達します。 Azure AD B2C サービスによって発行された SAML フェデレーション メタデータにアクセスします。
• 最新のアプリケーション – クライアントからのブラウザトラフィックに到達します。 OIDC、OAuth の well-known、および Azure AD B2C サービスによって公開されたキー検出にアクセスします。
• REST API – ネイティブクライアントまたは Web クライアントからのトラフィックに到達します。 OIDC、OAuth の well-known、および Azure AD B2C サービスによって公開されたキー検出にアクセスします

Azure AD B2C の構成

基本的なユーザー・フローまたは高度な Identity Enterprise Framework (IEF) ポリシーを使用できます。 PingAccess は、発行者の値に基づいて、検出規則の WebFinger プロトコルを使用してメタデータ エンドポイントを生成します。 この規則に従うには、ユーザー フロー ポリシー プロパティを使用して Azure AD B2C 発行者を更新します。

詳細ポリシーでは、設定により IssuanceClaimPattern メタデータ要素が AuthorityWithTfp 値として JWT 発行者技術プロファイル に含まれます。

PingAccess と PingFederate の構成

次のセクションの手順を使用して、PingAccess と PingFederate を構成します。 統合ユーザーフロー全体について、次の図を参照してください。

PingFederate をトークン プロバイダーとして構成する

PingFederate を PingAccess のトークン プロバイダーとして構成するには、PingFederate から PingAccess への接続を確認します。 PingAccess から PingFederate への接続を確認します。

ヘッダーベースの認証用に PingAccess アプリケーションを構成する

次の手順を使用して、ヘッダーベースの認証用のターゲット Web アプリケーション用の PingAccess アプリケーションを作成します。

仮想ホストの作成

重要

すべてのアプリケーションに対して仮想ホストを作成します。

仮想ホストを作成するには、次の手順を実行します。

1. [設定] >[アクセス] >[仮想ホスト] に移動します。
2. [仮想ホストの追加] を選択します。
3. [ホスト] に、アプリケーション URL の FQDN 部分を入力します。
4. [ポート] に、「443」と入力します
5. 保存 を選択します。

Web セッションの作成

Web セッションを作成するには:

1. [Settings] >[Access>Web Sessions] に移動します。
2. [ Web セッションの追加] を選択します。
3. Webセッションの名前を入力してください。
4. Cookie の種類 (署名付き JWT または暗号化 JWT) を選択します。
5. [オーディエンス] に一意の値を入力します。
6. [クライアント ID] に、Microsoft Entra アプリケーション ID を入力します。
7. Client Secret に、Microsoft Entra ID でアプリケーション用に生成した Key を入力します。
8. (オプション)Microsoft Graph API を使用してカスタム要求を作成して使用する: [詳細設定] を選択します。 「プロファイルをリクエスト」の選択を解除し、「ユーザー属性を更新」を選択します。 カスタム要求の詳細については、「 Microsoft Entra アプリケーション プロキシを使用したオンプレミス アプリのヘッダーベースのシングル サインオン」を参照してください。
9. [保存] を選びます。

ID マッピングの作成

注

ID マッピングは、ヘッダーに同じデータが含まれていると想定されている複数のアプリケーションで使用できます。

ID マッピングを作成するには:

1. 設定>アクセス>ID マッピングに移動します。
2. [ID マッピングの追加] を選択します。
3. *Name を指定します。
4. ID マッピングの種類として [ ヘッダー ID マッピング] を選択します。
5. [Attribute-Mapping] テーブルで、必要なマッピングを指定します。 たとえば、

属性名	ヘッダー名
「UPN」	X-ユーザープリンシパル名
'メール'	Xメール
'oid'	X-オイド
「SCP」	Xスコープ
「AMR」	X-AMRの

6. [保存] を選びます。

サイトを作成する

注

一部の構成では、サイトに複数のアプリケーションを含めることができます。 必要に応じて、1 つのサイトで複数のアプリケーションを使用できます。

サイトを作成する

1. Main>Sitesに移動します。
2. [サイトの追加] を選択します。
3. サイトの [名前] を入力します。
4. サイトの [ターゲット] を入力します。 ターゲットは、アプリケーションをホストしているサーバーのホスト名とポートのペアです。 このフィールドにはアプリケーションパスを入力しないでください。 たとえば、 https://mysite:9999/AppName のアプリケーションのターゲット値が mysite:9999 であるとします。
5. ターゲットがセキュア接続を期待しているかどうかを示します。
6. ターゲットがセキュアな接続を期待している場合は、「信頼できる証明書グループ」を「 任意のノードを信頼する」に設定します。
7. 保存 を選択します。

アプリケーションを作成する

保護する Azure のアプリケーションごとに PingAccess でアプリケーションを作成するには。

1. Main>Applicationsに移動

2. [ アプリケーションの追加] を選択する

3. アプリケーション の名前 を指定します

4. 必要に応じて、アプリケーションの 説明 を入力します

5. アプリケーションの コンテキストルート を指定します。 たとえば、 https://mysite:9999/AppName のアプリケーションのコンテキスト ルートは /AppName です。 コンテキスト ルートはスラッシュ (/) で始まる必要があり、スラッシュ (/) で終わることはできず、/Apps/MyApp のように複数のレイヤーの深さにすることができます。

6. 作成した 仮想ホスト を選択します

   注

   仮想ホストとコンテキスト ルートの組み合わせは、PingAccess で一意である必要があります。

7. 作成した Web セッション を選択します

8. アプリケーションを含む作成した サイト を選択します

9. 作成した ID マッピング を選択します

10. [有効] を選択して、保存時にサイトを有効にします

11. [保存] を選びます。

PingFederate 認証ポリシーを構成する

Azure AD B2C テナントによって提供される複数の IdP にフェデレーションするように PingFederate 認証ポリシーを構成します

1. IdP と SP 間の属性をブリッジするコントラクトを作成します。 SPが各IdPから異なる属性セットを必要としない限り、必要な契約は1つだけです。 詳細については、Ping Identity のドキュメントの「 フェデレーション ハブと認証ポリシー コントラクト 」を参照してください。

2. IdP ごとに、IdP と PingFederate(フェデレーションハブを SP として含む)との間に IdP 接続を作成します。

3. [ Target Session Mapping ] ウィンドウで、該当する認証ポリシーコントラクトを IdP 接続に追加します。

4. [ セレクタ] ウィンドウで、認証セレクタを設定します。 たとえば、 Identifier First Adapter のインスタンスを参照して、各 IdP を認証ポリシーの対応する IdP 接続にマップします。

5. IdP としてのフェデレーション ハブである PingFederate と SP の間に SP 接続を作成します。

6. 対応する認証ポリシー契約を [ Authentication Source Mapping ] ウィンドウで SP 接続に追加します。

7. 各 IdP と連携して、SP としてフェデレーション ハブである PingFederate に接続します。

8. SP と連携して、フェデレーション ハブである PingFederate に IdP として接続します。

次のステップ

詳細については、次の記事を参照してください

• Azure AD B2C のカスタム ポリシー

• Azure AD B2C でカスタム ポリシーを始める