製品ドキュメント
Citrix Virtual Apps and Desktops
Service Current Release 2402 LTSR 2311 2308 2305 2303 2212 2209 2206 2203 LTSR 1912 LTSR
PDFを表示

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

April 6, 2026
寄稿者: 
C

はじめに

Browser Content Redirection は、VDA側での認証とクッキー共有を可能にするシングルサインオンのサポートにより、合理化されたユーザーエクスペリエンスを提供するようになりました。

  • この機能強化により、冗長なログインが排除され、BCRウィンドウが閉じられた後でもBCRセッション全体で認証とクッキーの永続性が維持されるため、プロダクティビティが向上します。

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

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

  • BCR内で認証済みページを開くたびに、ユーザーは資格情報を再入力する必要があり、SSOの永続性が途切れていました。
  • SSOはBCRウィンドウが開いている間のみ維持され、ウィンドウを閉じたり再度開いたりすると、ユーザーはログインプロセスを繰り返す必要がありました。

  • 認証フローはクライアントから行われていたため、管理者はクライアントデバイスからセキュアな認証サイトへのネットワークアクセスを提供する必要がありました。

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

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

最小要件

  • Citrix Virtual Apps and Desktops 2511
  • Citrix Workspace App for Windows 2511
  • Citrix Workspace App for Linux 2511 (プレビュー)
  • Browser Redirection Extension (ChromeまたはEdge) 25.11以降

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

BCRシングルサインオンで現在サポートされている認証シーケンスには、2つのタイプがあります。

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

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

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

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

ページ内フォームベースの認証 [プレビュー]

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

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

注:

上記のメカニズムでシナリオがカバーされない場合、または上記のメカニズムを使用するようにウェブアプリを設定できない場合は、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構成は、追加の柔軟性を提供します。

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

方法2: JSONによるBCRシングルサインオンの構成

bcrconfig.jsonの作成

bcrconfig.jsonには、いくつかのWebアプリ構成を含めることができます。BCR拡張機能は、要求されたURLをアプリ配列内のいずれかのアプリによって指定されたallowListの1つと照合しようとし、ページリダイレクトとシングルサインオン処理を処理する方法を決定するために、関連するルールを動的に適用します。WebアプリがBCR拡張機能によってどのように扱われるかを制御するために、以下のキーを使用できます（ブール値はJSON仕様に従って小文字である必要があります - trueまたはfalseのみ）。

  • appName [文字列値、必須]: これは主に拡張機能の内部およびログ記録の目的で使用されます。

  • allowList [文字列配列、必須]: アプリにはallowListに少なくとも1つのURLを含める必要があります。これは、クライアントがページをレンダリングし、VDAがレンダリングしないようにリダイレクトされることを意図したURLです。複数のURLを定義でき、ワイルドカードも受け入れられます。ワイルドカードルールは、ブラウザコンテンツリダイレクトACL構成とまったく同じです。たとえば、すべてのGoogleアプリをリダイレクトするように構成するには、次の配列を使用します。

    [“.google.com/”, “.google.com”, “.youtube.com”, “.youtube.com/”]

  • denyList [文字列値、オプション]: 認証が必要なときにWebアプリケーションがユーザーをリダイレクトするURLを定義します。この構成は主にリダイレクトベース認証に不可欠ですが、一部のフォームベース認証フローで特定の転送を防ぐためにも使用できます。このキーにリストされているURLはリダイレクトされないため、サーバー側の認証が行われます。プロファイル共有が不要な場合に、ドメインの特定のサブURLがクライアントにリダイレクトされないように制限するためにも使用できます。

  • profileSharing [ブール値、必須]: これは、シングルサインオン認証Cookieおよびユーザー設定を保存するその他のCookieが共有され、サーバー側とクライアント側でレンダリングされるページ間で一貫した動作を保証するために設定する必要があるキー値です。

  • cookies [文字列配列、オプション]: ウェブアプリケーションがユーザーにプロンプトを表示せずにロードするために必要な認証クッキーを1つ以上定義します。拡張機能は、ここにリストされているすべてのクッキーが指定されたウェブアプリ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"
}
<!--NeedCopy-->

bcrconfig.json ファイルのサンプルを以下に示します。その要素については、以下で詳しく説明します。

上記の JSON 構造には、異なる構成を持つ 3 つのアプリが含まれています。

