シングルサインオンのサポート

最終公開日 : Nov 13, 2026
Related information
ブラウザコンテンツリダイレクト

はじめに

ブラウザコンテンツリダイレクトは、シングルサインオンのサポートにより合理化されたユーザーエクスペリエンスを提供するようになり、VDA側での認証とCookie共有を可能にします。
この機能強化により、重複するログインが不要になり、BCRウィンドウが閉じられた後でもBCRセッション全体で認証とCookieの永続性を維持することで、生産性が向上します。
このシームレスなエクスペリエンスは、認証がクライアントではなくVDAから行われるようにすることで、セキュリティをさらに強化します。

シングルサインオンなしの場合

  • BCR内で認証されたページを開くには、ユーザーは毎回資格情報を再入力する必要があり、SSOの永続性が失われました。
  • SSOはBCRウィンドウが開いている間のみ維持されました。ウィンドウを閉じて再度開くと、ユーザーはログインプロセスを繰り返す必要がありました。
  • 認証フローはクライアントから行われ、管理者はクライアントデバイスからセキュアな認証サイトへのネットワークアクセスを提供する必要がありました。

シングルサインオンありの場合

  • (VDAで既に認証されている場合) SSOがVDAブラウザからシームレスに保持されるため、ユーザーは資格情報の入力を求められなくなります。
  • 認証はVDAから行われるため、クライアント側のネットワーク要件と露出を制限することでセキュリティ体制が向上し、大幅に改善された中断のないエクスペリエンスを提供します。

最小要件

  • シトリックス バーチャルアプリおよびデスクトップ 2507
  • シトリックス ワークスペースアプリ for Windows 2511
  • シトリックス ワークスペースアプリ for Linux 2601
  • ブラウザリダイレクト拡張機能 (Chrome または Edge) 25.11 以降

サポートされている認証シーケンス

現在、BCRシングルサインオンでサポートされている認証シーケンスは2種類あります。

リダイレクトベースの認証

この標準的な方法では、アプリケーションはHTTPリダイレクトを使用して、ユーザーを認証専用ページに強制的に移動させます。
例えば、ユーザーが必要なセッションCookieなしで <https://my.intranet.app> にアクセスしようとすると、Webアプリケーションは、<https://my.intranet.app/auth> のような認証エンドポイントへのHTTP 302リダイレクトで応答します。
ユーザーがそのページで認証に成功すると、ブラウザは元のアプリケーションURLにリダイレクトされ、必要な認証Cookieが含まれるようになります。

ページ内フォームベース認証

この方法では、ユーザーを目的のアプリケーションURLに留まらせたまま、ログインインターフェイスを動的に表示します。
例えば、ユーザーが <https://my.intranet.app> のような保護されたページに移動すると、必要なCookieがないため、ページはリダイレクトをトリガーせずに認証フォームを直接読み込みます。このプロセスには、ページインターフェイスとIDP（Identity Provider）間のいくつかの内部的なやり取りが含まれる場合があります。これらのやり取りは、最終的に有効なCookieが提供され、利用されて、ユーザーが元のページのコンテンツにアクセスできるようになるまで続きます。
注：
上記のメカニズムでシナリオがカバーされていない場合、または上記のメカニズムを使用するようにWebアプリを設定できない場合は、Citrix製品チームにお問い合わせください。

構成

ステップ0: はじめに

BCRでシングルサインオンを構成する方法は2つあります。構成方法は、目的のBCR Webサイトの認証メカニズムと、シングルサインオンをサポートするために複数のWebアプリケーションを構成する必要がある柔軟性によって異なります。
方法1: この方法では、Web Studioの既存のBCRポリシーを使用して、シングルサインオンのサポートを実現します。
シングルサインオンのサポートが導入される前は、ブラウザコンテンツリダイレクト認証サイトポリシーを使用して、認証（または中間ページ）に使用されるURLを指定し、フローの中断がないようにクライアントにリダイレクトしていました。
シングルサインオンサポートの導入により、BCRはVDA側のブラウザの認証Cookieを利用するため、認証サイトポリシーのURLは、代わりにブラウザコンテンツリダイレクトブロックリストポリシーで構成する必要があります。これにより、認証がVDAを介して行われることが保証されます。
方法2: この方法は方法1と同様のロジックで動作しますが、URLは代わりにJSON (bcrconfig.json) を介して構成され、ホストされているJSON URLがBCR ACLポリシーで呼び出されます。JSON構成は、追加の柔軟性を提供します。
  1. 企業は環境内で複数のWebアプリケーションを使用しており、各アプリケーションは実装に基づいて異なる認証メカニズムを使用する場合があります。新しいJSONメソッドにより、構成がより直感的で堅牢かつスケーラブルになります。
  2. ページ内フォームベース認証を扱う場合、方法1では、そのような構成をサポートする既存のポリシーがないため、特定の認証Cookieを設定する方法が提供されません。したがって、Webサイトでページ内フォームベース認証が必要な場合、JSONが唯一の方法です。
