Citrix ADC

nFactor の概念、エンティティ、および用語

このトピックでは、nFactor 認証に関連する主要なエンティティの一部とその重要性について説明します。

ログインスキーマ

nFactorは、ユーザーインターフェースである「ビュー」を、ランタイム処理である「モデル」と切り離します。nFactorのビューは、ログインスキーマによって定義されます。ログインスキーマは、ユーザーが表示するものを定義し、ユーザーからデータを抽出する方法を指定するエンティティです。

ビューを定義するために、ログインスキーマは、ログオンフォームを定義するディスク上のファイルを指します。このファイルは、「Citrix 共通フォームプロトコル」の仕様に従っている必要があります。このファイルは、基本的に、ログオンフォームの XML 定義です。

XML ファイルの他に、ログインスキーマには、ユーザーのログイン要求からユーザー名とパスワードを収集するための高度なポリシー式が含まれています。これらの式はオプションであり、ユーザーからのユーザー名とパスワードが期待されるフォーム変数名で到着した場合は、省略できます。

ログインスキーマは、現在の資格情報のセットをデフォルトの SingleSignOn 資格情報として使用するかどうかも定義します。

ポリシーラベル

ポリシー・ラベルは、ポリシーの集合です。これは、Citrix ADCのポリシーインフラストラクチャに異質ではない構造です。ポリシーラベルは、認証係数を定義します。つまり、ユーザーからの資格情報が満たされているかどうかを判断するために必要なすべてのポリシーが含まれています。ポリシーラベル内のすべてのポリシーは、同種とみなすことができます。認証のためのポリシーラベルは、異なるタイプのポリシー、例えば書き換えを取ることはできません。別の方法で言えば、ポリシーラベル内のすべてのポリシーは、ユーザーからの同じパスワード/資格情報を検証します。policyLabel 内のポリシーの結果は、論理 OR 条件に従います。したがって、最初のポリシーで指定された認証が成功すると、それに続く他のポリシーはスキップされます。

ポリシーラベルは、次の CLI コマンドを実行することによって作成できます。

add authentication policy label mylabel –loginSchema <>

ポリシーラベルは、プロパティとしてログインスキーマを取ります。ログイン・スキーマは、そのポリシー・ラベルのビューを定義します。ログインスキーマが指定されていない場合、暗黙のログインスキーマ LSCHEMA_INT がそのポリシーラベルに関連付けられます。ログイン・スキーマは、ポリシー・ラベルがパススルーになるかどうかを決定します。

仮想サーバラベル

Citrix ADCの高度なポリシーインフラストラクチャでは、仮想サーバーも暗黙のポリシーラベルになります。これは、仮想サーバーも複数のポリシーにバインドできるためです。ただし、仮想サーバーはクライアントトラフィックのエントリポイントであり、異なるタイプのポリシーを取ることができるため、特別なサーバーです。各ポリシーは、仮想サーバ内で独自のラベルの下に置かれます。したがって、仮想サーバはラベルの集合体です。

次の要因

ポリシーが仮想サーバまたはポリシーラベルにバインドされるたびに、次の要素で指定できます。次の要因は、特定の認証が成功した場合に何をすべきかを決定します。次の要素がない場合は、そのユーザーの認証プロセスが終了します。

仮想サーバまたはポリシーラベルにバインドされた各ポリシーは、異なる次の要素を持つことができます。これにより、すべてのポリシーの成功において、ユーザーの認証のための新しいパスを定義できる究極の柔軟性が得られます。管理者は、この事実を活用して、特定のポリシーを満たさないユーザーに対して巧妙なフォールバック要因を作り出すことができます。

非認証ポリシー

nFactor では、NO_AUTHN という特殊な組み込みポリシーが導入されています。NO_AUTHN ポリシーは、認証結果として常に成功を返します。非認証ポリシーは、次の CLI コマンドを実行することによって作成できます。

add authentication policy noauthpolicy –rule <> -action NO_AUTHN

コマンドに従って、no-authentication ポリシーは、任意の高度なポリシー式が可能なルールを取ります。認証結果は常にNO_AUTHNから成功します。

