シングルサインオンのサポート
はじめに
Browser Content Redirectionは、シングルサインオンのサポートにより、VDA側での認証とCookie共有を可能にし、効率化されたユーザーエクスペリエンスを提供します。
この機能強化により、重複するログインが排除され、BCRウィンドウが閉じられた後でもBCRセッション全体で認証とCookieの永続性が維持されるため、生産性が向上します。
このシームレスなエクスペリエンスは、認証がクライアントではなくVDAから行われるようにすることで、セキュリティをさらに強化します。
シングルサインオンなしの場合
-
BCR内で認証されたページを開くと、ユーザーは毎回資格情報を再入力する必要があり、SSOの永続性が失われました。
-
SSOはBCRウィンドウが開いている間のみ維持されました。ウィンドウを閉じて再度開くと、ユーザーはログインプロセスを繰り返す必要がありました。
-
認証フローはクライアントから行われたため、管理者はクライアントデバイスからセキュアな認証サイトへのネットワークアクセスを提供する必要がありました。
シングルサインオンありの場合
-
VDAブラウザからSSOがシームレスに保持されるため、ユーザーは資格情報の入力を求められなくなります (VDAで既に認証されている場合)。
-
認証はVDAから行われるため、クライアント側のネットワーク要件と露出が制限され、セキュリティ体制が向上し、大幅に改善された中断のないエクスペリエンスが提供されます。
最小要件
-
Citrix バーチャルアプリおよびデスクトップ 2507
-
Citrix Workspace アプリ Windows 向け 2511
-
Citrix Workspace アプリ 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ウェブサイトの認証メカニズムと、シングルサインオンをサポートするために複数のウェブアプリケーションを構成する必要がある柔軟性によって異なります。
方法1: この方法では、Web Studioの既存のBCRポリシーを使用して、シングルサインオンのサポートを実現します。
シングルサインオンのサポートが導入される前は、ブラウザコンテンツリダイレクト認証サイトポリシーを使用して、認証（または中間ページ）に使用されるURLを指定し、フローの中断がないようにクライアントにリダイレクトしていました。
シングルサインオンのサポートが導入されたことで、BCRはVDA側のブラウザの認証Cookieを活用するようになり、そのため、認証サイトポリシーのURLは、代わりにブラウザコンテンツリダイレクトブロックリストポリシーで構成する必要があります。これにより、認証がVDAを介して行われるようになります。
方法2: この方法は方法1と同様のロジックで動作しますが、URLは代わりにJSON (
bcrconfig.json) を介して構成され、ホストされているJSON URLがBCR ACLポリシーで呼び出されます。JSON構成は、追加の柔軟性を提供します。
-
企業は環境内で複数のWebアプリケーションを使用しており、各アプリケーションは実装に基づいて異なる認証メカニズムを使用する場合があります。新しいJSONメソッドにより、構成がより直感的で堅牢かつスケーラブルになります。
-
ページ内フォームベース認証を扱う場合、方法1では、そのような構成をサポートする既存のポリシーがないため、特定の認証Cookieを設定する方法が提供されません。したがって、Webサイトでページ内フォームベース認証が必要な場合、JSONが唯一の方法です。
将来を見据えると、JSONはより堅牢な機能を導入するためのスケーラブルな方法を提供するため、CitrixはJSONベースの構成を推奨します。
ステップ1：認証メカニズムの決定
構成に使用するメソッドを決定するには、まずアプリケーションがどのような認証メカニズムを使用しているかを判断する必要があります。ウェブアプリケーションの認証方法を正確に判断する最善の方法は、ウェブアプリケーション管理者に連絡することです。
それが選択肢にない場合は、BCR拡張機能がインストールされていない状態で認証フローを実行しながら、ブラウザの開発者ツールのタブで要求/応答のやり取りを検査する必要があります。次の結果は、認証タイプを判断するのに役立ちます。
リダイレクトベース認証の場合: ステータス列で1つ以上の302 (リダイレクト) 応答を探します。302応答には、認証ページを指すロケーションヘッダーが含まれているはずです。このページURLは、方法1を使用している場合はブラウザコンテンツリダイレクトブロックリストポリシーに、方法2を使用している場合は
bcrconfig.jsonファイルのアプリ構成のdenyListセクションに設定する必要があります。
ページ内フォームベース認証の場合: メソッド列で複数のPOSTリクエストを探します。POSTリクエストに対する後の応答の1つは、Webアプリ固有の認証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が設定されている場合は、それらをブラウザコンテンツリダイレクトブロックリストポリシーにコピーし、認証サイトポリシーを無効にします。
方法2：JSONでBCRシングルサインオンを構成する
bcrconfig.json の作成
bcrconfig.jsonには複数のWebアプリ構成を含めることができます。BCR拡張機能は、要求されたURLをapps配列内のいずれかのアプリによって指定されたallowListのいずれかに一致させようとし、関連するルールを動的に適用して、ページのリダイレクトとシングルサインオン処理をどのように処理するかを決定します。BCR拡張機能がWebアプリをどのように扱うかを制御するために、以下のキーを使用できます（JSON仕様に従って、ブール値は小文字である必要があることに注意してください - trueまたはfalseのみ）。
-
allowList : アプリには
allowListに少なくとも1つのURLを含める必要があります。これは、クライアントがページをレンダリングし、VDAではないようにリダイレクトされることを意図したURLです。複数のURLを定義でき、ワイルドカードも受け入れられます。ワイルドカードルールは、ブラウザコンテンツリダイレクトACL構成とまったく同じです。たとえば、すべてのGoogleアプリをリダイレクトするように構成するには、次の配列を使用します。 -
deleteClientCache:
bcrconfig.json構成メカニズムが使用されている場合、BCRクライアントはセキュリティ強化のためにデフォルトでブラウザキャッシュを削除します。このプロセスは、ユーザーがリダイレクトされたすべてのタブを閉じるか、セッションで初めてリダイレクトされたページを開始したときに発生します。この動作を防ぐには、このキーの値をfalseに設定します。クライアントデバイスが信頼されている場合、このキーをfalseに設定するとユーザーエクスペリエンスが向上します。クライアントデバイスが信頼されていない場合、このキーを設定しない（または）このキーをtrueに設定すると、セキュリティ体制が強化されます。
構成例
{
"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エントリに関連するCookieはクライアントと共有されません。 -
cookiesキーの文字列配列は空ですが、
profileSharing共有キーがfalseに設定されているため、いずれにしても無視されます。
myWebApp2、リダイレクトベースの認証シナリオ:
-
allowListキーの文字列配列値は、<https://myWebApp2.com>内のすべてのパスをクライアントにリダイレクトする必要があることを指定します。ただし、denyListキーにリストされている値がある場合は除きます。 -
denyListキーの文字列配列値は、myWebApp2.comドメイン下の/authPortal/で始まるパスがクライアント側のリダイレクトを防止され、サーバー側の認証が実行できるように指定します。 -
profileSharingキーのブール値が true に設定されているため、allowList エントリに関連するクッキーはクライアントと共有され、シングルサインオンが実行されます。 -
cookiesキーの文字列配列は空であるため、拡張機能はサーバー側認証後に特定のCookieが設定されるのを待たずに、クライアントと共有されます。
myWebApp3、フォームベースの認証シナリオ:
-
allowListキーの文字列配列値は、<https://myWebApp3.com>内のすべてのパスをクライアントにリダイレクトする必要があることを指定します。ただし、denyListキーにリストされている値がある場合は除きます。 -
denyListキーの文字列配列値は、myWebApp3.comドメイン下の/authPortal/で始まるパスがクライアント側のリダイレクトを防止され、サーバー側の認証が実行できるように指定します。 -
profileSharingキーのブール値はtrueに設定されているため、allowListエントリに関連するCookieはクライアントと共有されます。 -
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 ファイルのダウンロードを許可しています。
-
注:
-
ポリシーを保存し、セッションを起動してポリシー構成をテストします。注:ポリシーを設定した後、ホストされている
bcrconfig.jsonファイルはいつでも編集して調整できます。ファイルは、BCR 拡張機能を実行しているメインのブラウザプロセスが起動または再起動したときにのみ再ロードされ、変更が適用されます。
注記:
-
要するに、ポリシーの観点からは、Browser Content Redirectionポリシー（これはデフォルトで有効になっています）を有効にし、JSONファイルを指すURLでBrowser Content Redirection ACL構成ポリシーを構成するだけで済みます。
-
JSON 構成は現在、以下のポリシーに適用され、それらを柔軟にします。ただし、残りのポリシーは以前と同じ動作を継続します。
-
ブラウザコンテンツリダイレクト ACL 構成: ACL 内の URL は、
allowListキーを介して JSON で構成できるようになりました。 -
ブラウザコンテンツリダイレクトブロックリスト構成: ブロックリストは、
denyListキーを介して JSON で構成できるようになりました。 -
ブラウザコンテンツリダイレクト認証サイト: 認証サイトも、
denyListキーを介して JSON で構成できます。
-