チュートリアル: Microsoft Entra ID と F5 のヘッダーベース SSO 用 BIG-IP Easy Button の間で SSO を構成する
このチュートリアルでは、F5 を Microsoft Entra ID と統合する方法について学習します。 F5 を Microsoft Entra ID と統合すると、次のことができます:
- F5 にアクセスできるユーザーを Microsoft Entra ID で制御する。
- ユーザーが自分の Microsoft Entra アカウントを使って F5 に自動的にサインインできるようにする。
- 1 つの場所でアカウントを管理します。
Note
F5 BIG-IP APM を今すぐ購入できます。
シナリオの説明
このシナリオでは、HTTP 承認ヘッダーを使用して、保護されたコンテンツへのアクセスを管理するクラシック レガシ アプリケーションについて説明します。
従来のアプリケーションには、Azure AD との直接的な統合をサポートする最新のプロトコルがありません。 アプリケーションを最新化することは可能ですが、コストがかかりすぎ、慎重な計画が必要であり、潜在的なダウンタイムのリスクが生じます。 代わりに、プロトコル遷移によって従来のアプリケーションと最新の ID コントロール プレーンとの間のギャップを橋渡しするために、F5 BIG IP Application Delivery Controller (ADC) を使用します。
アプリケーションの前に BIG-IP があると、Microsoft Entra の事前認証とヘッダーベースの SSO でサービスをオーバーレイできるため、アプリケーションの全体的なセキュリティ態勢が大幅に向上します。
Note
組織では、この種類のアプリケーションに対して Microsoft Entra アプリケーション プロキシを使用してリモート アクセスを取得することもできます。
シナリオのアーキテクチャ
このシナリオの SHA ソリューションは次のもので構成されています。
アプリケーション: Microsoft Entra SHA によって保護される BIG-IP 公開サービス。
Microsoft Entra ID: Security Assertion Markup Language (SAML) ID プロバイダー (IdP)。ユーザーの資格情報の検証、条件付きアクセス、および BIG-IP に対する SAML ベースの SSO の責任を負います。 SSO を介して、Microsoft Entra ID により、必要なセッション属性が BIG-IP に提供されます。
BIG-IP: アプリケーションに対するリバース プロキシおよび SAML サービス プロバイダー (SP)。バックエンド アプリケーションへのヘッダーベースの SSO を実行する前に認証を SAML IdP に委任します。
このシナリオの SHA では、SP と IdP によって開始されたフローの両方がサポートされます。 次の図は、SP Initiated フローを示しています。
| 手順 | 説明 |
|---|---|
| 1 | ユーザーがアプリケーション エンドポイント (BIG-IP) に接続する |
| 2 | BIG-IP APM アクセス ポリシーは、ユーザーを Microsoft Entra ID (SAML IdP) にリダイレクトします |
| 3 | Microsoft Entra ID によって、ユーザーの事前認証と、条件付きアクセス ポリシーの適用が行われます |
| 4 | ユーザーが BIG-IP (SAML SP) にリダイレクトされ、発行された SAML トークンを使用して SSO が実行される |
| 5 | BIG-IP によって、Microsoft Entra 属性がアプリケーションへの要求のヘッダーとして挿入される |
| 6 | アプリケーションが要求を承認し、ペイロードを返す |
前提条件
以前の BIG-IP エクスペリエンスは必要ありませんが、次のものが必要です。
Microsoft Entra ID 無料サブスクリプション (またはそれ以上)。
既存の BIG-IP。または、Azure に BIG-IP Virtual Edition (VE) をデプロイします。
次のいずれかの F5 BIG-IP ライセンス SKU。
F5 BIG-IP® Best バンドル。
F5 BIG-IP Access Policy Manager™ (APM) スタンドアロン ライセンス。
既存の BIG-IP F5 BIG-IP® Local Traffic Manager™ (LTM) に対する F5 BIG-IP Access Policy Manager™ (APM) アドオン ライセンス
90 日間の BIG-IP 全機能試用版ライセンス。
オンプレミスのディレクトリから Microsoft Entra ID に同期されたユーザー ID。
Microsoft Entra アプリケーション管理者のアクセス許可を持つアカウント。
HTTPS でサービスを公開するための SSL Web 証明書。または、テストの間は既定の BIG-IP 証明書を使います。
ヘッダーベースの既存のアプリケーション。または、テスト用に簡単な IIS ヘッダー アプリをセットアップします。
BIG-IP の構成方法
このシナリオで使用する BIG-IP は、テンプレートを使用した 2 つの方法や高度な構成を含め、さまざまな方法で構成できます。 このチュートリアルでは、Easy Button テンプレートを提供する最新の Guided Configuration 16.1 について説明します。 Easy Button を使用すると、管理者は Azure AD と BIG-IP の間を行き来して SHA のためにサービスを有効にする必要がなくなります。 デプロイとポリシー管理は、APM のガイド付き構成ウィザードと Microsoft Graph との間で直接処理されます。 この充実した BIG-IP APM と Microsoft Entra ID の統合により、アプリケーションでは確実に ID フェデレーション、SSO、Microsoft Entra 条件付きアクセスを迅速かつ容易にサポートできるため、管理オーバーヘッドが軽減されます。
Note
このガイド全体で参照されている文字列または値の例はすべて、実際の環境に合わせて置き換える必要があります。
Easy Button を登録する
クライアントまたはサービスから Microsoft Graph へのアクセスには、Microsoft ID プラットフォームによって信頼されている必要があります。
この最初の手順では、Graph への Easy Button アクセスを承認するために使用されるテナント アプリの登録を作成します。 これらのアクセス許可により、BIG-IP では、公開済みアプリケーションの SAML SP インスタンスと、SAML IdP となる Microsoft Entra ID の間に信頼を確立するために必要な構成をプッシュできるようになります。
アプリケーションの管理者権限を持つアカウントを使用して、Azure portal にサインインします。
左のナビゲーション ペインで、[Microsoft Entra ID] サービスを選択します。
[管理] で [アプリの登録]>[新規登録] を選びます。
アプリケーションの表示名を入力します (
F5 BIG-IP Easy Buttonなど)。アプリケーションを使用できるユーザー >[Accounts in this organizational directory only] (この組織ディレクトリのアカウントのみ) を指定します。
[登録] を選択して、初期のアプリ登録を完了します。
[API* のアクセス許可*] に移動し、次の Microsoft Graph* のアプリケーション*のアクセス許可*を承認します：
- Application.Read.All
- Application.ReadWrite.All
- Application.ReadWrite.OwnedBy
- Directory.Read.All
- Group.Read.All
- IdentityRiskyUser.Read.All
- Policy.Read.All
- Policy.ReadWrite.ApplicationConfiguration
- Policy.ReadWrite.ConditionalAccess
- User.Read.All
組織に管理者の同意を付与します。
[証明書とシークレット] ブレードで、新しいクライアント シークレットを生成し、記録しておきます。
[概要] ブレードで、[クライアント ID] と [テナント ID] を記録しておきます。
Easy Button を構成する
APM* の [ガイド*付き構成*] を開始して、Easy Button テンプレート*を起動します。
[アクセス] > [ガイド付き構成] > [Microsoft 統合] と移動して、[Microsoft Entra アプリケーション] を選択します。
構成手順の一覧を確認し、[次へ] を選択します。
アプリケーションを発行するために必要な一連の手順に従います。
Configuration Properties
[構成のプロパティ] タブでは、BIG-IP アプリケーション構成と SSO オブジェクトが作成されます。 [Azure サービス アカウントの詳細] セクションは、アプリケーションとして、以前に Microsoft Entra テナントに登録したクライアントを表すものとします。 これらの設定*により、BIG-IP* の OAuth クライアント*では、通常は手動で構成する* SSO* プロパティと共に、SAML SP をテナント*に直接個別に登録できるようになります。 Easy Button により、公開*されて SHA が有効になっているすべての BIG-IP* サービス*に対してこの操作が行われます。
これらの一部はグローバル設定であるため、より多くのアプリケーションを公開するために再利用でき、デプロイの時間と労力をさらに削減するのに役立ちます。
一意の構成名を入力して、管理者が各 Easy Button 構成を容易に区別できるようにします。
[Single Sign-On (SSO) & HTTP Headers](シングル サインオン (SSO) と HTTP ヘッダー) を有効にします
テナントに Easy Button クライアントを登録するときに記録したテナント ID、クライアント ID、およびクライアント シークレットを入力します。
BIG-IP がテナントに正常に接続されたことを確認してから、[次へ] を選択します。
サービス プロバイダー
サービス* プロバイダー*設定*では、SHA によって保護されるアプリケーション*の SAML SP インスタンス*のプロパティを定義します。
ホストを入力します。 これは、セキュア アプリケーションのパブリック FQDN です。
エンティティ ID を入力します。 これは、トークンを要求する SAML SP を識別するために Microsoft Entra ID によって使用される識別子です。
オプションの [セキュリティ設定] で、発行された SAML アサーションを Microsoft Entra ID で暗号化する必要があるかどうかを指定します。 Microsoft Entra ID と BIG-IP APM の間でアサーションを暗号化すると、コンテンツ トークンが傍受されないこと、および個人や会社のデータが侵害されないことの追加保証が提供されます。
[Assertion Decryption Private Key] (アサーション解読秘密キー) の一覧から、[新規作成] を選択します。
[OK] を選択します。 新しいタブで [SSL 証明書とキーのインポート] ダイアログが開きます。
PKCS 12 (IIS) を選択して、証明書と秘密キーをインポートします。 プロビジョニングが完了したら、ブラウザー タブを閉じて、メイン タブに戻ります。
[Enable Encrypted Assertion](暗号化アサーションを有効にする) をオンにします。
暗号化を有効にした場合は、[Assertion Decryption Private Key](アサーション解読秘密キー) の一覧から証明書を選択します。 これは、Microsoft Entra アサーションを解読するために BIG-IP APM で使用される証明書の秘密キーです。
暗号化を有効にした場合は、[Assertion Decryption Certificate](アサーション解読証明書) の一覧から証明書を選択します。 これは、発行された SAML アサーションを暗号化するために BIG IP から Microsoft Entra ID にアップロードされる証明書です。
Microsoft Entra ID
このセクションでは、Microsoft Entra テナント内で新しい BIG-IP SAML アプリケーションを手動で構成するために通常使用するすべてのプロパティを定義します。 Easy Button には、Oracle PeopleSoft、Oracle E-business Suite、Oracle JD Edwards、SAP ERP* 用の一連の定義済みアプリケーション* テンプレート*のほか、その他すべてのアプリ*用の汎用 SHA テンプレート*が用意されています。 このシナリオでは、[F5 BIG-IP APM Azure AD 統合] > [追加] を選択します。
Azure 構成
BIG-IP によって Microsoft Entra テナント内に作成されるアプリと、MyApps ポータルでユーザーに表示されるアイコンの表示名を入力します。
IdP Initiated サインオンを有効にするには、[サインオン URL (省略可能)] に何も入力しないでください。
[署名キー] と [署名証明書] の横にある更新アイコンを選択して、先ほどインポートした証明書を見つけます。
[Signing Key Passphrase] (署名キーのパスフレーズ) に証明書のパスワードを入力します。
[署名オプション] (省略可能) を有効にします。 これにより、BIG-IP は、Microsoft Entra ID によって署名されたトークンと要求のみを受け入れるようになります。
ユーザーとユーザー グループは、Microsoft Entra テナントから動的に照会され、アプリケーションへのアクセスを承認するために使用されます。 後でテストに使用できるユーザーまたはグループを追加します。そうしないと、すべてのアクセスが拒否されます。
ユーザー属性とクレーム
ユーザーが正常に認証されると、Microsoft Entra ID は、ユーザーを一意に識別する要求と属性の既定のセットを使用して SAML トークンを発行します。 [ユーザー属性と要求] タブには、新しいアプリケーションのために発行する既定の要求が表示されます。 また、さらに多くの要求を構成することもできます。
この例では、属性をもう 1 つ含めることができます。
[ヘッダー名] に「employeeid」と入力します。
[基になる属性] に「user.employeeid」と入力します。
追加のユーザー属性
[Additional User Attributes](追加のユーザー属性) タブでは、Oracle、SAP、および他のディレクトリに格納された属性を必要とするその他の JAVA ベースの実装など、さまざまな分散システムに必要なセッション拡張を有効にすることができます。 次に、LDAP ソースからフェッチされた属性を追加の SSO ヘッダーとして挿入して、ロール、パートナー ID などに基づいてアクセスをさらに制御できます。
Note
この機能は Microsoft Entra ID と相関関係はありませんが、属性のもう 1 つのソースです。
条件付きアクセス ポリシー
条件付きアクセス ポリシーは、デバイス、アプリケーション、場所、リスクの兆候に基づいてアクセスを制御するために、Microsoft Entra の事前認証後に適用されます。
[使用可能なポリシー] ビューには、既定で、ユーザー ベースのアクションを含まないすべての条件付きアクセス ポリシーが一覧表示されます。
[Selected Policies](選択されたポリシー) ビューには、既定で、すべてのクラウド アプリをターゲットとするすべてのポリシーが表示されます。 これらのポリシーは、テナント レベルで適用されるため、選択解除することも、[Available Policies](使用可能なポリシー) リストに移動することもできません。
公開されているアプリケーションに適用するポリシーを選択するには:
- [Available Policies](使用可能なポリシー) リストで目的のポリシーを選択します。
- 右矢印を選択して、これを [Selected Policies](選択されたポリシー) リストに移動します。
選択したポリシーでは、[Include](含める) または [Exclude](除外する) オプションをオンにする必要があります。 両方のオプションをオンにした場合、選択したポリシーは適用されません。
Note
ポリシーの一覧は、最初にこのタブに切り替えたときに 1 回だけ列挙されます。ウィザードから手動でテナントにクエリを実行するための更新ボタンが用意されていますが、このボタンはアプリケーションがデプロイされている場合にのみ表示されます。
仮想サーバーのプロパティ
仮想サーバーは、アプリケーションに対するクライアント要求をリッスンする仮想 IP アドレスで表される BIG-IP データ プレーン オブジェクトです。 受信したトラフィックは、ポリシーの結果と設定に従って送信される前に、仮想サーバーに関連付けられている APM プロファイルに対して処理および評価されます。
宛先アドレスを入力します。 これは、BIG-IP がクライアント トラフィックを受信するために使用できる任意の IPv4 または IPv6 アドレスです。 対応するレコードが DNS にも存在する必要があり、それによってクライアントでは、BIG-IP の公開済みアプリケーションの外部 URL を、アプリケーション自体ではなく、この IP に解決できるようになります。 テストでは、テスト PC の localhost DNS を使用しても問題ありません。
[サービス ポート] に、HTTPS 用の「443」を入力します。
[Enable Redirect Port](リダイレクト ポートを有効にする) をオンにし、リダイレクト ポートを入力します。 これにより、受信 HTTP クライアント トラフィックが HTTPS にリダイレクトされます。
クライアント* SSL* プロファイル*を使用すると、HTTPS* 用の仮想サーバー*が有効になり、クライアント*接続が TLS* で暗号化されるようになります。 前提条件の一部として作成したクライアント SSL プロファイルを選択するか、テストする場合は既定値のままにします。
プールのプロパティ
[Application Pool](アプリケーション プール) タブには、1 つまたは複数のアプリケーション サーバーを含むプールとして表される、BIG-IP の背後にあるサービスの詳細が表示されます。
[Select a Pool](プールの選択) から選択します。 新しいプールを作成するか、既存のプールを選択します。
[負荷分散方法] で、[
Round Robin] を選択します。[プール サーバー] では、既存のノードを選択するか、ヘッダーベースのアプリケーションをホストするサーバーの IP とポートを指定します。
バックエンド アプリケーションでは HTTP ポート 80 を使用しますが、HTTPS の場合は当然のことながら 443 に切り替えます。
シングル サインオンと HTTP ヘッダー
SSO を有効にすると、ユーザーは資格情報を入力しなくても、BIG-IP で公開されているサービスにアクセスできるようになります。 Easy Button ウィザードでは、SSO 用に Kerberos、OAuth Bearer、および HTTP 承認ヘッダーがサポートされています。ここでは後者を有効にして、以下を構成します。
ヘッダー操作:
Insertヘッダー名:
upnヘッダー値:
%{session.saml.last.identity}ヘッダー操作:
Insertヘッダー名:
employeeidヘッダー値:
%{session.saml.last.attr.name.employeeid}
Note
中かっこ内で定義されている APM セッション変数は、大文字と小文字が区別されます。 たとえば、Microsoft Entra の属性名が orclguid として定義されている場合に「OrclGUID」と入力すると、属性マッピング エラーが発生します。
セッションの管理
BIG-IP のセッション管理の設定は、ユーザー セッションが終了されるか続行が許可される条件、ユーザーと IP アドレスの制限、および対応するユーザー情報を定義するために使用されます。 これらの設定の詳細については、F5 のドキュメントを参照してください。
しかし、ユーザーがサインオフするときに IdP、BIG-IP、およびユーザー エージェント間のすべてのセッションが確実に終了されるようにする、シングル ログアウト (SLO) 機能についての説明はここにはありません。 Easy Button によって SAML アプリケーションが Microsoft Entra テナントでインスタンス化されると、ログアウト URL にも、APM の SLO エンドポイントが設定されます。 このようにして、Microsoft Entra MyApps ポータルからの IdP Initiated サインアウトでも、BIG-IP とクライアント間のセッションが終了します。
これに加え、テナントから公開済みアプリケーションの SAML フェデレーション メタデータもインポートされて、APM に Microsoft Entra ID の SAML ログアウト エンドポイントが提供されます。 これにより、SP Initiated サインアウトでクライアントと Microsoft Entra ID との間のセッションが確実に終了するようになります。 しかし、これを真に効果的に行うには、APM で、ユーザーがいつアプリケーションからサインアウトしたのかを正確に知る必要があります。
BIG-IP Web トップ ポータルを使用して公開済みアプリケーションにアクセスする場合は、そこからのサインアウトが APM によって処理され、Microsoft Entra サインアウト エンドポイントも呼び出されます。 しかし、BIG-IP Web トップ ポータルが使用されていないために、サインアウトするようにユーザーが APM に指示する方法がないシナリオについて考えてみます。ユーザーがアプリケーション自体からサインアウトした場合でも、BIG-IP では技術的にはこれが認識されません。 このため、SP によって開始されるサインアウトでは、セッションが不要になったときに確実に安全に終了されるように、慎重に検討する必要があります。 これを実現する 1 つの方法は、SLO 関数をアプリケーションのサインアウト ボタンに追加して、クライアントを Microsoft Entra SAML または BIG-IP サインアウト エンドポイントにリダイレクトできるようにすることです。 テナントの SAML サインアウト エンドポイントの URL については、[アプリの登録] > [エンドポイント] で確認できます。
アプリに変更を加えることができない場合は、BIG-IP でアプリケーションのサインアウト呼び出しをリッスンし、要求を検出したら SLO をトリガーすることを検討してください。 これを実現するための BIG-IP iRules の使用については、Oracle PeopleSoft SLO ガイダンスを参照してください。 これを実現するための BIG-IP iRules の使用の詳細については、F5 のナレッジ記事「URI 参照ファイル名に基づく自動セッション終了 (ログアウト) の構成」および「ログアウト URI インクルード オプションの概要」を参照してください。
まとめ
この最後の手順では、構成の概要を示します。 [Deploy](デプロイ) を選択してすべての設定をコミットし、エンタープライズ アプリケーションのテナント リストにアプリケーションが存在することを確認します。
これで、アプリケーションが公開され、その URL を介して直接または Microsoft のアプリケーション ポータルを介して、SHA によりアクセスできるようになります。
次のステップ
ブラウザーから、アプリケーションの外部 URL に接続するか、Microsoft MyApps ポータルでアプリケーションのアイコンを選択します。 Microsoft Entra ID への認証後、アプリケーションの BIG-IP の仮想サーバーにリダイレクトされ、SSO を通じて自動的にサインイン処理が行われます。
これは、ヘッダーベースのアプリケーションによって表示された、挿入されたヘッダーの出力を示しています。
このパターンを使用する組織では、セキュリティを強化するため、アプリケーションへのすべての直接アクセスをブロックすることで、BIG-IP 経由の厳密なパスを強制することもできます。
詳細なデプロイ
ガイド付き構成テンプレートには、より具体的な要件を実現するための柔軟性が足りない場合があります。 そうしたシナリオの場合は、ヘッダーベースの SSO の詳細構成に関するページを参照してください。
また、BIG-IP には、Guided Configuration の厳格な管理モードを無効にするオプションが用意されています。 これにより、ウィザード ベースのテンプレートを使用して構成の大部分を自動化する場合でも、構成を手動で調整できるようになります。
[Access](アクセス) > [Guided Configuration] の順に移動して、アプリケーションの構成の行の右端にある小さな南京錠アイコンを選択します。
その時点で、ウィザード UI を介した変更を行うことができなくなります。ただし、アプリケーションの公開されたインスタンスに関連付けられているすべての BIG-IP オブジェクトのロックが解除され、直接管理できるようになります。
Note
厳格なモードを再度有効にして構成をデプロイすると、ガイド付き構成の UI 外部で実行した設定はすべて上書きされるため、運用サービスに対しては、詳細構成の方式をお勧めします。
トラブルシューティング
さまざまな要因により、SHA によって保護されたアプリケーションにアクセスできない場合があります。 BIG-IP のログは、接続、SSO、ポリシー違反、正しく構成されていない変数マッピングなど、あらゆる種類の問題をすばやく区別するのに役立つ可能性があります。 ログの詳細レベルを上げることでトラブルシューティングを開始します。
[Access Policy] (アクセス ポリシー) > [Overview] (概要) > [Event Logs] (イベント ログ) > [Settings] (設定) に移動します。
公開されたアプリケーションの行を選択し、[Edit] (編集) > [Access System Logs] (システム ログへのアクセス) を選択します。
SSO の一覧から [デバッグ] を選択して、 [OK] を選択します。
問題を再現してからログを検査しますが、詳細モードでは大量のデータが生成されるため、終了したら忘れずに、これを元に戻してください。
Microsoft Entra 事前認証が成功した直後に、BIG-IP ブランドのエラーが表示される場合は、Microsoft Entra ID から BIG-IP への SSO に関連する問題が発生している可能性があります。
[Access] (アクセス) > [Overview] (概要) > [Access reports] (レポートへのアクセス) に移動します。
過去 1 時間のレポートを実行して、ログに手がかりがないかどうかを確認します。 セッションに対する [View session](セッションの表示) 変数リンクも、APM が Microsoft Entra ID から予想される要求を受信しているかどうかを把握するのに役立ちます。
BIG-IP のエラー ページが表示されない場合は、問題は、バックエンド要求や、BIG-IP からアプリケーションへの SSO に関係している可能性が高くなります。
その場合は、[Access Policy] (アクセス ポリシー) > [Overview] (概要) > [Active Sessions] (アクティブ セッション) に移動し、アクティブ セッションのリンクを選択します。
この場所にある [変数の表示] リンクも、SSO の問題、特に BIG-IP APM で Microsoft Entra ID または別のソースから適切な属性を取得できない場合に、根本的な原因を特定するのに役立つことがあります。
詳細については、F5 のナレッジ記事「Active Directory の LDAP リモート認証の構成」を参照してください。 また、この LDAP クエリに関する F5 のナレッジ記事には、LDAP 関連の問題の診断に役立つ優れた BIG-IP 参照テーブルもあります。