Citrix Virtual Apps and Desktops

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

May 31, 2026

寄稿者:

はじめに

ブラウザコンテンツリダイレクトは、シングルサインオンのサポートにより合理化されたユーザーエクスペリエンスを提供し、VDA側での認証とCookieの共有を可能にします。

この機能強化により、冗長なログインが不要になり、BCRウィンドウが閉じられた後でもBCRセッション全体で認証とCookieの永続性を維持することで、生産性が向上します。

このシームレスなエクスペリエンスは、認証がクライアントではなくVDAから行われるようにすることで、セキュリティをさらに強化します。

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

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

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

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

必要最小要件

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

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

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

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

この標準的な方法では、アプリケーションはHTTPリダイレクトを使用して、ユーザーを認証専用ページに強制的に移動させます。

例えば、ユーザーが必要なセッションCookieなしで https://my.intranet.app にアクセスしようとすると、Webアプリケーションは認証エンドポイント（https://my.intranet.app/auth など）へのHTTP 302リダイレクトで応答します。

ユーザーがそのページで正常に認証されると、ブラウザは元のアプリケーションURLにリダイレクトされ、必要な認証Cookieが含まれるようになります。

ページ内フォームベース認証 [Preview]

この方法では、ログインインターフェースを動的に表示しながら、ユーザーを意図したアプリケーションURLに留めます。

例えば、ユーザーが https://my.intranet.app のような保護されたページに移動すると、必要なCookieがないため、リダイレクトをトリガーすることなく、ページが認証フォームを直接ロードします。このプロセスには、ページインターフェースとIDP (Identity Provider) の間でいくつかの内部的なやり取りが含まれる場合があります。これらのやり取りは、最終的に有効なCookieが提供され、利用されて、ユーザーが元のページのコンテンツにアクセスできるようになるまで続きます。

注:

上記のメカニズムでシナリオがカバーされない場合、またはWebアプリを上記のメカニズムを使用するように設定できない場合は、Citrix製品チームにお問い合わせください。

コンフィギュレーション

ステップ0: はじめに

BCRでシングルサインオンを構成するには、2つの方法があります。構成方法の選択は、目的のBCRウェブサイトの認証メカニズムと、シングルサインオンをサポートするために複数のウェブアプリケーションを構成する必要がある柔軟性によって異なります。

方法1: この方法は、Web Studioの既存のBCRポリシーを使用して、シングルサインオンのサポートを実現します。

シングルサインオンのサポートが導入される前は、ブラウザコンテンツリダイレクト認証サイトポリシーが、認証（または中間ページ）に使用されるURLを指定するために使用され、フローが中断されないようにクライアントにリダイレクトされていました。

シングルサインオンのサポートが導入されたことで、BCRはVDA側のブラウザの認証Cookieを活用するようになり、そのため、認証サイトポリシーのURLは、代わりにブラウザコンテンツリダイレクトブロックリストポリシーで構成する必要があります。これにより、認証がVDAを介して行われることが保証されます。

方法2: この方法は方法1と同様のロジックで動作しますが、URLはJSON (bcrconfig.json) を介して構成され、ホストされているJSON URLはBCR ACLポリシーで呼び出されます。JSON構成は、追加の柔軟性を提供します。

企業は環境内で複数のウェブアプリケーションを使用しており、各アプリケーションは実装に基づいて異なる認証メカニズムを使用する場合があります。新しいJSONメソッドにより、構成がより直感的で堅牢かつスケーラブルになります。
ページ内フォームベース認証を扱う場合、方法1では、そのような構成をサポートする既存のポリシーがないため、特定の認証Cookieを設定する方法が提供されません。したがって、ウェブサイトがページ内フォームベース認証を必要とする場合、JSONが唯一の方法です。

将来を見据えると、JSONはより堅牢な機能を導入するためのスケーラブルな方法を提供するため、CitrixはJSONベースの構成を試すことを推奨します。

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

