シングルサインオンのサポート
はじめに
ブラウザコンテンツリダイレクトは、シングルサインオンのサポートにより、VDA側での認証とCookie共有を可能にし、合理化されたユーザーエクスペリエンスを提供するようになりました。
この機能強化により、冗長なログインが不要になり、BCRウィンドウが閉じられた後でもBCRセッション全体で認証とCookieの永続性が維持されるため、生産性が向上します。
このシームレスなエクスペリエンスは、認証がクライアントではなくVDAから行われることを保証することで、セキュリティをさらに強化します。
シングルサインオンなしの場合
- BCR内で認証されたページを開くたびに、ユーザーは資格情報を再入力する必要があり、SSOの永続性が失われていました。
- SSOはBCRウィンドウが開いている間のみ維持され、ウィンドウを閉じたり再度開いたりすると、ユーザーはログインプロセスを繰り返す必要がありました。
- 認証フローはクライアントから行われていたため、管理者はクライアントデバイスからセキュアな認証サイトへのネットワークアクセスを提供する必要がありました。
シングルサインオンありの場合
- VDAブラウザからSSOがシームレスに保持されるため、ユーザーは資格情報の入力を求められることはありません（VDAで既に認証されている場合）。
- 認証はVDAから行われるため、クライアント側のネットワーク要件と露出が制限され、セキュリティ体制が向上し、大幅に改善された中断のないエクスペリエンスが提供されます。
必要最低要件
- シトリックス バーチャルアプリおよびデスクトップ 2507
- シトリックス ワークスペース アプリ 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が含まれるようになります。
ページ内フォームベース認証 [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を押して開発者ツールを表示します。
- 「ネットワーク」タブをクリックします。
- 「ログを保持」設定をオンにします。
- ネットワークログを簡素化するには、「Doc」フィルターをクリックします。
- 「名前」の横を右クリックし、「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でこの機能を有効にします。 - リダイレクトするWebサイトでブラウザーコンテンツリダイレクトACL構成ポリシーを構成します。この点に関する構成の変更はありません。
- 認証サイトポリシーにすでにURLが設定されている場合は、それらをブラウザコンテンツリダイレクトブロックリストポリシーにコピーし、認証サイトポリシーを無効にします。
- 以前に認証/仲介サイトを設定していない場合は、仲介URL（BCR拡張機能がインストールされていない状態で認証フローを実行中に、ブラウザの開発者ツールの[ネットワーク]タブにあるリクエスト/レスポンスのやり取りから）を特定し、ブロックリストに設定します。
方法2：JSONでBCRシングルサインオンを構成する
bcrconfig.json というファイルの作成
bcrconfig.jsonには、いくつかのWebアプリ構成を含めることができます。BCR拡張機能は、要求されたURLをapps配列内のいずれかのアプリによって指定されたallowListのいずれかに一致させようとし、関連するルールを動的に適用して、ページの再ルーティングとシングルサインオン処理をどのように処理するかを決定します。BCR拡張機能がWebアプリをどのように扱うかを制御するために、次のキーを使用できます（ブール値はJSON仕様に従って小文字である必要があることに注意してください - trueまたはfalseのみ）。
- appName [string value, mandatory]: これは主に拡張機能の内部およびログ記録の目的で使用されます。
-
allowList [string array, mandatory]: アプリには
allowListに少なくとも1つのURLを含める必要があります。これは、クライアントがページをレンダリングし、VDAがレンダリングしないようにリダイレクトされることを意図したURLです。複数のURLを定義でき、ワイルドカードも受け入れられます。ワイルドカードルールは、ブラウザコンテンツリダイレクトACL構成とまったく同じです。たとえば、すべてのGoogleアプリをリダイレクトするように構成するには、次の配列を使用します。[“.google.com/”, “.google.com”, “.youtube.com”, “.youtube.com/”]
- denyList [string value, optional]: 認証が必要なときにWebアプリケーションがユーザーをリダイレクトするURLを定義します。この構成は、リダイレクトベースの認証に主に不可欠ですが、一部のフォームベースの認証フローで特定の再ルーティングを防ぐためにも使用できます。このキーにリストされているURLはリダイレクトされないため、サーバー側の認証が行われます。プロファイル共有が不要な場合に、ドメインの特定のサブURLがクライアントにリダイレクトされないように制限するためにも使用できます。
- profileSharing [boolean value, mandatory]: これは、シングルサインオン認証Cookieとユーザー設定を保存するその他のCookieが共有されるように設定する必要があるキー値であり、サーバー側とクライアント側でレンダリングされるページ間で一貫した動作を保証します。
- cookies [string array, optional]: Webアプリケーションがユーザーにプロンプトを表示せずにロードするために必要な1つ以上の認証Cookieを定義します。拡張機能は、ここにリストされているすべてのCookieが指定された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エントリに関連するCookieはクライアントと共有されません。 - cookiesキーの文字列配列は空ですが、
profileSharing共有キーがfalseに設定されているため、いずれにしても無視されます。
myWebApp2、リダイレクトベースの認証シナリオ:
-
allowListキーの文字列配列値は、https://myWebApp2.com内のすべてのパスがクライアントにリダイレクトされることを指定します。ただし、denyListキーにリストされている値がある場合は除きます。 -
denyListキーの文字列配列値は、myWebApp2.comドメイン下の/authPortal/で始まるパスがクライアント側のリダイレクトから防止され、サーバー側の認証が実行できるように指定します。 -
profileSharingキーのブール値はtrueに設定されているため、allowListエントリに関連するCookieはクライアントと共有され、シングルサインオンが実行されます。 -
cookiesキーの文字列配列は空であるため、拡張機能はサーバー側認証後に特定のCookieが設定されるのを待たずにクライアントと共有されます。
myWebApp3、フォームベースの認証シナリオ:
-
allowListキーの文字列配列値は、https://myWebApp3.com内のすべてのパスがクライアントにリダイレクトされることを指定します。ただし、denyListキーにリストされている値がある場合は除きます。 -
denyListキーの文字列配列値は、myWebApp3.comドメイン下の/authPortal/で始まるパスがクライアント側のリダイレクトから防止され、サーバー側の認証が実行できるように指定します。 -
profileSharingキーのブール値はtrueに設定されているため、allowListエントリに関連するCookieはクライアントと共有されます。 - 「cookies」キーの文字列配列にはCookie名が含まれているため、拡張機能はサーバー側認証後にこのCookieが設定されるのを待ちます。
allowList内の関連URLのCookieはクライアントと共有され、クライアント側のリダイレクトが発生します。
環境設定
-
deleteClientCacheキーはtrueに設定されているため、BCRクライアントはセキュリティ強化のため、デフォルトでブラウザキャッシュを削除します。このキーが設定されていない場合でも、これがデフォルトの動作です。
BCRポリシーの構成
bcrconfig.jsonを作成したら、JSONファイルの内容を使用するようにBrowser Content Redirection ACL configurationを構成するには、以下の手順に従ってください。
-
ファイルに
.bcrconfig.json拡張子を付けて名前を付けます。例:myrules.bcrconfig.json -
VDAからアクセス可能なWebサーバーにJSONファイルをホストし、URLをメモします。
注：
サーバーはファイルのダウンロードを許可する必要があります。Microsoft IISサイトはデフォルトでJSONファイルのダウンロードを許可しています。
-
Citrix Studioで、ポリシーの下にあるブラウザコンテンツリダイレクトACL構成設定に、前のステップで取得したURLを追加します。
注：
「Browser content redirection ACL configuration」設定の他のエントリは残しておくことができます。競合が発生した場合、BCR拡張機能は
bcrconfig.json設定を優先します。Citrixは、管理の容易さ、アプリケーションレベルの構成、およびスケーラビリティのために、構成全体をJSONに移行することを推奨します。 -
ポリシーを保存し、セッションを起動してポリシー構成をテストします。
注：
ポリシーを設定した後、チューニングのためにホストされている
bcrconfig.jsonファイルをいつでも編集できます。ファイルは、BCR拡張機能を実行しているメインブラウザプロセスが起動または再起動したときにのみ再読み込みされ、変更が適用されます。
注記:
本質的に、ポリシーの観点から、Browser Content Redirectionポリシー（デフォルトで有効）を有効にするだけでよく、JSONファイルを指すURLでBrowser Content Redirection ACL構成ポリシーを構成する必要があります。
JSON構成は現在、以下のポリシーに適用され、それらを柔軟にしますが、残りのポリシーは以前と同じアクションを実行し続けます。
- ブラウザコンテンツリダイレクトACL構成: ACL内のURLは、
allowListキーを介してJSONで構成できるようになりました。- ブラウザコンテンツリダイレクトブロックリスト構成: ブロックリストは、
denyListキーを介してJSONで構成できるようになりました。- ブラウザコンテンツリダイレクト認証サイト: 認証サイトも、
denyListキーを介してJSONで構成できます。