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

  • [アーティクル]

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

インターネットに公開されている多くの e コマース サイトと 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 アプリケーションのワークフローを示しています。

OIDC および SAML アプリケーションのワークフローの図。

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

PingAccess リバース プロキシ

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

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

PingAccess サーバー上のアップストリーム IDP の図。

IdP を公開するポリシーを持つ一般的な Azure AD B2C デプロイでは、課題があります。 PingAccess は、1 つのアップストリーム IdP で構成されます。

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

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

認証プロバイダーまたはアップストリーム IDP 用のプロキシとして構成される PingFederate の図。

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

PingAccess、PingFederate、Azure AD B2C、およびアプリケーションのプロトコル シーケンス フローの図。

前提条件

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

  • 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 Experience Framework (IEF) ポリシーを使用できます。 PingAccess では、検出規則のための WebFinger プロトコルを使用して、発行者の値に基づいてメタデータ エンドポイントが生成されます。 この規則に従うには、ユーザー フローのポリシー プロパティを使用して Azure AD B2C の発行者を更新します。

トークンの互換性ダイアログのサブジェクト (sub) 要求 URL のスクリーンショット。

高度なポリシーでは、構成には JWT トークン発行者の技術プロファイルで IssuanceClaimPattern メタデータ要素を AuthorityWithTfp 値に設定することが含まれます。

PingAccess と PingFederate を構成する

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

PingAccess と PingFederate の統合ユーザー フローの図

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

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

詳細については、Ping ID ドキュメントの「PingAccess のトークン プロバイダーとして PingFederate を構成する」を参照してください。

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

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

仮想ホストを作成する

重要

すべてのアプリケーション用の仮想ホストを作成します。 詳細については、Ping ID ドキュメントの「PingAccess で構成できる内容」を参照してください。

仮想ホストを作成するには、次の手順に従います。

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

Web セッションを作成する

Web セッションを作成するには、次の手順に従います。

  1. [設定]>[アクセス]>[Web セッション] に移動します。
  2. [Add Web Session] (Web セッションの追加) を選択します。
  3. Web セッションの名前を入力します。
  4. [Cookie Type] (Cookie の種類) として [Signed JWT] (署名付き JWT) または [Encrypted JWT] (暗号化された JWT) を選択します。
  5. [対象ユーザー] に対して一意の値を入力します。
  6. [クライアント ID] に、Microsoft Entra アプリケーション ID を入力します。
  7. [クライアント シークレット] に、Microsoft Entra ID でアプリケーション用に生成したキーを入力します。
  8. (省略可能) Microsoft Graph API を使用してカスタム要求を作成して使用します。[Advanced] (詳細設定) を選択します。 [Request Profile] (プロファイルの要求) と [Refresh User Attributes] (ユーザー属性の更新) の選択を解除します。 カスタム要求の詳細については、「Microsoft Entra アプリケーション プロキシを使ったオンプレミス アプリのヘッダーベース シングル サインオン」を参照してください。
  9. [保存] を選択する

ID マッピングを作成する

Note

ヘッダーに同じデータが予期される場合は、複数のアプリケーションで ID マッピングを使用できます。

ID マッピングを作成するには、次の手順に従います。

  1. [設定]>[アクセス]>[ID マッピング] にアクセスします。
  2. [Add Identity Mapping] (ID マッピングの追加) を選択します。
  3. *"名前" を指定します。
  4. ID マッピングでのヘッダー ID マッピングの種類を選択します。
  5. 属性マッピングのテーブルで、必要なマッピングを指定します。 たとえば、次のように入力します。
属性名 ヘッダー名
'upn' x-userprincipalname
'email' x-email
'oid' x-oid
'scp' x-scope
'amr' x-amr
  1. [保存] を選びます。

サイトを作成する

Note

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

サイトを作成するには、次の手順に従います。

  1. [メイン]>[サイト] にアクセスします。
  2. [サイトの追加] を選択します。
  3. サイトの名前を入力します
  4. サイトのターゲットを入力します。 ターゲットは、アプリケーションがホストされているサーバーのホスト名とポートのペアです。 このフィールドには、アプリケーションのパスを入力しないでください。 たとえば、https://mysite:9999/AppName にあるアプリケーションのターゲット値は mysite:9999 になります。
  5. ターゲットがセキュリティで保護された接続を想定しているかどうかを指定します。
  6. セキュリティで保護された接続がターゲットで想定されている場合は、[Trusted Certificate Group] (信頼できる証明書グループ) を [Trust Any] (すべて信頼する) に設定します。
  7. [保存] を選択します。

アプリケーションの作成

保護する必要がある Azure 内の各アプリケーションに対して PingAccess でアプリケーションを作成するには、次の手順に従います。

  1. [メイン]>[アプリケーション] にアクセスします。

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

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

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

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

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

    注意

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

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

  8. アプリケーションが含まれている、作成したサイトを選択します

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

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

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

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

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

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

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

  3. [Target Session Mapping](ターゲット セッション マッピング) ウィンドウで、該当する認証ポリシーのコントラクトを IdP 接続に追加します。

  4. [Selectors](セレクター) ウィンドウで、認証セレクターを構成します。 たとえば、各 IdP を認証ポリシー内の対応する IdP 接続にマップするには、 [Identifier First Adapter](ID の最初のアダプター) のインスタンスを参照します。

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

  6. [Authentication Source Mapping](認証ソース マッピング) ウィンドウで、対応する認証ポリシーのコントラクトを SP 接続に追加します。

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

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

次のステップ

追加情報については、次の記事を参照してください。