構成に使用する方法を決定するには、まずアプリケーションがどのような認証メカニズムを使用しているかを判断する必要があります。ウェブアプリケーションの認証方法を正確に判断する最善の方法は、ウェブアプリケーションの管理者にお問い合わせいただくことです。

それが選択肢にない場合は、BCR拡張機能がインストールされていない状態で認証フローを実行しながら、ブラウザの開発者ツールの「ネットワーク」タブでリクエスト/レスポンスのやり取りを検査する必要があります。以下の結果は、認証タイプを判断するのに役立ちます。

リダイレクトベース認証の場合: ステータス列で1つ以上の302（リダイレクト）応答を探します。302応答には、認証ページを指すロケーションヘッダーが含まれているはずです。このページURLは、方法1を使用している場合はブラウザコンテンツリダイレクトブロックリストポリシーに、方法2を使用している場合はbcrconfig.jsonファイルのアプリ構成のdenyListセクションに設定する必要があります。

ページ内フォームベース認証の場合: メソッド列で複数のPOSTリクエストを探します。POSTリクエストに対する後の応答の1つは、ウェブアプリ固有の認証Cookieを含むset-cookieヘッダーを返すはずです。このCookieは、bcrconfig.jsonファイルのアプリ構成のCookieセクションに設定する必要があります。方法1はページ内フォームベース認証をサポートしていないため、このシナリオでは方法2が唯一の構成オプションです。

例: ここにgithub.comの例を示します。この方法は、BCRでリダイレクトしたい任意のウェブサイトに使用でき、正しい構成であることを確認できます。

Chromeを開き、CTRL+SHIFT+Iを押して開発者ツールを表示します。
「Network」タブをクリックします。
「Preserve log」設定をオンにします。
「Doc」フィルターをクリックして、ネットワークログを簡素化します。
「Name」の横を右クリックし、「URL」列を追加します。
開発者ツールを開いたまま、github.comにアクセスします。
github.comにサインインします。
github.comの初期ページからログオン後の宛先までのすべての中間ホップをメモします。
要求/応答ヘッダーを分析して、上記で指定された認証タイプを特定します。

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

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

ステップ3：構成

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

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

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

bcrconfig.json ファイルを新規作成する

bcrconfig.jsonには、複数のWebアプリ構成を含めることができます。BCR拡張機能は、要求されたURLをapps配列内のいずれかのアプリによって指定されたallowListのいずれかに一致させようとし、関連するルールを動的に適用して、ページの再ルーティングとシングルサインオン処理をどのように処理するかを決定します。BCR拡張機能がWebアプリをどのように扱うかを制御するために、以下のキーを使用できます（JSON仕様に従って、boolean値は小文字である必要があることに注意してください - trueまたはfalseのみ）。

appName [string value, mandatory]: これは主に拡張機能の内部で、ログ記録の目的で使用されます。
allowList [string array, mandatory]: アプリにはallowListに少なくとも1つのURLを含める必要があります。これは、クライアントがページをレンダリングし、VDAではないようにリダイレクトされることを意図したURLです。複数のURLを定義でき、ワイルドカードも受け入れられます。ワイルドカードルールは、Browser Content Redirection ACL configurationとまったく同じです。たとえば、すべてのGoogleアプリをリダイレクトするように構成するには、次の配列を使用します。