将来を見据えると、JSONはより堅牢な機能を導入するためのスケーラブルな方法を提供するため、CitrixはJSONベースの構成を試すことを推奨します。

ステップ1：認証メカニズムの決定

構成に使用する方法を決定するには、まずアプリケーションがどのような認証メカニズムを使用しているかを判断する必要があります。Webアプリケーションの認証方法を正確に判断するには、Webアプリケーション管理者に問い合わせるのが最善の方法です。
それが選択肢にない場合は、BCR拡張機能がインストールされていない状態で認証フローを実行しながら、ブラウザの開発者ツールのタブで要求/応答のやり取りを検査する必要があります。次の結果は、認証タイプを判断するのに役立ちます。
リダイレクトベースの認証の場合: 列で1つ以上の302（リダイレクト）応答を探します。302応答には、認証ページを指すロケーションヘッダーが含まれている必要があります。このページURLは、方法1を使用している場合はブラウザコンテンツリダイレクトブロックリストポリシーに設定し、方法2を使用している場合はbcrconfig.jsonファイルのアプリ構成のdenyListセクションに設定する必要があります。
ページ内フォームベース認証の場合: 列で複数のPOST要求を探します。POST要求に対する後続の応答の1つは、Webアプリ固有の認証Cookieを含むset-cookieヘッダーを返す必要があります。このCookieは、bcrconfig.jsonファイルのアプリ構成のcookiesセクションに設定する必要があります。方法1はページ内フォームベース認証をサポートしていないため、このシナリオでは方法2が唯一の構成オプションです。
例: github.comの例を次に示します。この方法は、BCRでリダイレクトしたいすべてのWebサイトで使用でき、適切な構成があることを確認できます。
  1. Chromeを開き、CTRL+SHIFT+Iを押して開発者ツールを表示します。
  2. タブをクリックします。
  3. 設定をオンにします。
  4. ネットワークログを簡素化するために、 フィルターをクリックします。
  5. 「名前」の横を右クリックし、「URL」列を追加します。
  6. 開発者ツールを開いたまま、github.com にアクセスします。
  7. github.com にサインインします。
  8. github.com の初期ページから、ログオン後の最終ページまでのすべての中間ホップをメモします。
  9. 上記で指定された認証タイプを特定するために、要求/応答ヘッダーを分析します。

ステップ2：構成方法を選択する

  1. リダイレクトベースの認証のみを扱っており、さまざまなニーズを持つ複数のWebアプリケーション（例：リダイレクトベースの認証を使用するWebアプリケーションと、ページ内フォームベースの認証を使用する別のWebアプリケーション）をリダイレクトする必要がない場合は、方法1を選択してシングルサインオンを構成できます。
  2. ページ内フォームベースの認証を扱っている場合、または異なる認証メカニズムを持つ複数のWebアプリケーションを扱っている場合、あるいはリダイレクトベースの認証のみであってもより柔軟性を求める場合は、方法2を選択できます。

ステップ3：構成

方法1：既存のポリシーでBCRシングルサインオンを構成する

  1. HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HDXMediaStream key: Dword BrowserProfileSharing value 1 に次のレジストリ値を作成して、VDAで機能を有効にします。
  2. リダイレクトするWebサイトでブラウザーコンテンツリダイレクトACL構成ポリシーを構成します。この点での構成変更はありません。
  3. 認証サイトポリシーにURLがすでに構成されている場合は、それらをブラウザーコンテンツリダイレクトブロックリストポリシーにコピーし、認証サイトポリシーを無効にします。
  4. 以前に認証/中間サイトを構成していない場合は、中間URLを特定し（BCR拡張機能がインストールされていない状態で認証フローを実行中に、ブラウザーの開発者ツールの「ネットワーク」タブにある要求/応答のやり取りから）、ブロックリストに構成します。

方法2：JSONでBCRシングルサインオンを構成する

