技術概要:Workspace シングルサインオン
ユーザーのプライマリ Workspace ID は、SaaS、モバイル、Web、仮想アプリ、仮想デスクトップへのアクセスを許可します。承認されたリソースの多くは、ユーザーのプライマリワークスペース ID とは異なる ID を持つ別の認証を必要とします。Citrix Workspaceでは、セカンダリリソースへのシングルサインオンを提供することで、シームレスなエクスペリエンスをユーザーに提供します。
プライマリアイデンティティ
ユーザーのプライマリ ID とセカンダリ ID の違いを理解することで、Workspace シングルサインオンを理解するための基盤となります。
まず、Citrix Workspaceでは、増え続けるオプションのリストからプライマリIDを選択できます。現在、次の項目が含まれています。
- Windows Active Directory
- Azure Active Directory
- Okta
- Citrix Gateway
Citrix Workspaceでは、ユーザーのプライマリIDは2つの目的を果たします。
- Citrix Workspaceへのユーザーの認証
- Citrix Workspace内の一連のリソースへのアクセスをユーザーに許可する
ユーザーがプライマリIDを使用してCitrix Workspaceに正常に認証されると、すべてのセカンダリリソースに対する認証が行われます。組織では、ユーザーのプライマリ ID に対して強力な認証ポリシーを設定することが重要です。
多くのIDプロバイダーには,強力な認証ポリシーオプションが含まれており,Citrix Workspaceに対するユーザーのプライマリ認証を保護するのに役立ちます。Active Directory のように、IDプロバイダーに単一のユーザー名とパスワードしか含まれていない場合、Citrix Workspace には、時間ベースのワンタイムパスワードなど、プライマリ認証のセキュリティを向上させる追加機能が含まれています。
Citrix Workspace のプライマリIDについてより深く理解するには、「ワークスペースのアイデンティティ技術概要」を参照してください。
セカンダリアイデンティティ
Citrix Workspace内でユーザーがアクセスするアプリケーション、デスクトップ、リソースの多くは、セカンダリIDと呼ばれる別のユーザー資格情報のセットで保護されています。セカンダリ ID の多くは、ユーザーのプライマリ ID とは異なります。
シングルサインオン µ-service は、次のような適切なアプローチを使用して、ユーザーのプライマリワークスペース ID をリソース固有の ID に変換します。
- SAML
- Kerberos
- フォーム
- 仮想スマートカード
Citrix Workspaceでは、ユーザーはプライマリIDで一度認証し、セカンダリリソースに対するその後の認証チャレンジはすべて自動的に満たされます。
Citrix Workspaceで異なるリソースへのシングルサインオンがどのように提供されるかは、アクセスされるリソースの種類によって異なります。さまざまなアプローチをよりよく理解するには、次のトピックに分けることをお勧めします。
- SaaSアプリ
- ウェブアプリ
- モバイルアプリ (セクションは近日公開)
- 仮想アプリとデスクトップ
- IdP チェーン
SSO: SaaS アプリ
Citrix Workspaceの観点からは、SaaSアプリケーションは、サードパーティがクラウドでホストするブラウザベースのアプリケーションです。アプリケーションにアクセスするには、ユーザーは SaaS アプリケーションに関連付けられた一連の資格情報（セカンダリ ID）を使用して認証する必要があります。
SaaSアプリケーションへのシングルサインオンを実現するために、Citrix WorkspaceはプライマリIDとセカンダリIDの間でIDをフェデレートします。SSO プロセスでは、業界標準の SAML ベースの認証が使用されます。
SAML ベースの認証では、通常、次の 3 つの主要なエンティティに焦点を当てています。
- ID プロバイダー:ユーザーの ID が有効であることを証明する SAML リンク内のエンティティ
- Service Provider :セカンダリ ID に基づいてサービス (SaaS アプリ) を提供する SAML リンクのエンティティ
- アサーション:提供するデータのパッケージ
SAML ベースの認証は、2 つの異なるユーザーアカウント (プライマリとセカンダリ) を共通の属性 (通常はユーザープリンシパル名 (UPN) または電子メールアドレスに関連付けます。
ユーザー ID は、ID プロバイダーのプライマリ ID とService Provider からのセカンダリ ID で異なる場合があります。
シングルサインオンでは、ユーザーはセカンダリ ID のユーザー名やパスワードを知る必要はありません。さらに、多くの SaaS アプリケーションには、認証で SAML が使用されている場合、ユーザーアカウントからパスワードを無効にする (および直接パスワードアクセス) する機能があります。これにより、ユーザー認証では、Service Provider からのセカンダリ ID ではなく、常に ID プロバイダーのプライマリ ID が使用されます。
Citrix Workspaceでは、SAMLプロセスに4番目のコンポーネントが導入されました
- アイデンティティブローカー：複数のアイデンティティプロバイダーを複数のService Provider （Citrix Workspace）にリンクするエンティティ
SAML リンク内には、Service Provider (SP) および ID プロバイダー (IdP) として機能するエンティティが必要です。IdP には、プライマリユーザーアカウント ID を含める必要はありません。この例では、プライマリユーザー ID がプライマリユーザーディレクトリ (Dir) 内に格納されています。
アイデンティティブローカー（IdB）として機能する場合、Citrix WorkspaceはユーザーのプライマリIDに関するクレームを受け取り、セカンダリIDに変換します。
ID ブローカー (IdB) を SAML 認証フローに追加するには、ユーザーのプライマリ ID (IdP) をセカンダリ ID (SP) にリンクする共通の属性が必要です。
SAML 認証が機能するには、ID ブローカーは、各 SaaS アプリケーションの SAML 固有のログオン URL に要求を関連付けます。この URL はユーザーアサーションを受け取ります。Service Provider はアサーションを受信すると、アサーションを生成したエンティティ (ID ブローカーの SAML 発行者 URL) に対してアサーションを検証する必要があります。
Citrix Workspaceでは、SaaSアプリケーションへのシングルサインオン全体のプロセスは次のとおりです。
Citrix Workspace内のSSOからSaaSアプリを使用すると、ユーザーおよび管理者エクスペリエンスのいくつかの課題を解決できます。
- ユーザーは、セカンダリ ID ごとにユーザー名とパスワードを覚える必要はありません。
- ユーザーは、セカンダリ ID ごとに複雑なパスワードを作成する必要がない
- ユーザーは、セカンダリ ID ごとに MFA キー/トークンを設定/設定する必要がない
- 管理者は、ユーザーのプライマリ ID を無効にすることで、すべての SaaS アプリケーションへのアクセスを無効にできます
- 管理者は、サポートされている ID プロバイダの増加するリストの 1 つに基づいてユーザーのプライマリ ID を基盤にすることができます
アクセスを安全に保つには、組織では
- プライマリワークスペース ID の強力な認証ポリシーを実装する
- セカンダリ ID で SaaS アプリへの直接アクセスを無効にする
SSO: ウェブアプリ
Web アプリケーションは、組織によってホストおよび管理されるブラウザベースのアプリケーションです。 Web アプリケーションは、オンプレミスのデータセンター内でホストされます。Web アプリケーションにアクセスするには、ホストへのセキュアな接続を確立し、Web アプリケーションに関連付けられた一連の資格情報（セカンダリ ID）を使用して認証する必要があります。
ゲートウェイコネクタは、概念的なアーキテクチャに基づいて、組織のCitrix Cloudサブスクリプションへのアウトバウンドコントロールチャネル接続を確立します。オンプレミスの Web アプリケーションへの認証要求とアクセス要求が確立されると、ゲートウェイコネクタのコントロールチャネルを経由するため、VPN 接続が不要になります。
Webアプリケーションによっては、セカンダリIDは、Citrix Workspaceへの認証に使用されるプライマリIDと同じIDか、異なるIDプロバイダーによって管理される一意のIDにすることができます。
Webアプリケーションへのシングルサインオンを実現するために、Citrix Workspaceでは、プライマリID（Citrix Workspaceへのサインインに使用）とセカンダリID（Webアプリケーションにサインインするために使用される）との間でIDをフェデレートします。WebアプリケーションのSSOプロセスは、より多くのWebアプリケーションをサポートできるようにするために、複数のアプローチを使用しています。 これらのアプローチは
- 基本-Webアプリケーション・サーバーがユーザーに基本-401チャレンジを提示する場合に使用します。基本認証では、Citrix Workspaceへの認証に使用される資格情報が使用されます。
- Kerberos-Web アプリケーションサーバーがユーザにネゴシエート-401 チャレンジを提示するときに使用されます。Kerberosは、Citrix Workspaceへの認証に使用される資格情報を使用します。
- Forms-Webアプリケーション・サーバーがユーザーに HTML 認証フォームを提示する場合に使用します。フォームベース認証では、管理者が、ユーザー名とパスワードの認証ページで適切なフィールドを特定する必要があります。
- SAML-WebアプリケーションサーバーがSAMLベースの認証を使用できる場合に使用されます。この認証では、WebアプリケーションがService Provider として機能し、Citrix Workspaceがアイデンティティプロバイダとして機能します。Citrix Workspaceへのログインに使用するユーザーのプライマリIDには、Webアプリケーションの資格情報とパラメーター（UPNまたは電子メール）が必要です。SAML ベースのシングルサインオンの詳細については、SSO から SaaS アプリへのセクションを参照してください。
- SSOなし-Webアプリケーション・サーバーがユーザー認証を必要としない場合、または管理者がユーザーに手動でサインインする必要がある場合に使用します。
Citrix Workspace内のWebアプリケーションへのシングルサインオンにより、ユーザーおよび管理者エクスペリエンスのいくつかの課題を解決できます。
- ユーザーは、各 Web アプリケーションのユーザー名とパスワードを覚える必要はありません。
- ユーザーは、Webアプリケーションごとに複雑なパスワードを作成する必要はありません
- ユーザーは、各 Web アプリケーションに対して MFA キー/トークンを設定/設定する必要はありません。
- ユーザーは、内部 Web アプリケーションにアクセスするために VPN 接続を開始する必要はありません。
- 管理者は、ユーザーのプライマリ ID を無効にすることで、すべての Web アプリケーションへのアクセスを無効にできます
- 管理者は、サポートされている ID プロバイダの増加するリストの 1 つに基づいてユーザーのプライマリ ID を基盤にすることができます
- 導入後は、管理者はゲートウェイコネクタを更新する必要はありません。Citrix Cloudサービスは、必要に応じて更新を自動化します。
アクセスを安全に保つには、組織では
- プライマリワークスペース ID の強力な認証ポリシーを実装する
- Web アプリケーションへの VPN アクセスを無効にする
冗長ゲートウェイコネクタを展開して、コネクタの更新時に可用性を維持します。一度に 1 つのコネクタのみが更新され、成功の結果を受信するまでプロセスは続行されません。
SSO: Virtual Apps and Desktops
Citrix Virtual Apps and Desktopsを使用すると、ユーザーはWindowsおよびLinuxベースのアプリケーションおよびデスクトップにリモートでアクセスできます。Windows ベースの仮想アプリケーションまたはデスクトップにアクセスするには、ユーザーが Active Directory ID で認証する必要があります。
ユーザーのプライマリ Workspace ID が Active Directory の場合、仮想アプリとデスクトップセッションはパススルー認証を使用して、セカンダリリソースへのシングルサインオンを提供します。ただし、組織がユーザーのプライマリアイデンティティにActive Directoryベースの非IDプロバイダを使用する場合は、Citrix Workspace シングルサインオン機能でプライマリIDをActive Directory セカンダリIDに変換する必要があります。
Citrix工作区では,仮想アプリおよびデスクトップへのシングルサインオンを実現するために、ユーザー用にActive Directoryベースの仮想スマートカードを動的に生成するフェデレーション認証サービスが使用されます。
仮想スマートカードを生成する前に、Workspace は一連の共通属性を介して、ユーザーのプライマリ ID と Active Directory ベースのセカンダリ ID をリンクできる必要があります。
たとえば、Okta がCitrix Workspace プライマリIDである場合、ユーザーのOOkta アイデンティティには3つの追加パラメータ（cip_sid、cip_upn、cip_oid）を含める必要があります。パラメータは、Active Directory アイデンティティを Okta アイデンティティに関連付けます。
ユーザーがプライマリIDに正常に認証されると、Citrix Workspace内のシングルサインオン機能では、パラメータを使用して仮想スマートカードを要求します。
Citrix Workspaceでは、Windowsベースの仮想アプリケーションおよびデスクトップへのシングルサインオンの全体的なプロセスは次のとおりです。
この例では、Citrix Virtual Apps and Desktops がオンプレミスの展開であることを前提としています。
組織がクラウドベースのCitrix Virtual Apps and Desktopsサービスを使用している場合、アーキテクチャは次のようになります。
Citrix Workspace内のWindowsベースの仮想アプリケーションおよびデスクトップへのSSOにより、ユーザーおよび管理者エクスペリエンスのいくつかの課題を解決できます。
- 仮想アプリケーションまたはデスクトップにアクセスするときに認証プロンプトが表示されない
- ユーザーは、Active Directory アイデンティティの複雑なパスワードを作成、更新、および記憶する必要がない
- 管理者は、ユーザーのプライマリ ID を無効にすることで、すべての仮想アプリケーションとデスクトップへのアクセスを無効にできます
フェデレーション認証サービスを適切に統合するには、次の点を考慮してください。
- 同期:プライマリワークスペース ID は、Active Directory ベースのセカンダリ ID との同期を維持する必要があります。多くのプライマリ ID プロバイダーには、プライマリ ID とセカンダリ ID 間の同期を維持するために役立つ Active Directory 同期ツールが含まれています。適切な同期がない場合、フェデレーション認証サービスは Active Directory ID を仮想スマートカードに関連付けることができません。
- スマートカードのみの認証:グループポリシーオブジェクトを使用すると,管理者はスマートカードのみの認証を強制できます。これにより、ユーザーがセカンダリ ID のユーザー名/パスワード資格情報を使用して、セキュリティで保護されたプライマリ ID をバイパスしようとする可能性を排除します。ただし、ユーザーがサービスへの対話的にログオンするためにユーザー名/パスワードを使用する必要がある場合、このポリシー設定を有効にすると認証が失敗します。
- 仮想スマートカードセキュリティ:フェデレーション認証サービスインフラストラクチャが適切に管理および保護されていることを確認することが重要です。次の記事では、フェデレーション認証サービスのセキュリティに関する推奨事項について説明します。
- 冗長性:運用環境では、アーキテクチャ全体に耐障害性を設計の一部として組み込む必要があります。これには、冗長フェデレーション認証サービスサーバー、証明機関などが含まれます。環境の規模によっては、組織はルート認証局を指すのではなく、下位証明機関専用にする必要がある場合があります。
- 認証局:運用環境の場合、組織は規模を処理する認証局を設計する必要があります。また、組織が関連する証明書失効リスト (CRL) インフラストラクチャを適切に設計し、サービス中断の可能性を克服する必要があります。
- 3 次認証:仮想デスクトップセッション内では、多くの内部 Web サイトで Active Directory ID で認証する必要があります。仮想デスクトップへのシングルサインオンを提供するために使用される仮想スマートカードを使用して、内部 Web サイトへのシングルサインオンを提供できます。フェデレーション認証サービスでは、仮想スマートカードがユーザー証明書ストア内に配置されるセッション内証明書を (グループポリシーオブジェクトを介して) 許可します。この機能は、これらの第三リソースへのシングルサインオンを提供します。
SSO: IdP チェーニング
現在、多くの組織が SaaS アプリケーションへのシングルサインオンを提供するために、サードパーティソリューション (Okta、Ping、Azure など) に依存しています。Citrix Workspaceでは、IdPチェーンと呼ばれるプロセスを介して、SSO対応のSaaSアプリケーションをユーザーのリソースフィードに統合できます。IdP チェーンは、本質的に 1 つの SAML アサーションを別の SAML アサーションに変換します。IdPチェーンにより、組織は現在のSSOプロバイダーを維持しながら、Citrix Workspaceと完全に統合できます。これには、強化されたセキュリティポリシーの実装も含まれます。
Citrix WorkspaceがSaaSアプリケーションにSSOを提供する場合、SAML認証が使用されます。SAML ベースの認証は、2 つの異なるユーザーアカウント (プライマリとセカンダリ) を共通の属性 (通常はユーザープリンシパル名 (UPN) または電子メールアドレスに関連付けます。
SAML ベースのシングルサインオンでは、次の 2 つのパートナーがあります。
- Service Provider (SP): サービスを提供し、セカンダリ ID を含むエンティティ
- ID プロバイダー (IdP): ユーザーのプライマリ ID の検証を提供するエンティティ。SAML グループ内の ID プロバイダーは、ユーザーの ID の最終的な権限である必要はありません。
プライマリユーザーディレクトリは、ユーザーの ID の最終的な権限です。アイデンティティブローカー（IdB）として機能するCitrix Workspaceでは、プライマリユーザーディレクトリ（Dir）からユーザーに関する要求を取得し、SAMLアサーションを作成します。アサーションは、ユーザーの ID をService Provider (SP) に証明し、シングルサインオンプロセスを実行します。
組織がすでに別の SSO プロバイダーを利用している場合、IdP チェーンは認証チェーンに追加の SAML 認証リンクを追加します。
このIdP連鎖の例では、アイデンティティブローカーとして機能するCitrix Workspaceがユーザーをプライマリユーザーディレクトリに対して認証します。最初のSAMLリンク内で、Citrix Workspaceはユーザーに関するクレームを使用して、Service Provider として機能するOKTA固有のリソースに対するSAMLアサーションを作成します。2 番目の SAML リンク内で、Okta はユーザーに関するクレームを利用して、Service Provider である特定の SaaS アプリケーションの SAML アサーションを作成します。
IdP チェーンは、ユーザーのプライマリ ID と要求されたサービスの間に追加のリンクを追加します。各 SAML リンク内で、ID プロバイダーとService Provider 間の共通属性は同じである必要があります。認証がチェーン内の異なるリンクを通過すると、共通属性が変更される可能性があります。
各 SAML リンク内で、ID プロバイダーは、各 SaaS アプリケーションの SAML 固有のログオン URL に認証要求を関連付けます。この URL は、共通属性を含むユーザーアサーションを受け取ります。Service Provider はアサーションを受信すると、アサーションを生成したエンティティ (アイデンティティープロバイダーの SAML 発行者 URL) に対してアサーションを検証する必要があります。
IdPチェーンでは,SSOプロバイダー内の各SSO対応アプリケーションにアプリ固有のURLがある点を除いて、プロセスは同一です。アプリ固有の URL は、Service Provider として機能します。アプリケーション固有の URL は、SSO プロバイダーがService Provider ロールを引き受けるときの SAML ログイン URL として使用されます。
この例では、ユーザーがCitrix Workspace内からOKTA対応アプリケーションを選択すると、Citrix Workspaceは要求されたOkta アプリケーションのSAMLログインURLにアサーションを提示します。Okta は、Citrix WorkspaceからのSAML発行者のURLを使用してアサーションを検証します。成功すると、Okta は SaaS アプリケーションの SAML ログイン URL にアサーションを提示し、Okta SAML 発行者 URL を使用してアサーションを検証します。
IdP チェーンを考える最も簡単な方法は、チェーン内の各リンクに個別に焦点を当てることです。これには、1 つの ID プロバイダーと 1 つのService Provider が含まれます。この例では、チェーン内のリンクは次のとおりです。
- シトリックスからオクタへ
- Okta-to-Workday
これにより、次の認証フローが生成されます。
IdPチェーンを作成すると、組織は現在のSSOプロバイダーを維持しながら、Citrix Workspace内のすべてのリソースを統一することができます。