[“.google.com/”, “.google.com”, “.youtube.com”, “.youtube.com/”]
denyList [string value, optional]: 認証が必要なときにWebアプリケーションがユーザーをリダイレクトするURLを定義します。この構成は、主にリダイレクトベースの認証に不可欠ですが、一部のフォームベースの認証フローで特定の再ルーティングを防ぐためにも使用できます。このキーにリストされているURLはリダイレクトされないため、サーバー側の認証が行われます。プロファイル共有が不要な場合に、ドメインの特定のサブURLがクライアントにリダイレクトされないように制限するためにも使用できます。
profileSharing [boolean value, mandatory]: これは、シングルサインオン認証クッキーやユーザー設定を保存するその他のクッキーが共有され、サーバー側とクライアント側でレンダリングされるページ間で一貫した動作を保証するために設定する必要があるキー値です。
cookies [string array, optional]: Webアプリケーションがユーザーにプロンプトを表示せずにロードするために必要な1つ以上の認証クッキーを定義します。拡張機能は、ここにリストされているすべてのクッキーが指定されたWebアプリURLに設定されていると検出されるまで、クライアント側のリダイレクトを防止します。この設定は主にページ内フォームベース認証に使用されますが、特定のシナリオでdenyListを指定することに加えて、リダイレクトベース認証にも利用できます。
deleteClientCache[boolean value, optional]: bcrconfig.json構成メカニズムが使用されている場合、BCRクライアントはセキュリティ強化のためにデフォルトでブラウザキャッシュを削除します。このプロセスは、ユーザーがリダイレクトされたすべてのタブを閉じるか、セッションで初めてリダイレクトされたページを開始したときに発生します。この動作を防ぐには、このキーの値をfalseに設定します。クライアントデバイスが信頼されている場合、このキーをfalseに設定するとユーザーエクスペリエンスが向上します。クライアントデバイスが信頼されていない場合、このキーを設定しない（または）このキーをtrueに設定すると、セキュリティ体制が強化されます。
schemaVersion [string value, mandatory]: これは主に拡張機能の内部で、ログ記録の目的で使用されます。本稿執筆時点では、その値は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"
}
<!--NeedCopy-->

以下にサンプル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キーの文字列配列値は、myWebApp2.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
VDAからアクセス可能なWebサーバーにJSONファイルをホストし、URLをメモします。

注:

サーバーはファイルのダウンロードを許可する必要があります。Microsoft IISサイトは、デフォルトでJSONファイルのダウンロードを許可しています。
Citrix Studioのポリシーで、前の手順で取得したURLを「ブラウザコンテンツリダイレクトACL設定」に追加します。

注:

「Browser content redirection ACL configuration」設定の他のエントリは残しておくことができます。競合が発生した場合、BCR拡張機能はbcrconfig.json設定を優先します。Citrixは、管理の容易さ、アプリケーションレベルの構成、およびスケーラビリティのために、構成全体をJSONに移行することを推奨します。
ポリシーを保存し、セッションを起動してポリシー構成をテストします。

注:

ポリシーを設定した後、ホストされているbcrconfig.jsonファイルをいつでも編集して調整できます。ファイルは、BCR拡張機能を実行しているメインのブラウザプロセスが起動または再起動したときにのみ再読み込みされ、変更が適用されます。

注:

要するに、ポリシーの観点からは、ブラウザコンテンツリダイレクトポリシー（デフォルトで有効）を有効にし、JSONファイルを指すURLでブラウザコンテンツリダイレクトACL構成ポリシーを構成するだけで済みます。

JSON構成は現在、以下のポリシーに適用され、それらを柔軟にしますが、残りのポリシーは以前と同じ動作を継続します。

ブラウザコンテンツリダイレクトACL構成: ACL内のURLは、allowListキーを介してJSONで構成できるようになりました。

ブラウザコンテンツリダイレクトブロックリスト構成: ブロックリストは、denyListキーを介してJSONで構成できるようになりました。

ブラウザコンテンツリダイレクト認証サイト: 認証サイトも、denyListキーを介してJSONで構成することもできます。

この製品ドキュメントの正式なバージョンは英語版です。英語以外のすべてのバージョンは、お客様の利便性のためにのみ提供され、機械翻訳された内容が含まれている場合があります。詳しくは、Cloud Software Group home で機械翻訳に関する免責事項（Machine Translation Disclaimer）をご覧ください。

この情報は役に立ちましたか?

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

May 31, 2026

寄稿者:

May 31, 2026

寄稿者:

この情報は役に立ちましたか?