bcrconfig.json の作成
bcrconfig.json には、複数の Web アプリ構成を含めることができます。BCR 拡張機能は、要求された URL を apps 配列内のいずれかのアプリで指定された allowList のいずれかに一致させ、関連するルールを動的に適用して、ページのリダイレクトとシングルサインオン処理を決定します。BCR 拡張機能が Web アプリをどのように処理するかを制御するために、次のキーを使用できます（JSON 仕様 に従って、ブール値は小文字である必要があることに注意してください - true または false のみ）。
  • appName : これは主に拡張機能の内部およびログ記録の目的で使用されます。
  • allowList : アプリには allowList に少なくとも 1 つの URL を含める必要があります。これは、クライアントがページをレンダリングし、VDA がレンダリングしないようにリダイレクトされることを意図した URL です。複数の URL を定義でき、ワイルドカードも使用できます。ワイルドカードのルールは、ブラウザコンテンツリダイレクト ACL 構成 とまったく同じです。たとえば、すべての Google アプリをリダイレクトするように構成するには、次の配列を使用します。
  • denyList : 認証が必要な場合に Web アプリケーションがユーザーをリダイレクトする URL を定義します。この構成は、主にリダイレクトベースの認証に不可欠ですが、一部のフォームベースの認証フローで特定の転送を防止するためにも使用できます。このキーにリストされている URL はリダイレクトされないため、サーバー側の認証が行われます。プロファイル共有が不要な場合に、ドメインの特定のサブ URL がクライアントにリダイレクトされないように制限するためにも使用できます。
  • profileSharing : これは、シングルサインオン認証 Cookie およびユーザー設定を保存するその他の Cookie が共有されるように設定する必要があるキー値であり、サーバー側とクライアント側でレンダリングされるページ間の一貫した動作を保証します。
  • cookies : Web アプリケーションがユーザーにプロンプトを表示せずに読み込まれるために必要な認証 Cookie を 1 つ以上定義します。拡張機能は、ここにリストされているすべての Cookie が指定された Web アプリ URL に対して設定されていると検出されるまで、クライアント側のリダイレクトを防止します。この設定は主にページ内フォームベース認証に使用されますが、特定のシナリオで denyList を指定することに加えて、リダイレクトベース認証にも利用できます。
  • deleteClientCache: bcrconfig.json 構成メカニズムが使用されている場合、BCR クライアントはセキュリティ強化のためにデフォルトでブラウザキャッシュを削除します。このプロセスは、ユーザーがリダイレクトされたすべてのタブを閉じるか、セッションで初めてリダイレクトされたページを開始したときに発生します。この動作を防止するには、このキーの値を false に設定します。クライアントデバイスが信頼されている場合、このキーを false に設定すると、ユーザーエクスペリエンスが向上します。クライアントデバイスが信頼されていない場合、このキーを設定しない（または）このキーを true に設定すると、セキュリティ体制が強化されます。
  • schemaVersion : これは主に拡張機能の内部およびログ記録の目的で使用されます。この記事の執筆時点では、その値は 2511 に設定されている必要があります。
構成例
{
  "apps": [
    {
      "appName": "myWebApp1",
      "allowList": [
        "https://myWebApp1.com/*"
      ],
      "denyList": [],
      "requires": {
        "profileSharing": false,
        "cookies": []
      }
    },
    {
      "appName": "myWebApp2",
      "allowList": [
        "https://myWebApp2.com/*"
      ],
      "denyList": [
        "https://myWebApp2.com/authPortal/*"
      ],
      "requires": {
        "profileSharing": true,
        "cookies": []
      }
    },
    {
      "appName": "myWebApp3",
      "allowList": [
        "https://*.myWebApp3.com/"
      ],
      "denyList": [
        "https://myWebApp3.com/authPortal/*"
      ],
      "requires": {
        "profileSharing": true,
        "cookies": [
          "requiredAuthCookie1",
          "requiredAuthCookie2"
        ]
      }
    }
  ],
  "preferences": {
    "deleteClientCache": true
  },
  "schemaVersion": "2511"
}
以下に bcrconfig.json ファイルのサンプルを示します。その要素については、以下で詳しく説明します。
上記の JSON 構造には、異なる構成を持つ 3 つのアプリが含まれています。
myWebApp1 シナリオ、SSO なし:
  • allowList キーの文字列配列値は、<https://myWebApp1.com> 内のすべてのパスがクライアントにリダイレクトされるべきであることを指定します。ただし、denyList キーにリストされている値がある場合はそれらを除きます。
  • denyList キーの文字列配列値は空であるため、認証サイトのリダイレクトは防止されません。したがって、認証は厳密にサーバー側で行われるわけではありません。
  • profileSharing キーのブール値が false に設定されているため、allowList エントリに関連するクッキーはクライアントと共有されません。
  • cookies キーの文字列配列は空ですが、profileSharing 共有キーが false に設定されているため、いずれにしても無視されます。