認証なしポリシー自体は値を追加していないようです。ただし、パススルーポリシーラベルとともに使用すると、論理的な決定を下してユーザー認証フローを推進する柔軟性が得られます。NO_AUTHN ポリシーとパススルー係数は、nFactor の柔軟性に新たな次元を提供します。

注: 後続のセクションでは、no-auth とパススルーの使用方法を示す例を確認してください。`

パススルー・ファクタ/ラベル

ユーザーが仮想サーバで認証に合格すると(第 1 ファクタ)、後続の認証は、ポリシーラベルまたはユーザ定義(セカンダリ)ファクタで行われます。 すべてのポリシーラベル/ファクタは、ログインスキーマエンティティに関連付けられ、そのファクタのビューを表示します。これにより、ユーザーが指定した要素に到達するまでのパスに基づいてビューをカスタマイズできます。

ログインスキーマを明示的に指していない特殊な種類のポリシーラベルがあります。特殊なポリシーラベルは、実際にはビューの XML ファイルを指していないログインスキーマを指します。これらのポリシーラベル/ファクターは「パススルー」ファクターと呼ばれます。

パススルー係数は、次の CLI コマンドを実行することによって作成できます。

例1:

add authentication policylabel example1

例2:

add loginschema passthrough_schema –authenticationSchema noschema

add authentication policylabel example2 –loginschema passthrough_schema

パススルー・ファクタは、認証、認可、および監査サブシステムがユーザーに戻って、そのファクタのクレデンシャルセットを取得しないようにすることを意味します。代わりに、すでに取得した資格情報を続行するには、認証、承認、および監査のヒントになります。これは、ユーザーの介入が望ましくない場合に便利です。例:

  • ユーザーには、2つのパスワードフィールドが表示されます。最初の要因の後、2番目の要因はユーザーの介入を必要としません

  • タイプ(証明書など)の認証が行われ、管理者がそのユーザーのグループを抽出する必要がある場合。

パススルー係数は、条件付きジャンプを行うためにNO_AUTHポリシーで使用することができます。

nFactor 認証フロー

認証は、常に nFactor の仮想サーバで開始されます。仮想サーバーは、ユーザーの最初の要素を定義します。ユーザーに表示される最初の形式は、仮想サーバーによって提供されます。ユーザーに表示されるログオンフォームは、ログインスキーマポリシーを使用して仮想サーバーでカスタマイズできます。ログインスキーマポリシーがない場合、ユーザーには 1 つのユーザー名とパスワードフィールドが表示されます。

カスタマイズしたフォームで複数のパスワードフィールドをユーザーに表示する必要がある場合は、ログインスキーマポリシーを使用する必要があります。設定済みのルール(イントラネットユーザと外部ユーザ、サービスプロバイダ A とサービスプロバイダ B など)に基づいて、さまざまなフォームを表示できます。

ユーザーの資格情報が投稿されると、認証は最初の要素である認証仮想サーバから開始されます。認証仮想サーバは複数のポリシーで構成できるため、それぞれが順番に評価されます。任意の時点で、認証ポリシーが成功すると、そのポリシーに対して指定された次の要素が使用されます。次の要素がない場合、認証プロセスは終了します。次の因子が存在する場合、その因子が通過因子または正規因子であるかどうかがチェックされます。パススルーの場合、その要素の認証ポリシーはユーザーの介入なしに評価されます。それ以外の場合は、その要因に関連付けられたログインスキーマがユーザーに表示されます。

パススルーファクタおよび認証なしポリシーを使用して論理的な決定を行う例

管理者は、グループに基づいてnextFactorを決定したいと考えています。

  • Add authentication policylabel group check

  • Add authentication policy admin group –rule http.req.user.is_member_of(“Administrators”) –action NO_AUTHN

  • Add authentication policy nonadmins –rule true –action NO_AUTHN

  • Bind authentication policy label group check –policy admingroup –pri 1 –nextFactor factor-for-admin

  • Bind authentication policy label groupcheck –policy nonadmins –pri 10 –nextfactor factor-for-others

  • Add authentication policy first_factor_policy –rule <> -action <>

  • Bind authentication vserver <> -policy first_factor_policy –priority 10 –nextFactor groupcheck

nFactor の概念、エンティティ、および用語