Citrix Cloudおよびオンプレミス環境向けのフェデレーション認証サービス
概要
IT業界では、従来の単一要素認証を超えて、内部リソースへのリモートアクセスを可能にするより優れた認証情報方式によるセキュリティ強化をすでに開始しています。組織は、内部サービスへの安全なアクセスを可能にするために、主にSAML(セキュリティアサーションマークアップ言語)ベースの最新の認証アプローチを採用しています。
最新の認証は、より安全なユーザー認証と承認を提供する ID 管理のフレームワークです。最新の認証を使用してユーザー ID を管理すると、管理者は、より安全な ID 管理システムを提供するさまざまなツールが提供されます。これらの認証方法には、ADFS、Azure Active Directory、Okta、Google 、Ping-Federate、およびその他のサービスが含まれます。これらのメソッドは、従来のパスワードとセキュリティトークンよりも広範な多要素オプション (テキスト、コール、PIN) を提供します。
SAML 認証では、従来の単一要素認証を使用する際のパスワードの弱点を根絶するだけでなく、管理者は、アクセスする必要があるすべてのアプリについて、ユーザーごとに 1 つの資格情報セットを管理できます。ユーザーが組織を離れると、IT 管理者は資格情報セットを 1 つだけ取り消す必要があります。認証情報は、個別のアプリケーションにログインせずに取り消すことができます。
SAMLって何ですか
SAML は、ID プロバイダーとサービスプロバイダー間で認証および承認データを交換するための XML ベースの業界標準のフレームワークです。
SAML プロバイダーを認識するには:
- サービスプロバイダ(SP)は、通常、アプリケーションの形式で、サービスを提供するエンティティです
- ID プロバイダー (IdP) は、ユーザーの認証と承認機能を含む、ユーザー ID を提供するエンティティです。
認証は、ユーザーの ID と資格情報 (パスワード、2 要素認証、多要素) を検証するプロセスです。
認証とは、認証されたユーザーに付与するアクセス権をサービスプロバイダーに通知するプロセスです。
SAML アサーション
SAML アサーションは、ID プロバイダがサービスプロバイダに送信し、ユーザー認証を含む暗号化署名された XML ドキュメントです。SAML アサーションには、次の 3 つの種類があります。
認証-認証アサーションは、ユーザーの識別を証明し、ユーザーがログインした時間と、使用された認証方法(Kerberos、多要素など)を提供します。
属性-アトリビューションアサーションは、SAML ユーザー属性 (UPN などのユーザーに関する情報を提供する特定のデータ) を渡します。
承認決定-認証決定アサーションは、ユーザーがサービスの使用を許可されているか、またはパスワード障害またはサービスに対する権限の欠如のために ID プロバイダが要求を拒否したかどうかを言います。
SAML は、ユーザーがサインインしてサービスにアクセスするための認証方法を完全に変更します。アプリケーションまたはサービスが SAML 経由で認証されるように構成されると、サービスプロバイダと設定された ID プロバイダーの間で認証交換が行われます。認証プロセスは、ユーザーの ID とアクセス許可を確認し、そのユーザーのサービスへのアクセスを許可または拒否します。各 ID プロバイダーとサービスプロバイダーは、SAML 認証を正しく機能させるには、同様かつ正確な設定に同意する必要があります。
SAML が ID プロバイダとサービスプロバイダ間のユーザーのパスワード送信をサポートしていないことを強調することが重要です。SAML は、ID プロバイダーとサービスプロバイダー間でユーザー、ログインアサーション、および属性に関する情報を渡すことによって機能します。ユーザーは、ID プロバイダーを使用して 1 回ログインします。次に、ID プロバイダーは、ユーザーがこれらの内部アプリケーションサービスにアクセスしようとすると、SAML アサーションをサービスプロバイダーに渡します。
フェデレーション認証サービス
最新の認証フレームワークは,Citrix環境に技術的な課題をもたらします。Citrix Workspaceでは、さまざまなアイデンティティプロバイダーを選択できます。同時に、Windows VDAはSAMLをネイティブにサポートしません。Virtual Delivery Agent(VDA)は、ログオン用の認証方法として、ユーザー名/パスワード、Kerberos、および証明書を受け入れます。
SAML認証では、Citrix GatewayとStoreFront はユーザーのパスワードにアクセスできません。SAMLアサーションのみを備えているため、セッションの起動中にVDAへのシングルサインオンを実行することはできません。SAMLトークンを使用すると、VDAへのシングルサインオン(SSO)が切断され、ユーザーに資格情報の入力を求められます。
Citrixでは、仮想スマートカードユーザー証明書を発行してVDAにログオンし、SAML認証を使用するときに、セッション起動中にシングルサインオンを実現するために、フェデレーション認証サービス(FAS)を導入しました。Citrix FASは、Active Directoryおよび証明書サービスと統合され、Active Directory ユーザーの代わりにスマートカードクラス証明書を自動的に発行します。Citrix FASでは、管理者が物理スマートカードをプロビジョニングして仮想スマートカードクラスのユーザー証明書を発行できる同様のAPIを使用します。
Citrix FASは、Workspace/StoreFrontおよびVDAと統合して、SAMLアサーションをユーザー証明書に効果的に交換することです。セッション起動プロセスの一環として挿入された発行された証明書により、VDAへのシングルサインオンを実現し、ユーザーに表示される追加の認証プロンプトを回避できます。Citrix FAS展開は、WindowsとLinux VDAのワークロードの両方でサポートされています。
FAS のインストールと考慮事項
Citrix Cloud Connector
Citrix Cloud展開の場合、Cloud Connector は、リソースの場所(FASサーバーが存在する場所)とCitrix Cloud間の通信を可能にします。リソースの場所ごとに 2 つ以上の Cloud Connector を設定することをお勧めします。クラウドコネクタがそれぞれのリソースの場所で Active Directory ドメインコントローラおよびVirtual Delivery Agentと通信できることを確認します。
FAS サーバー
Citrix FASは、すべての最新のWindowsサーバーバージョンにインストールできます。ただし、Citrix FAS展開は、WindowsとLinux VDAのワークロードの両方でサポートされています。FASサービスは、他のCitrixコンポーネントを含まない専用サーバーにインストールすることをお勧めします。データセンターまたはリソースの場所ごとに 2 台以上の FAS サーバをインストールします。Citrix FASのインストールと構成ドキュメントを参照してください。
スケーラビリティと高可用性については、Citrix FASスケーラビリティとHAドキュメントおよびCitrix KBの記事CTX225721を参照してください。オンプレミスからCitrix Cloudに移行する場合、オンプレミス環境に展開されている既存のFASサーバーを利用し、Cloud Connector経由でCitrix Cloudと通信するように構成できます。
FASサーバーは、Active Directory ドメインコントローラ、証明書サービスと登録機関の証明書、および秘密キーにアクセスする必要があるため、安全な内部ネットワークセグメント内にインストールする必要があります。証明書、ネットワーク、およびその他のセキュリティに関する考慮事項については、詳細な構成ドキュメントを参照してください。
証明書サービス
まだ展開されていない場合は、組織のセキュリティ基準に従って、エンタープライズモードで Microsoft 証明機関 (CA) サービスを設計および展開する必要があります。他のソフトウェアとの相互運用性の問題を回避するために、FASは独自の使用のために3つのCitrix FAS証明書テンプレートを提供しています。証明書テンプレートの1つは、Citrix VDAへのスマートカードログオン用です。他の 2 つの証明書テンプレートは、FAS を認証登録機関として認証することです。これらのテンプレートは、エンタープライズフォレストを管理するアクセス許可を持つ管理者アカウントを使用して、Active Directory に展開および登録する必要があります。
Active Directory
Active Directory には、Server 2012 の機能レベルを使用することをお勧めします。ドメインコントローラは、ドメインコントローラ認証証明書とテンプレートとともにインストールする必要があります (CTX218941)。ドメインコントローラー上の証明書は、スマートカード認証をサポートする必要があります。
Active Directory の展開はそれぞれ別の展開とは異なるため、FAS ソリューションを環境で動作させるには追加の手順が必要になる場合があります。配置に適したアーキテクチャを選択するには、マルチフォレスト選択認証については、Citrix ブログを参照してください。実稼働環境に実装する前に、ラボ環境でソリューションを慎重にテストすることをお勧めします。
3 つの FAS 証明書テンプレートすべてを Active Directory にアップロードし、新しいテンプレートを使用して証明書を発行するように CA サーバーを構成します。証明書テンプレートの1つは、Citrix VDAへのスマートカードログオン用です。他の 2 つの証明書テンプレートは、FAS を認証登録機関として認証することです。
CitrixFASグループポリシーADMXテンプレートをドメインコントローラのポリシー定義フォルダにインストールします。グループポリシーオブジェクト (GPO) を作成し、FAS サーバーの DNS アドレスを使用して GPO を構成します。このGPOは、FASサーバー、StoreFront サーバー、およびそれぞれのドメインを持つすべてのVDAに適用する必要があります。マシンカタログとデリバリーグループを作成する前に、FASグループポリシー構成がStoreFront とVDAに正しく適用されていることを確認します。
GPOリスト内のFASサーバーのDNSアドレスの順序は、すべてのVDA、StoreFront サーバー(存在する場合)、およびFASサーバーで一貫している必要があります。GPOリストは、仮想アプリまたはデスクトップの起動用に選択したFASサーバーを検索するために、VDAによって使用されます。
セッション内証明書サポート
デフォルトで、VDAはログオン後の証明書へのアクセスを許可しません。必要に応じて、グループポリシーテンプレートを使用して、セッション中の証明書用にシステムを構成します。GPOのセッション中証明書オプションは、VDAへのログイン後に証明書を使用可能にするかどうかを制御します。認証後にユーザーが証明書にアクセスする必要がある場合にのみ、このオプションを選択します。
セッション中オプションを選択すると、ログオン後にアプリケーションを使用するために証明書がユーザーの個人証明書ストアに配置されます。たとえば、VDAセッション内のWebサーバーへのTLS認証の場合、証明書はブラウザで使用されます。このオプションが選択されていない場合、証明書はログオンまたは再接続にのみ使用され、ユーザーは認証後に証明書にアクセスできません。
Citrix Delivery Controller
Citrix Delivery Controllerはバージョン7.15以上で、VDAはバージョン7.15以上である必要があります。Delivery ControllerでSet-BrokerSite -TrustRequestsSentToTheXmlServicePort $true
PowerShellコマンドレットを実行して、Delivery Controller とStoreFront サーバー間の信頼を有効にすることが重要です。
Citrix StoreFront
オンプレミス展開では、StoreFront サーバーの最新バージョンをインストールすることを強くお勧めします。StStoreFront サーバーはバージョン3.12以上である必要があります。チケットを要求するStoreFront サーバーと、チケットを使用するVirtual Delivery Agent(VDA)のFAS DNSアドレスの構成が同じであることを確認します。
Citrix FASの概念アーキテクチャ
フェデレーション認証サービス(FAS)は、Microsoft Active Directory および認証局(CA)と統合されるCitrixコンポーネントで、ユーザーはCitrix環境内でシームレスに認証できます。これにより、より快適な代替サインイン方法が提供されるため、ユーザーはVDAセッションの起動時に資格情報を入力する必要がなくなり、シングルサインオンが実現します。
StoreFront 3.6以降のオンプレミス環境では、SAML認証を複数の外部IDプロバイダとともに使用することが可能であり、Citrix FASと統合され、ユーザーはCitrix Gatewayから、またはStoreFront 経由で直接認証できます。
シトリックスは、2020年6月にCitrix Cloudとのフェデレーション認証サービスのパブリックGAリリースを達成しました。Citrix FASは、Azure ADやOkta アイデンティティプロバイダーなどのフェデレーションアイデンティティプロバイダーを使用する場合に、Citrix Workspaceで完全にサポートされ、VDAへのシングルサインオンを実現しました。
オンプレミス展開用のCitrix FAS
オンプレミス環境でのCitrix FAS展開の概念アーキテクチャは次のとおりです。ここでは、この展開の各レイヤーの設計フレームワークを確認して、組織に完全なソリューションを提供する方法について理解しましょう。
ユーザーレイヤー:ユーザーは、Citrix Workspaceアプリまたはブラウザを使用してCitrix Gateway経由でCitrix環境にアクセスします。Citrix Workspace アプリは、Windows、Mac、Android、iOSで利用できます。外部ユーザーは、Web ブラウザーから HTML5 バージョンの Workspace アプリを使用することもできます。Web ブラウザーでは、デバイスに Workspace アプリをインストールできません。
アクセスレイヤー:このレイヤーでは、Citrix GatewayとStoreFront の展開について説明します。リモートユーザーにアクセスできるようにCitrix GatewayをDMZネットワークに展開し、StoreFront サーバーを社内ネットワーク内に展開して内部ユーザー向けに展開します。Citrix管理者がCitrix GatewayでSAML認証ポリシーを構成しました。
StoreFront ストアでフェデレーション認証サービスの統合を有効にするには、作成された新しいストアで、PowerShellコマンドレットを管理者アカウントとして実行します。ユーザーがStoreFront 経由でアクセスしていて、ゲートウェイが関与していない場合は、この手順が必要です。PowerShell コマンドレットの詳細については、Citrixドキュメントを参照してください。VDAログオンプロバイダ設定を構成すると、StoreFront はFASから証明書を要求し、VDAへの認証のためにセッション起動時にVDAから証明書を取得するように指示します。構成が完了すると、この構成は、そのストアに対するすべてのセッション起動に適用されます。
Citrix Gatewayを使用する場合は、Citrix GatewayとコールバックURLの詳細を使用してStoreFront を構成します。これは、ログオン証拠がコールバックを介して転送されるためです。ログオンタイプを「スマートカード」として構成すると、ネイティブクライアントが SAML 認証を実行するのに役立ちます。[認証情報の検証をGatewayに完全に委任する]設定では、StoreFront サーバーでユーザー認証をGatewayに委任できます。これにより、Citrix GatewayからのパススルーSAML認証が可能になります。IT管理者は、信頼されたFASサーバーリストを含むFASグループポリシーオブジェクトを作成し、FASサーバー、VDA、StoreFront サーバーがADドメインに存在するOUに適用されます。
SAML 認証を使用する場合、実際の認証は ID プロバイダーで行われます。SAML アイデンティティプロバイダーは、ADFS、Azure AD、Okta、Google 、または Ping アイデンティティなどの何でもかまいません。Active Directory フェデレーションサービス (ADFS) を ID プロバイダーとして、この概念的なアーキテクチャに移行すると考えてみましょう。
ADFS は、セキュリティで保護されたエンタープライズおよびフェデレーションパートナー組織内のアプリケーションにアクセスしたいエンドユーザーが、シンプルかつセキュリティで保護された ID フェデレーションおよびシングルサインオン (SSO) 機能を提供します。ADFS は、組織の Active Directory ドメインおよび証明書サービスと緊密に統合されています。
これからは、SAMLサービスプロバイダがCitrix GatewayまたはStoreFront であることが示されます。SAML ID プロバイダーは、ドメイン上に存在し、認証のために内部ネットワークと外部ネットワークの両方からアクセスするように構成された Microsoft ADFS です。
すべてのレイヤーの最後に FAS 認証ワークフローと一緒にリソースの列挙とセッション起動プロセスについて説明します。
制御層:配信コントローラ、SQL データベース、Studio、およびライセンスは、制御層で展開および管理されるコアコンポーネントです。管理者は、仮想マシンをプロビジョニングおよび管理するためにハイパーバイザーと通信するようにホスト接続を構成しました。マシンカタログとデリバリーグループが作成され、Citrix Studio を使用して必要なユーザーグループへのアクセスが有効になります。Citrix Directorは、管理者がCitrix環境全体を監視するのに役立ちます。
Citrix FAS展開の場合は、Delivery Controller で、StStoreFront サーバーから送信されたXML要求を信頼する trustRequestSsSentTexmlServicePort を「true」に設定します。これにより、「パススルー」認証、およびCitrix Gateway経由でルーティングされる接続がサポートされます。StoreFront サーバーは、XMLを使用してDelivery Controller と通信し、認証されたユーザーのリソースを列挙します。ユーザーには、資格が付与されているアプリとデスクトップを一覧表示するStoreFront ページが表示されます。
リソース層:リソース層は,Citrix環境内のすべてのユーザーワークロード(VDA)が存在する場所です。Citrix Studio 助けを借りて、マスターイメージテンプレートを使用して、管理者はWindows Server OSを使用して仮想アプリサーバーを展開しました。管理者は、Citrix Provisioning(PVS)を使用して、タスクワーカー用のサーバーVDAを作成しました。管理者は、マシン作成サービス(MCS)を使用して、パワーワーカーには Windows 10 を使用して仮想デスクトップを、Linux ユーザーには Red Hat Enterprise ディストリビューションを使用して仮想デスクトップをハイパーバイザーにデプロイしました。
これらの仮想マシンとともにインストールされた仮想デリバリーエージェントは、Delivery Controllerに登録されます。管理者は、デスクトップとアプリを使用してマシンカタログとDelivery Controllerを作成し、ADセキュリティグループを使用するユーザーのアクセスを可能にします。Citrix HDXポリシーは、デリバリーグループのCitrix Studio を使用して作成および割り当てられ、HDX接続を最適化および保護します。
Citrix FAS展開の場合、ネットワーク管理者は、セッション起動時にユーザー証明書を取得するためにCitrix FASサーバーと通信するようにVDAのファイアウォールルールを構成しています。Citrix管理者は、信頼されたFASサーバーを含むグループポリシーが、VDAとStoreFront サーバーがADに存在するActive Directory OUにリンクされ、有効になっていることを確認しました。
Platform Layer:この層では、オンプレミス展開の制御層コンポーネントとユーザーワークロードをホストするために必要なハードウェアプラットフォームについて説明します。Citrix管理者は、サーバーハードウェアにハイパーバイザーソフトウェアをインストールし、制御インフラストラクチャとユーザーワークロードに必要な仮想マシンを展開しました。ネットワーク管理者は、環境内のすべてのCitrixコンポーネントのファイアウォールルールを有効にして相互に通信します。ストレージ管理者は、Citrix環境への適切なストレージの構成と割り当てを支援しました。
操作層:この概念的な展開のために、私たちは操作層の下のFASサーバーの展開に焦点を当ててみましょう。
Citrix FASサーバーの展開では、Citrix管理者がハイパーバイザー上に2つの新しいWindows仮想マシンを展開し、FASコンポーネントをインストールしました。FAS 管理コンソールは、FAS インストールの一部としてインストールされます。管理コンソールの初回使用時は、証明書テンプレートの展開、証明機関のセットアップ、およびFASへの証明機関の使用権限の付与を行う手順が表示されます。
認証局の横に移動すると、FASは、Windows認証局に固有の DCOM 呼び出しを使用します。サードパーティまたは公共の認証局は使用できません。FASコンソール内で複数のCAの詳細を指定することで、高可用性を実現できます。中央認証局は、フォレスト間の登録を介して複数のドメインをサポートできます。同じ行に沿って、StoreFront、FAS、およびVDAはすべてKerberos経由で相互に認証されるため、同じドメインまたはドメイン間で双方向の信頼関係を持つドメインに存在する必要があります。
また、StoreFront の指示に従って、VDAログオンおよびセッション内使用のための証明書の発行を許可するユーザールールを構成する必要があります。各ルールでは、証明書の要求を信頼するStoreFrontサーバー、証明書を要求できる一連のユーザー、および証明書の使用を許可する一連のVDAマシンを指定します。詳細については、Citrixドキュメントを参照してください。
FASには、FASがドメインユーザーの代わりに自律的に証明書を発行できるようにする、登録機関の証明書があります。そのため、FASサーバーを保護し、アクセス許可を制限するために、セキュリティポリシーを開発して実装することが重要です。
セッションの起動時に、ユーザー証明書の生成は、プロセスの最も高価な部分です。FASは、ユーザーの新しい証明書を動的に生成する必要があります。ログオンプロセスを少し拡張し、FASサーバーのCPU負荷を増やすことができます。ただし、FASサーバーは、明示的なパスワード認証を使用する場合とほぼ同じ速さでユーザーがログインできる証明書をキャッシュできます。FASサーバー内でユーザー証明書が事前に生成されると、ユーザーのログイン時間が大幅に短縮されます。従う詳細な手順については、Citrix ドキュメントを参照してください。
Citrix FASでのセッション起動プロセス
Citrix GatewayおよびStoreFront でVDAへのFASを使用する場合の認証フローについて説明します。
ユーザーがCitrix Gateway(サービスプロバイダー)にログオンすると、SAMLログイン要求を生成して応答し、ADFS(アイデンティティプロバイダー)ログインページにリダイレクトします。ユーザーは、[ADFS シングルサインオン] ページで資格情報を入力します。ADFS は Active Directory を使用してユーザーを認証し、SAML 要求を SAML 応答として解析します。サービスプロバイダー(Citrix Gateway)に引き渡された署名付きトークンを含むエンコードされたSAMLレスポンス。
Citrix Gatewayは、IdP証明書を使用してSAMLレスポンスを検証します。SAML アサーションを抽出して、ユーザーの ID (ユーザープリンシパル名) とアクセスを許可する承認を調べます。その後、StoreFront に渡され、検証とリソースの列挙が行われます。StoreFront サーバーは、コールバックURL構成を使用する信頼されたゲートウェイを使用してアサーションを再度検証および検証します。FASログオン証拠機能は、Citrix Gateway およびStoreFront によってFASに渡されるログオン証拠を提供します。FASは、トークンが信頼できるアイデンティティプロバイダ(IdP)によって発行されたことを確認するために、証拠を検証することができます。ログオン証拠の詳細については、シトリックスのドキュメントを参照してください。
これで、StoreFrontのログオンデータプロバイダサービスがフェデレーション認証サービスにアクセスし、認証されたユーザーの証明書を生成するように要求されます。FAS は Active Directory に接続してユーザーを確認し、Active Directory 証明書サービス (ADCS) に話しかけ、ユーザーの証明書要求を送信します。
認証局は、認証されたユーザーに有効な証明書を発行します。FASは、ユーザー証明書とその属性を保持します。この証明書はStoreFront では共有されません。ただし、StoreFront はユーザーが有効であることを認識し、FASはこの認証ユーザーの証明書を登録しました。
これで、StoreFront サーバーはXMLを使用してDelivery Controller と通信し、認証されたユーザーのリソースを列挙します。ユーザーには、資格が与えられているすべてのアプリとデスクトップを一覧表示するStoreFront ページが表示されます。
ユーザーがワークスペースアプリで仮想アプリまたはデスクトップを起動すると、要求がStoreFront に送信され、ICAファイルが取得されます。StoreFront はDelivery Controllerに連絡し、このセッションのVDAの詳細を要求します。配信コントローラはリクエストを検証し、VDAを選択します。VDAはこのユーザーセッションを受け取り、VDAとSecure Ticket Authority(STA)の詳細をStoreFront と共有してICAファイルを生成できます。さらに、StoreFront サーバーはGPOリストからFASサーバーを選択し、選択したFASサーバーに接続して、ユーザー証明書へのアクセスを許可するチケットを取得します。このチケットはFASサーバーに保存されています。StoreFront は、このFASトークンをICAファイルに追加し、ワークスペースアプリに送り返します。
Workspaceアプリは、VDAとの通信を検証および許可するためのSTAチケットを提供することにより、Citrix Gatewayとの起動セッションを確立します。STAチケットはDelivery Controllerで検証され、セッションを起動するためにVDAに渡されます。FASチケットは、この期間中にVDAとともに提示され、FASサーバーで検証されます。VDA資格情報プラグインは、GPOリストから選択したFASサーバーにアクセスします。FASサーバーはトークンを検証し、有効なユーザー証明書を発行します。ユーザー証明書の検証に成功すると、シングルサインオンが実行され、VDAセッションが起動され、ユーザーに提示されます。
Citrix Cloud展開のためのCitrix FAS
Citrix Cloud環境を使用したFAS展開の概念アーキテクチャを以下に示します。各レイヤーの設計フレームワークと、この展開のFASワークフローを確認して、組織に完全なソリューションがどのように提供されているかを理解しましょう。
ユーザーレイヤー:ユーザーは、Citrix Cloudのサブスクライバーとも呼ばれ、クラウドワークスペースURLを使用してCitrix環境にアクセスできます。ユーザーは、エンドポイントにインストールされているブラウザーまたはワークスペースアプリから接続するために、Citrix CloudからWorkspace URLが提供されます。
アクセスレイヤー:Citrix WorkspaceまたはGateway Serviceは、ユーザーがCitrix環境にアクセスするためのフロントエンドまたはエントリポイントです。管理者は、クラウドポータルを使用してワークスペースの URL と認証オプションを変更できます。クラウドコネクタをインストールすると、お客様のActive Directory ドメインをCitrix Cloudに拡張できます。ワークスペースの認証構成により、管理者はユーザーがサインインしてCitrixリソースにアクセスするための認証ソースを選択できます。
Microsoft Azure Active Directory (AAD) を、この概念アーキテクチャに移行するための認証ソースとして考えてみましょう。Citrix Cloudには、お客様がCitrix CloudサブスクリプションをAzure ADに接続できるAzure ADアプリが含まれています。Azure Active Directory をCitrix Cloud に接続する方法の詳細については、『シトリックスのドキュメント』を参照してください。Azure AD認証を有効にした場合、ユーザーとグループへのアクセスを提供するには、Citrix Cloudのライブラリを使用して管理する必要があります。
ワークスペース認証構成ページは、新しいオプション「フェデレーション認証サービスによる認証の構成」で有効になっています。FAS はデフォルトで無効になっています。管理者は、「FASを有効にする」ボタンを使用して、FAS認証を有効にします。
ユーザーがワークスペース URL を使用して環境にアクセスし始めると、ユーザーは構成に基づいて対応する ID プロバイダーにリダイレクトされます。この場合、ユーザーは Azure が提供するサインインページにリダイレクトされます。ユーザーが有効なAzure AD資格情報を入力すると、ブラウザーがCitrix Workspaceにリダイレクトされ、リソースページが表示され、ユーザーに割り当てられている[アプリとデスクトップ]が表示されます。
セッション起動プロセスとFAS認証ワークフローについては,すべてのレイヤーの最後に説明します。
制御層:Citrix Cloud環境では、Delivery Controller、SQLデータベース、Studio、Director、およびライセンスは、Virtual Apps and Desktops サービスのアクティブ化中にクラウド上に展開される制御層のコアコンポーネントです。管理者は、オンプレミスのハイパーバイザーと通信するように、リソースの場所とホスティング接続を構成しました。マシンカタログはCloud Studio ポータルを使用して作成され、Citrix Directorは環境の監視に役立ちます。
管理者がCitrix WorkspaceでFAS認証を有効にすると、Citrix Cloud上の追加のFAS µサービスがオンプレミスFASサーバーと通信できるようになります。クラウドFAS µ-serviceをアウトバウンド SSL 接続経由で接続するリソースの場所にデプロイされた FAS サーバー。
リソースレイヤー:このレイヤーは、この展開内のすべてのユーザーワークロードが存在するリソースの場所を参照します。管理者は、オンプレミスのユーザーワークロードとCitrix Cloudを統合するための開始点として、Citrix Cloud Connectorをインストールしました。これにより、オンプレミスのコンポーネントとCitrix Cloudサービス間の通信が可能になります。
リソースの場所にインストールされたVDAは、クラウドデリバリーコントローラに登録されます。管理者は、マシンカタログとデリバリーグループを作成します。Citrix HDXポリシーは、デリバリーグループのCitrix Studio を使用して作成および割り当てられ、HDX接続を最適化および保護します。
プラットフォーム層:この層は、ユーザーのワークロードとリソースの場所に必要な他のコンポーネントをホストするために必要なハードウェアプラットフォームについて説明します。Citrix管理者は、サーバーハードウェアにハイパーバイザーソフトウェアをインストールし、ユーザーワークロードやFASサーバーなどのコンポーネントに必要な仮想マシンを展開しました。ネットワーク管理者は、環境内のすべてのCitrixコンポーネントのファイアウォールルールを有効にして相互に通信します。ストレージ管理者は、Citrix環境への適切なストレージの構成と割り当てを支援しました。
操作レイヤー:ユーザーワークロードを管理するために必要なファイルサーバー、Citrix WEMサーバー、RDSライセンスサーバー、Citrix App Layering サーバー、FASサーバーなどのツールとコンポーネントについては、オペレーションレイヤーで説明しています。
管理者は、ファイルサーバークラスターとワークスペース環境マネージャーサービスを展開して、VDAのユーザープロファイルを構成しました。IT 管理者は、ユーザープロファイルとフォルダーリダイレクト用の専用のファイル共有と NFS 共有を作成しました。Citrix管理者は、リソース管理ポリシーを適用して、VDAエージェントのCPUとメモリ使用率を最適化しました。IT 管理者は、リモートデスクトップサービス (RDS) クライアントアクセスライセンスサーバーを構成して、仮想アプリワークロードの RDS ライセンスを発行します。
Active Directory ユーザーとグループを Azure AD と同期するために、管理者は必要な数の Azure AD 接続サーバーをインストールし、Azure サブスクリプションで構成します。Citrix FAS展開の場合、Citrix管理者は2つの新しいWindows仮想マシンを展開し、インストールプロセスに従ってCitrix FASサービスをインストールおよび構成しました。
管理者特権を持つ FAS 管理コンソールを使用して、管理者は FAS サーバーを構成し、証明書テンプレートの展開、認証局の設定、FAS 認証局の使用を許可するプロセスを通じて構成しました。詳細な手順については、シトリックスのドキュメントを参照してください。
また、VDAログオン用の証明書の発行を許可するユーザールールを構成する必要があります。各ルールでは、証明書の要求を信頼するStoreFrontサーバー、証明書を要求できる一連のユーザー、および証明書の使用を許可する一連のVDAマシンを指定します。ただし、Citrix Cloudでルールが使用される場合、StoreFrontのアクセス許可は無視されます。既存のFASサーバーを使用している場合、FASインストーラは既存のセットアップを検出し、これらのオプションの横に緑色のマークを付けます。
Citrix CloudおよびオンプレミスのStoreFront 展開でも同じルールを使用できます。オンプレミスのStoreFront でルールが使用されている場合でも、StoreFront のアクセス許可は引き続き適用されます。詳細については、Citrixドキュメントを参照してください。詳細については、を参照してください。
CitrixFASグループポリシーADMXテンプレートをドメインコントローラのポリシー定義フォルダにインストールします。FASサーバーのDNSアドレスを使用してGPOを作成し、構成します。このGPOは、FASサーバー、StoreFront サーバー、およびそれぞれのドメインを持つすべてのVDAに適用する必要があります。マシンカタログとデリバリーグループを作成する前に、FASグループポリシー構成がStoreFront とVDAに正しく適用されていることを確認します。
Citrix Cloud上でFASサーバーを構成し、オンプレミスのFASサーバーとCitrix Cloudを接続する最後の手順として、管理者は「Citrix Cloudに接続」オプションを選択しました。Citrix Cloudでサインインすると、管理者は顧客アカウントとリソースの場所を選択します。これで、Citrix CloudはFASサーバーを登録し、[リソースの場所]ページに表示します。
Citrix CloudでCitrix FASを使用する場合のセッション起動プロセス
ユーザーが Workspace URL を使用して環境にアクセスし始めると、ユーザーは Azure ベースのサインインページにリダイレクトされます。ユーザーは、Azure シングルサインオンページで有効な Azure 資格情報を入力します。Azure はユーザーを認証し、ユーザーをCitrix Workspaceページにリダイレクトします。Citrix Workspaceがリソースを列挙し、リソースページにユーザーに提示しました。
ユーザーがワークスペースで仮想アプリケーションまたはデスクトップを起動すると、ICAファイルの取得要求が送信されます。コントローラは、リソースの場所から使用可能なVDAを選択します。Citrix Cloudは、VDAと同じリソースの場所にあるFASサーバーを選択し、認証局から提供されたユーザー証明書を使用してVDAへのアクセスを許可するチケットを取得します。このチケットはFASサーバーに保存されています。Citrix WorkspaceはこのFASトークンをICAファイルに追加し、ユーザーシステムに返送します。
Workspaceアプリは、ICAファイルを使用してVDAへの接続を確立し、加入者を認証するために、VDAはFASに接続してチケットを提示します。VDA資格情報プラグインはFASサーバーに接続し、トークンを検証します。これで、FASサーバーは有効なユーザー証明書をVDAに提供します。ユーザー証明書の検証に成功すると、シングルサインオンが実行され、そのユーザーのVDAセッションが開始されます。
ユースケース #1
Citrix Service Provider(CSP)は、複数のお客様がアクセスできるようにするハイブリッドCitrix Virtual Apps and Desktops 環境を設計します。将来の成長を考慮すると、CSP は、より多くの新規顧客のオンボーディングも検討する必要があります。設計仕様では、顧客ごとに異なる ID プロバイダを提供することを提案し、ドメインの信頼を作成することを回避します。
Citrixサービスプロバイダは,お客様のCitrix和Deskt虚拟应用程序ops 環境に頻繁にオンボードし、このソリューションでは、Citrix GatewayではUPNサフィックスに基づいて異なるSAML IDプロバイダを選択的に提供する必要がありました。たとえば、顧客 A は Azure AD を使用するように構成され、顧客 B は Active Directory フェデレーションサービス (ADFS) を使用するように構成されています。お客様ごとに異なるIDプロバイダを構成するには、Citrix FASを使用してCitrix VDAへのシングルサインオンを提供する必要がありました。
Citrix ブログを参照してください。このドキュメントには、環境を設定するための詳細な手順が記載されています。各顧客のワークフローとセッション起動プロセスについて説明します。重要な構成は、Citrix ADC AAA、nFactor、およびCitrix Gatewayセッションポリシーを使用して、Citrix Gatewayで発生し、複数のユーザーの要求に対応します。
ユーザーがCitrix Gateway(サービスプロバイダー)にログインすると、そのユーザーはUPNサフィックスに基づいて識別され、各IDプロバイダーのログインページにリダイレクトされます。ユーザーが認証情報を入力すると、ID プロバイダーはユーザーを認証し、応答として SAML トークンで応答します。署名付きトークンを含むエンコードされたSAML応答は、サービスプロバイダーのCitrix Gatewayに引き渡されます。ここでは、トークンを検証するためにアイデンティティプロバイダーのルートCA証明書がインストールされています。
Citrix Gatewayは、IdP証明書を使用してSAMLレスポンスを検証します。SAML アサーションを抽出して、ユーザーの ID (ユーザープリンシパル名) とアクセスを許可する承認を調べます。その後、StoreFront に渡され、検証とリソースの列挙が行われます。
これで、StoreFrontのログオンデータプロバイダサービスがフェデレーション認証サービスにアクセスし、認証されたユーザーの証明書を生成するように要求されます。FASは、Active Directory に接続して、ユーザーとそのシャドウアカウントを確認します。次に、Active Directory 証明書サービス (AD CS) に話しかけ、ユーザーに証明書要求を送信します。認証局は、認証されたユーザーに有効な証明書を発行します。
ユーザーがワークスペースアプリで仮想アプリまたはデスクトップを起動すると、要求がStoreFront に送信され、ICAファイルが取得されます。StoreFront はリクエストを検証し、このセッションのVDAの詳細を配信コントローラに問い合わせます。デリバリーコントローラーはリクエストを検証し、VDAおよびSecure Ticket Authority(STA)の詳細をStoreFront と共有してICAファイルを生成します。さらに、StoreFront サーバーはGPOリストからFASサーバーを選択し、選択したFASサーバーに接続して、ユーザー証明書へのアクセスを許可するチケットを取得します。このチケットはFASサーバーに保存されています。StoreFront は、このFASトークンをICAファイルに追加し、ワークスペースアプリに送り返します。
ワークスペースアプリは,通信を検証して許可するためのSTAチケットを提供することにより,CitrixGatewayとのセッションを開始するための接続を開始します。検証時に、セッションを起動するために接続がVDAに渡されます。FASチケットは認証時にVDAとともに提示され、FASサーバーに対して検証されます。VDA資格情報プラグインは、GPOリストから選択したFASサーバーにアクセスします。FASサーバーはトークンを検証し、有効なユーザー証明書を発行します。ユーザー証明書の検証に成功すると、シングルサインオンが実行され、VDAセッションが開始されます。
ユースケース #2
会社Aは最近、Company-Bを買収しました。そのため、会社Aは、既存のCitrix Virtual Apps and Desktops 環境で、Company-B社の従業員にアクセス権を付与したいと考えていました。両方の会社ドメイン間の認証を簡素化するために、管理者は Azure Active Directory などの外部 SAML ID プロバイダーソリューションを実装して、ドメイン間のフェデレーション接続を確立しました。SAML 認証により、ユーザーは他の会社の AD 環境にシームレスにログインして、リソースにアクセスできます。どちらの会社でも、ユーザーは会社固有の資格情報を使用できます。この場合、シャドウアカウントを使用して、Company-A でマッピングされ、リソースにアクセスできます。
Citrix VDAにログインするには、すべてのユーザーがVDAによって信頼されるドメインにActive Directory アカウントを持っている必要があります。フェデレーションユーザーの場合、Company-A ドメイン内の各フェデレーティッドユーザー (Company-B) のシャドウアカウントを作成する必要があります。これらのシャドウアカウントには、SAML IdP によって提供される SAML 属性 (通常は電子メールアドレス) に一致する UPN が必要です。SAML IdP によって提供される電子メールアドレスが会社ドメインの UPN サフィックスと一致しない場合は、Active Directory ドメインと信頼スナップインの SAML IdP によって提供される電子メールサフィックスに一致する UPN サフィックスを追加する必要があります。
Company-B ユーザーはゲートウェイ URL にアクセスし、ユーザーは SAML ID プロバイダーにリダイレクトされます。この場合、Azure Active Directory です。企業 A ドメインと企業 B ドメインの両方が単一の Azure AD テナントに同期されました。
ユーザーは、AAD に対して認証するために Company-B 資格情報を入力し、SAML トークンを使用してゲートウェイにリダイレクトし直します。
ゲートウェイは SAML トークンを解析し、この SAML トークンを使用して、シャドウアカウントを使用してユーザーの身元を確認します。その後、リソース列挙のためにStoreFront に渡されます。
これで、StoreFrontのログオンデータプロバイダーサービスがフェデレーション認証サービスにアクセスし、認証されたシャドウアカウントユーザーの証明書を生成するように要求します。FASはActive Directory に接続して、ユーザー(シャドウアカウント)を確認します。次に、Active Directory 証明書サービス (AD CS) に話しかけ、ユーザーに証明書要求を送信します。認証局は、認証されたユーザーに有効な証明書を発行します。
StoreFront によってリソースページが作成され、ユーザーに返送されます。
ユーザーがワークスペースアプリで仮想アプリまたはデスクトップを起動すると、要求がStoreFront に送信され、ICAファイルが取得されます。StoreFront はリクエストを検証し、このセッションのVDAの詳細を配信コントローラに問い合わせます。デリバリーコントローラーはリクエストを検証し、VDAおよびSecure Ticket Authority(STA)の詳細をStoreFront と共有してICAファイルを生成します。さらに、StoreFront サーバーはGPOリストからFASサーバーを選択し、選択したFASサーバーに接続して、ユーザー証明書へのアクセスを許可するチケットを取得します。このチケットはFASサーバーに保存されています。StoreFront は、このFASトークンをICAファイルに追加し、ワークスペースアプリに送り返します。
ワークスペースアプリは,通信を検証して許可するためのSTAチケットを提供することにより,CitrixGatewayとのセッションを開始するための接続を開始します。検証時に、セッションを起動するために接続がVDAに渡されます。FASチケットは認証時にVDAとともに提示され、FASサーバーに対して検証されます。VDA資格情報プラグインは、GPOリストから選択したFASサーバーにアクセスします。FASサーバーはトークンを検証し、有効なユーザー証明書を発行します。ユーザー証明書の検証に成功すると、シングルサインオンが実行され、VDAセッションが開始されます。
ユースケース #3
既存のエンタープライズCitrixのお客様は、技術更新およびアップグレード計画の一環として、既存のレガシーCitrix環境を移行したいと考えています。移行計画では、Citrix環境の制御インフラストラクチャをCitrix Cloudに移動する必要があります。ユーザーワークロードをデプロイするために、ユーザーはリージョナルデータセンターと Azure Cloud で利用可能な既存のハードウェアを利用することを計画しました。これにより、ユーザー管理とリソース割り当ての改善に役立ちます。また、お客様は、各地域のデータセンターに展開されている既存のCitrix Gatewayを利用して、HDX接続を最適化することを選択しました。最後に、認証のために、顧客は、Azure Active Directory ドメインサービスへのドメインコントローラを移行する予定として、Azure Active Directory を使用することを選択しました。
移行計画によると、ドメイン管理者は、ユーザーとグループを Azure Active Directory と同期し、Azure AD ドメインサービスと同期するように AD 接続をインストールおよび構成しました。お客様はCitrix Cloudサブスクリプションを購入しました。したがって、制御インフラストラクチャコンポーネントは、Citrixによって展開および管理されます。Citrix Adminは、ユーザーの認証方法としてAzure ADを構成し、各リージョンのデータセンターにCloud Connectorをインストールしてリソースの場所を作成しました。
各リージョンにインストールされている既存のCitrix网关を利用するために,管理者はCitrix Cloudで「Gateway」オプションを構成し、オンプレミスのゲートウェイをポイントします。これにより、オンプレミスのゲートウェイ経由でユーザーのHDX接続を起動できます。管理者は、必要なユーザーワークロードを各データセンターの既存のハードウェアに展開し、VDAはCitrix Cloudコントローラーに登録されました。ドメイン管理者は、Citrixリソースへのユーザープロビジョニング用のリージョンワイズ AD セキュリティグループを作成しました。Citrix管理者は、リージョン固有のADセキュリティグループを使用して、Citrix Cloudポータルのライブラリページのリソースへのアクセスを有効にしました。これにより、ユーザーは同じリージョンから公開デスクトップおよびアプリケーションにアクセスできます。
Citrix Workspaceで認証にAzure ADを使用するときにVDAへのシングルサインオンを実現するために、お客様はCitrix FASソリューションを使用することにしました。Citrix管理者は、必要な数のFASサーバーをインストールし、Citrix Cloudの各リソースの場所でCitrix Cloud FASサービスと通信するように構成しました。各リージョンへのFASサーバーのリストを含むグループポリシーは、OUレベルでリンクされているため、VDAは同じデータセンターからFASサーバーのリストを取得します。
では、ユーザーのセッション起動ワークフローを見てみましょう。
ユーザーが Workspace URL を使用して環境にアクセスし始めると、ユーザーは Azure ベースのサインインページにリダイレクトされます。ユーザーは、Azure シングルサインオンページで有効な Azure 資格情報を入力します。Azure はユーザーを認証し、ユーザーをCitrix Workspaceにリダイレクトします。
Citrix Workspaceがクラウドコントローラに接続して、ユーザーに割り当てられたリソースを列挙し、ユーザーに提示します。
ユーザーは Workspace で仮想アプリケーションまたはデスクトップを起動し、ICAファイルを取得するための要求が送信されます。Cloud Controllerは、リソースがこのユーザーにマップされているリソースの場所から、使用可能なVDAを選択します。Citrix Cloudは、同じリソースの場所にあるFASサーバーを選択して、VDAへのアクセスを許可するチケットを取得します。FASサーバーは、認証局からユーザー証明書を要求しています。認証局は、FASサーバーに保存されています。Citrix WorkspaceはこのFASトークンとCloud Connector をSTAとしてICAファイルに追加し、ユーザーシステムに送り返します。
ワークスペースアプリはICAファイルを解析し、VDAへのHDX接続のためにオンプレミスのゲートウェイへの接続を確立します。
Citrix GatewayはCloud Connector でSTAチケットを使用して接続を検証し、接続をVDAに渡します。
ユーザーを認証するために、VDAはGPOリストからFASサーバーに接続します。VDA資格情報プラグインはFASサーバーに接続し、トークンを検証します。これで、FASサーバーは有効なユーザー証明書をVDAに提供します。
ユーザー証明書の検証に成功すると、シングルサインオンが実行され、そのユーザーのVDAセッションが開始されます。
ユースケース #4
新しいCitrixのお客様は、Citrix Virtual Apps環境を展開して、イントラネットポータルやExchangeメールボックスなど、インターネット経由で公開されない内部リソースへのアクセスを可能にしたいと考えています。環境の高可用性を確保するために、お客様は、アクティブ/アクティブ設計の 2 つの場所に環境を展開することを選択しました。重要なサーバは、コンポーネントレベルでの障害を回避するために、各場所で冗長として利用できます。お客様は、多要素認証にMicrosoft 365を使用し、認証にはCitrix環境で条件付きアクセスを希望しています。お客様の主な目標は、データセンターから仮想アプリケーションにアクセスできるユーザーにアクセスできるようにすることです。
設計に従って、お客様は、StoreFront サーバー3台、Delivery Controller×3、常時稼働SQLサーバー、3台のPVSサーバー、ライセンス、およびDirectorサーバーで構成される各場所に専用のXenDesktop(Virtual Apps and Desktops)サイトを展開しました。各場所には、GSLB、ゲートウェイ、およびロードバランサ用のCitrix ADC ペア構成があります。お客様は Azure AD 認証の使用を希望しているため、各場所に一組の Citrix FAS サーバーを展開する必要があります。
環境は、設計と顧客の要件に従って構成されました。
グローバルサーバー負荷分散 (GSLB) がサイト間で構成され、ユーザーの負荷分散と利用可能なサイトへのルーティングが行われます。
StoreFront サーバーは、Citrix ADCゲートウェイを使用して負荷分散されます。
StoreFront サーバーは、両方の場所のデリバリーコントローラーと通信するように構成されているため、ユーザーはデータセンター1または2のリソースにアクセスできます。
証明書要求プロセスを最適化するために、StoreFront サーバーのGPOをローカルデータセンター内のFASサーバーのみを指すように構成することをお勧めします。
StoreFront が両方のデータセンターからのリソースを列挙するこの顧客環境では、両方のデータセンターのすべてのFASサーバーを認識するようにVDAを構成する必要があります。VDAは、StoreFront から要求を受信したFASサーバー(別のデータセンターにある場合があります)から証明書を取得できます。StoreFront サーバーは、同じデータセンター内の2つのFASサーバーとのみ通信します。次の図に示すように、FASサーバーを一覧表示するGPOポリシーでは、空白を使用して、StoreFront サーバーがFASサーバーの一覧を正しいインデックスにフェッチするようにします。
これを構成するときは、GPO の「インデックス」アライメントを考慮する必要があります。StoreFront とVDAのFASサーバーの一覧は、Delivery Controllerの一覧と同様に、アライメントする必要があります。VDAは、認識していないDelivery Controller からの起動要求を受け付けません。
Citrix FASを使用すると、VDAはリストされたFASサーバーから証明書を取得できます。さらに考慮すべき点は、StoreFront とVDAレジストリ内のFASサーバーの順序が一致する必要があることです。これは、FASサーバーには、レジストリにリストされている順序に基づいてインデックス番号が割り当てられるためです。StoreFrontとVDAの間でインデックスが一致するようにするために、StoreFront サーバーグループに適用されるレジストリ/ポリシーの空白のエントリを残す必要がある場合があります。
では、ユーザーのセッション起動ワークフローを見てみましょう。
ユーザーが環境へのアクセスを開始すると、ユーザー要求は GSLB ADNS に基づいて Datacenter-1 または Datacenter-2 のいずれかにランされます。
ゲートウェイは、Azure ベースのサインインページにユーザーをリダイレクトします。ユーザーは、Azure シングルサインオンページで有効な Azure 資格情報を入力します。Azure はユーザーを認証し、ユーザーを Gateway にリダイレクトします。
Citrix GatewayはStoreFront サーバーに接続し、ユーザーに割り当てられたリソースを列挙し、ユーザーに提示します。
ユーザーが仮想アプリケーションを起動し、ICAファイルを取得するための要求が送信されます。StoreFront はDelivery Controllerに接続し、ユーザーがリソースにアクセスするためにマップしたデリバリーグループから使用可能なVDAを選択します。StoreFront は、GPOを介して同じ場所にあるFASサーバーを選択し、VDAへのアクセスを許可するチケットを取得します。FASサーバーは、認証局からユーザー証明書を要求しています。認証局は、FASサーバーに保存されています。StoreFront は、このFASトークンとDelivery Controller をSTAとしてICAファイルに追加し、ユーザーシステムに送り返します。
ワークスペースアプリはICAファイルを解析し、VDAへのHDX接続用のオンプレミスゲートウェイへの接続を確立します。
Citrix Gatewayは、デリバリーコントローラーでSTAチケットを使用して接続を検証し、接続をVDAに渡します。
ユーザーを認証するために、VDAはGPOリストからFASサーバーに接続します。VDA資格情報プラグインはFASサーバーに接続し、トークンを検証します。これで、FASサーバーは有効なユーザー証明書をVDAに提供します。ユーザー証明書の検証に成功すると、シングルサインオンが実行され、そのユーザーのVDAセッションが開始されます。
概要
Citrixフェデレーション認証サービスは、お客様が従来のパスワード資格情報方法を排除し、SAMLなどの最新の認証方法に移行したいすべての展開を支援します。最後に、Citrix FASは重要なサービスです。したがって、展開される前に、会社のセキュリティチームによって承認されたものです。FASサービスに必要なセキュリティ管理を確認し、実装します。
ソース
このリファレンスアーキテクチャの目的は、お客様独自の実装計画を支援することです。この作業を容易にするために、独自の詳細な設計および実装ガイドに適応できるソース図を提供します:ソースダイアグラム。
参照ドキュメント
フェデレーション認証サービスの高可用性とスケーラビリティ-CTX225721