myWebApp2、リダイレクトベースの認証シナリオ:
  • allowList キーの文字列配列値は、<https://myWebApp2.com> 内のすべてのパスがクライアントにリダイレクトされるべきであることを指定します。ただし、denyList キーにリストされている値がある場合はそれらを除きます。
  • denyList キーの文字列配列値は、myWebApp2.com ドメイン下の /authPortal/ で始まるパスがクライアント側のリダイレクトから除外され、サーバー側の認証が実行されるように指定します。
  • profileSharing キーのブール値が true に設定されているため、allowList エントリに関連するクッキーはクライアントと共有され、シングルサインオンが実行されます。
  • cookies キーの文字列配列は空であるため、拡張機能は、サーバー側認証後に特定のクッキーが設定されるのを待たずに、クライアントと共有します。
myWebApp3、フォームベースの認証シナリオ:
  • allowList キーの文字列配列値は、<https://myWebApp3.com> 内のすべてのパスがクライアントにリダイレクトされるべきであることを指定します。ただし、denyList キーにリストされている値がある場合はそれらを除きます。
  • denyList キーの文字列配列値は、myWebApp3.com ドメイン下の /authPortal/ で始まるパスがクライアント側のリダイレクトから除外され、サーバー側の認証が実行されるように指定します。
  • profileSharing キーのブール値が true に設定されているため、allowList エントリに関連するクッキーはクライアントと共有されます。
  • cookies キーの文字列配列にはクッキー名が含まれているため、拡張機能はサーバー側認証後にこのクッキーが設定されるのを待ちます。allowList の関連 URL のクッキーはクライアントと共有され、クライアント側のリダイレクトが発生します。
環境設定
  • deleteClientCache キーは true に設定されているため、BCR クライアントはセキュリティ強化のためにデフォルトでブラウザキャッシュを削除します。これは、キーが設定されていない場合でもデフォルトの動作です。
BCR ポリシーの構成
bcrconfig.json を作成したら、以下の手順に従って Browser Content Redirection ACL configuration を構成し、JSON ファイルのコンテンツを使用します。
  • ファイルに .bcrconfig.json 拡張子を付けて名前を付けます。例: myrules.bcrconfig.json
  • JSON ファイルを VDA からアクセス可能な Web サーバーでホストし、URL をメモします。
    注：
    サーバーはファイルのダウンロードを許可する必要があります。Microsoft IIS サイトは、デフォルトで JSON ファイルのダウンロードを許可しています。
  • Citrix Studio の で、前の手順で取得した URL を 設定に追加します。
    注：
    設定の他のエントリはそのまま残すことができます。競合が発生した場合、BCR 拡張機能は bcrconfig.json 設定を優先します。Citrix は、管理の容易さ、アプリケーションレベルの構成、およびスケーラビリティのために、構成全体を JSON に移行することを推奨します。
  • ポリシーを保存し、セッションを起動してポリシー構成をテストします。
    注：
    ポリシーを設定した後、ホストされている bcrconfig.json ファイルをいつでも編集して調整できます。ファイルは、BCR 拡張機能を実行しているメインのブラウザプロセスが起動または再起動したときにのみ再ロードされ、変更が適用されます。
注：
  • 要するに、ポリシーの観点からは、ブラウザコンテンツリダイレクトポリシー（デフォルトで有効）を有効にし、JSON ファイルを指す URL を使用してブラウザコンテンツリダイレクト ACL 構成ポリシーを構成するだけで済みます。
  • JSON 構成は現在、以下のポリシーに適用され、それらを柔軟にします。ただし、残りのポリシーは以前と同じ動作を継続します。
    • ブラウザコンテンツリダイレクト ACL 構成: ACL 内の URL は、allowList キーを介して JSON で構成できるようになりました。
    • ブラウザコンテンツリダイレクトブロックリスト構成: ブロックリストは、denyList キーを介して JSON で構成できるようになりました。
    • ブラウザコンテンツリダイレクト認証サイト: 認証サイトも、denyList キーを介して JSON で構成できます。