myWebApp1 シナリオ、SSO なし

  • allowList キーの文字列配列値は、denyList キーにリストされている値（存在する場合）を除き、https://myWebApp1.com 内のすべてのパスがクライアントにリダイレクトされることを指定します。
  • denyList キーの文字列配列値は空であるため、リダイレクトが防止される認証サイトはありません。したがって、認証は厳密にはサーバー側で保持されません。
  • profileSharing キーのブール値は false に設定されているため、allowList エントリに関連するクッキーはクライアントと共有されません。
  • cookies キーの文字列配列は空ですが、profileSharing 共有キーが false に設定されているため、いずれにしても無視されます。

myWebApp2、リダイレクトベースの認証シナリオ

  • allowList キーの文字列配列値は、denyList キーにリストされている値（存在する場合）を除き、https://myWebApp2.com 内のすべてのパスがクライアントにリダイレクトされることを指定します。

  • denyList キーの文字列配列値は、myWebApp2.com ドメイン下の /authPortal/ で始まるパスがクライアント側のリダイレクトから防止され、サーバー側の認証が実行されるように指定します。

  • profileSharing キーのブール値は true に設定されているため、allowList エントリに関連するクッキーはクライアントと共有され、シングルサインオンが実行されます。

  • cookies キーの文字列配列は空であるため、拡張機能はサーバー側認証後に特定のクッキーが設定されるのを待たずに、クライアントと共有されます。

myWebApp3、フォームベースの認証シナリオ

  • allowList キーの文字列配列値は、denyList キーにリストされている値（存在する場合）を除き、https://myWebApp3.com 内のすべてのパスがクライアントにリダイレクトされることを指定します。
  • denyList キーの文字列配列値は、myWebApp2.com ドメイン下の /authPortal/ で始まるパスがクライアント側のリダイレクトから防止され、サーバー側の認証が実行されるように指定します。
  • profileSharing キーのブール値は true に設定されているため、allowList エントリに関連するクッキーはクライアントと共有されます。
  • cookies キーの文字列配列にはクッキー名が含まれているため、拡張機能はサーバー側認証後にこのクッキーが設定されるのを待ちます。allowList 内の関連 URL のクッキーはクライアントと共有され、クライアント側のリダイレクトが発生します。

設定

  • deleteClientCache キーは true に設定されているため、BCR クライアントはセキュリティ強化のためにデフォルトでブラウザキャッシュを削除します。これは、キーが設定されていない場合でもデフォルトの動作です。

BCR ポリシーの構成

bcrconfig.json を作成したら、以下の手順に従って、JSON ファイルのコンテンツを使用するように Browser Content Redirection ACL configuration を構成します。

  • ファイルに .bcrconfig.json 拡張子を付けます（例: myrules.bcrconfig.json）

  • JSON ファイルを VDA からアクセス可能な Web サーバーでホストし、URL をメモします。

    注:

    サーバーはファイルのダウンロードを許可する必要があります。Microsoft IIS サイトはデフォルトで JSON ファイルのダウンロードを許可しています。

  • Citrix Studio の [ポリシー] で、前の手順で取得した URL を [Browser content redirection ACL configuration] 設定に追加します。

    注:

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

  • ポリシーを保存し、セッションを起動してポリシー構成をテストします。

    注:

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

    注:

    • 要するに、ポリシーの観点からは、Browser Content Redirection ポリシー（デフォルトで有効）を有効にし、JSON ファイルを指す URL を使用して Browser Content Redirection ACL configuration ポリシーを構成するだけで済みます。

    • JSON 構成は現在、以下のポリシーに適用され、それらを柔軟にしますが、残りのポリシーは以前と同じアクションを実行し続けます。

      • Browser content redirection ACL configuration: ACL 内の URL は、allowList キーを介して JSON で構成できるようになりました。
      • Browser Content redirection block list configuration: ブロックリストは、denyList キーを介して JSON で構成できるようになりました。
      • Browser Content redirection authentication sites: 認証サイトも、denyList キーを介して JSON で構成できます。
シングルサインオンのサポート
April 6, 2026
寄稿者: 
C
April 6, 2026
寄稿者: 
C

この記事の概要

サイトに関するフィードバック | Your privacy choices footer linkプライバシーに関する選択肢 | プライバシーと法令 | Cookieの設定 | 同意設定 | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.