条件付き認証
条件付き認証は、ゼロトラストフレームワークをさらに強化するための新しいセキュリティ機能です。条件付き認証により、Citrix Cloud™ 管理者は、設定したポリシー条件に基づいて、Workspace ログインフロー中にエンドユーザーを異なる IdP に誘導できます。これにより、管理者が設定したリスク要因に基づいて、異なるエンドユーザーが異なるレベルのアクセス検証を受けることになります。
本稿執筆時点では、定義したポリシーに基づいてエンドユーザーを異なる IdP インスタンスに誘導する、5 種類の切り替え条件がサポートされています。
一般的なユースケース
- 合併・買収 (M&A) のケース。大規模な親組織が、合併プロセス中の複数の小規模企業を傘下に持つ場合。
- 組織内の正社員が通常使用を許可されているものとは異なる、専用の IdP、OIDC アプリケーション、または SAML アプリケーションに誘導することで、サードパーティユーザーや契約社員に Workspace アクセスを付与する場合。
- 異なる認証メカニズムを必要とする複数の支店や部門を持つ大規模組織。
前提条件
- Citrix Cloud Identity and Access Management ページで作成された 2 つ以上の ID プロバイダー
複数 IdP
これまで、ID タイプは単一のインスタンスのみが許可されていました。Citrix® は現在、同じ ID プロバイダータイプの複数のインスタンスを追加することをサポートしています (たとえば、複数の Azure AD を [Identity and Access Management] タブの下に追加できるようになりました)。
重要:
DaaS と SPA は現在複数の IdP をサポートしていますが、一部のサービスではこの機能の実装にまだ取り組んでおり、まもなく利用可能になる予定です。
条件付き認証の構成
- [条件付き認証プロファイルの作成] をクリックします。
-
プロファイルの名前を入力し、[認証ポリシーの作成] をクリックします。
-
必要に応じてポリシーに適用する条件を選択し、[保存] をクリックします。
-
[Workspace 構成] に移動し、[認証] をクリックして、ID プロバイダーまたは条件付き認証プロファイルを選択します。
条件付き認証の概念
条件付き認証プロファイル
条件付き認証プロファイルは、定義した条件に応じてエンドユーザーが Workspace に認証する方法を制御する複数の条件付き認証ポリシーで構成されます。このプロファイルにより、ポリシーの優先順位付けと並べ替えが可能になり、ポリシーが評価される順序を指定できます。
条件付き認証ポリシー
条件付き認証ポリシーは、1 つ以上の条件で構成されるポリシーです。これらの条件が AND ロジックを使用して満たされると、エンドユーザーのログインプロセスは、Okta OIDC、SAML、または Gateway IDP 接続などの特定のターゲット IdP インスタンスに誘導されます。個々のポリシーは複製でき、必要に応じて変更および名前変更が可能です。
各ポリシーは次のデータで構成されます。
- ポリシールール: エンドユーザーを特定の IdP インスタンスに誘導するために満たす必要がある 1 つ以上の条件。たとえば、Workspace URL 1 が使用され、かつユーザーが AD Group1 のメンバーである場合。
- ポリシー結果: ログオンプロセス中にユーザーが誘導されるターゲット IdP インスタンス。たとえば、Workspace URL 1 が使用され、かつユーザーが AD Group1 のメンバーである場合 → AAD SAML IDP インスタンス。
- ポリシー名: ポリシーを識別および説明するために使用される管理者向けのわかりやすい名前。
たとえば、
Workspace URL 1 AND Group1 - AAD SAML。 - ポリシー優先度: ポリシーが評価される順序を決定します。優先度は降順で評価されます。たとえば、優先度 1 は優先度 2 よりも高くなります。
条件付き認証の事前認証ページ
Workspace の構成方法と条件付き認証プロファイルで設定された条件によっては、Workspace ユーザーはログインプロセス中に事前認証ページに遭遇する場合があります。このページは、Workspace ユーザーのユーザー名形式をキャプチャするために不可欠であり、条件付き認証ポリシーに基づいて決定を下す上で重要です。これにより、ユーザーのログインフローが適切な IdP インスタンスに誘導されます。
ログインの自動入力
事前認証ページが必要な場合、ログインページでユーザー名フィールドに事前認証ページからのユーザー入力を自動的に入力するログイン自動入力機能を導入しました。これにより、ユーザーがユーザー名を二度入力する必要がなくなります。
ログイン自動入力機能は、以下に示すように、条件付き認証プロファイル設定で管理者によって管理および構成されます。
-
条件付き認証プロファイルページで [設定の管理] をクリックします。
-
[編集] をクリックします。
-
ログイン自動入力を有効にする IdP を選択します。
重要:
ログイン自動入力は、それをサポートする IdP でのみ利用可能であり、AD および AD+TOTP ではデフォルトで有効になり、強制されます (デフォルト設定については上記のスクリーンショットを参照)。
特定の IdP は特定のログイン形式を期待しており、一部の IdP は複数の種類のユーザー名形式をサポートできます。たとえば、Google Cloud Identity では、ユーザーはメールアドレス (
user.name@domain.com) でログインする必要がありますが、これは UPN (username@domain.com) とは異なる場合があります。Workspace エンドユーザーが事前認証ページでダウンレベルログオン名 (domain\username) を入力した場合、ダウンレベルログオン名は IdP ログインページのユーザー名フィールドに事前入力され、ユーザーがログオンしようとするとエラーが発生します。管理者は、ログイン自動入力機能を構成する前に、最も適切な IdP 切り替えポリシー条件と、特定の IdP がログオンプロセス中に受け取ることを期待するユーザー名形式を考慮する必要があります。
ポリシー条件タイプ
注:
条件付き認証プロファイルに Workspace URL 条件タイプまたはネットワークロケーション名条件タイプのみのポリシーが含まれている場合、事前認証ページは表示されず、ユーザーは直接 IdP にリダイレクトされます。プロファイルに他のポリシー条件タイプが含まれている場合、事前認証ページがエンドユーザーに表示されます。これは、一致するポリシーが Workspace URL またはネットワークロケーション名タイプであっても同様です。
Workspace URL
[Workspace 構成] > [アクセス] 内で、各 Workspace URL を個別の IdP インスタンスにリンクできます。さらに、複数の Workspace URL を同じポリシーに関連付けて、エンドユーザーを同じ IdP インスタンスに誘導できます。
ADユーザーグループメンバーシップ
ADユーザーグループメンバーシップを使用すると、グループメンバーシップに基づいて、特定のActive DirectoryユーザーグループにIdPインスタンスを割り当てることができます。
- UPNサフィックスまたはドメインダウンレベルログオン名は、相互に排他的な2つのポリシー条件です。
- これらは、エンドユーザーが事前認証ページに入力する必要があるユーザー名の形式を決定します。同じポリシー内でこれら両方の条件を使用することはできません。
UPNサフィックス
username1@domain.comやusername2@domain.netなどの1つ以上のUPNサフィックスに対してIdPインスタンスを構成します。
ドメインダウンレベルログオン名
DOMAIN1\username1やDOMAIN1.COM\username1などの1つ以上のドメイン名にIdPインスタンスを割り当てます。
相互に排他的な2つの条件のいずれかが選択されると、同じポリシーに追加されるのを防ぐために、もう一方の条件のドロップダウンメニューオプションは無効になります。
ネットワークロケーション名
クライアントのパブリックエグレスIPとネットワークロケーション名に基づいてIdPインスタンスを割り当てます。
-
適切なネットワークロケーションを作成します。
-
条件付き認証プロファイル内で、ロケーション名が事前に入力されます。目的のロケーション名を選択し、ターゲットIdPを割り当てます。
重要:
ネットワークロケーションサイト内で明示的に定義されておらず、ネットワークロケーション名ポリシーによって参照されていないクライアントエグレスIPは、「未定義」として分類されます。
一般的なNLSのユースケース/構成:
-
NLSシナリオ1: 外部（未定義）IPがWorkspaceに認証してアクセスするのをブロックします。
Policy1: AllInternalIPs NLSサイト内で定義されたエグレスIPを持つ内部クライアントのみが、ADを使用してWorkspaceにログインできます。
-
NLSシナリオ2: すべての「未定義」エグレスIPを、追加の認証要素やセキュリティ強化を伴う「キャッチオールIdPインスタンス」に誘導します。「いずれにも一致しない」とすべての内部NLSサイトのリストを使用して、「未定義のエグレスIPをすべてキャッチする」ポリシーを定義します。
Policy1: AllInternalIPs NLSサイト内で定義されたエグレスIPを持つ内部クライアントのみが、ADを使用してWorkspaceにログインできます。
Policy2: AllInternalIPs NLSサイト内で定義されていない外部エグレスIPは、TOTPを使用してWorkspaceにログインする必要があります。
条件付き認証プロファイルのカスタムエラーメッセージの設定
ユーザーが入力した内容とポリシー条件のいずれも一致しない場合に、Workspaceのエンドユーザーに表示されるユーザーフレンドリーなエラーメッセージを構成できます。
-
条件付き認証プロファイル内で、[設定の管理] を選択します。
-
エンドユーザーに表示されるデフォルトのエラーメッセージを編集します。
Citrix Monitor統合によるトラブルシューティング
ユーザーのログイン試行が一致するポリシーがないために失敗した場合、トランザクションIDを示すエラーページが表示されます。ユーザーはこのトランザクションIDをCitrix Cloud管理者に提供して、さらなるサポートを受けることができます。
Citrix Cloud管理者は、Workspaceのエンドユーザーから提供されたトランザクションIDをCitrix Monitorに貼り付けることで、ポリシー、入力されたユーザー名、および関連する条件付き認証ポリシーに関する詳細にアクセスできます。この情報は、管理者が条件付き認証の問題をより効率的にトラブルシューティングし、解決するのに役立ちます。
-
[Monitor] を選択し、右上隅にある検索ボックスをクリックします。
-
ドロップダウンリストからトランザクションIDを選択します。過去3日間のトランザクションのみが利用可能です。
-
エンドユーザーの失敗したトランザクションと、評価された条件付き認証ポリシーの詳細を表示します。シェブロンボタンをクリックして、エンドユーザーの<Policy 1 of 3>など、評価されたすべてのポリシーをナビゲートできます。
クラウドネイティブ条件付き認証とNetScalerベースの適応型認証の比較
クラウドネイティブ条件付き認証機能は、ほとんどの条件付き認証ユースケースをカバーするように設計されています。ただし、より高度な認証機能については、NetScalerベースの適応型認証が利用可能です。
NetScalerベースの適応型認証を使用するには、Citrix Cloudの[IDおよびアクセス管理] ページ > [条件付き認証プロファイル] セクションからリクエストを送信してください。
既知の問題と制限事項
- カスタムドメインは現在、条件付き認証ではサポートされていません。これは今後のアップデートのロードマップ項目です。
- ポリシーに負の優先度を設定しても、期待どおりに動作しません。これは今後のアップデートで対処されます。
- 現在、グループ条件はActive Directoryのみでサポートされています。ネイティブのEntra IDグループ条件は今後追加される予定です。