nFactor の概念、エンティティ、および用語
このトピックでは、nFactor 認証に関係する主要なエンティティのいくつかとその重要性について説明します。
ログインスキーマ
nFactor は、ユーザーインターフェイスである ‘view’ を、ランタイム処理である ‘model’ と切り離します。nFactor のビューはログインスキーマによって定義されます。ログインスキーマは、ユーザーに表示される内容を定義し、ユーザーからデータを抽出する方法を指定するエンティティです。
ビューを定義するために、ログインスキーマはログオンフォームを定義するディスク上のファイルを指します。このファイルは、「Citrix 共通形式プロトコル」の仕様に準拠している必要があります。このファイルは基本的に、ログオンフォームの XML 定義です。
ログインスキーマには、XML ファイルに加えて、ユーザーのログイン要求からユーザー名とパスワードを収集するための高度なポリシー式が含まれています。これらの式はオプションであり、user からのユーザー名とパスワードが予想されるフォーム変数名で届いた場合は省略できます。
ログインスキーマは、現在の資格情報セットをデフォルトの SingleSignon 資格情報として使用する必要があるかどうかも定義します。
ログインスキーマを作成するには、次の CLI コマンドを実行します。
add authentication loginSchema <name> -authenticationSchema <string> [-userExpression <string>] [-passwdExpression <string>] [-userCredentialIndex <positive_integer>] [-passwordCredentialIndex <positive_integer>] [-authenticationStrength <positive_integer>] [-SSOCredentials ( YES | NO )]
<!--NeedCopy-->
注:
ssoCredentials は、現在の要素認証情報がデフォルトの SSO 認証情報であるかどうかを示します。デフォルト値は NO です。
nFactor 認証設定では、デフォルトで SSO に最終要素の認証情報が使用されます。 ssoCredentials 構成を使用すると、現在の要素の認証情報を使用できます。この構成が異なるファクタで設定される場合、この構成が設定された最後のファクタが優先されます。
各パラメータの詳細については、「https://developer-docs.citrix.com/projects/citrix-adc-command-reference/en/13/authentication/authentication-loginSchema/#add-authentication-loginS」を参照してください。
ポリシーラベル
ポリシーラベルはポリシーの集まりです。これは、Citrix ADCのポリシーインフラストラクチャとは異質ではない構成要素です。ポリシーラベルは認証要素を定義します。つまり、ユーザーからの認証情報が満たされているかどうかを判断するのに必要なすべてのポリシーが含まれています。ポリシーラベル内のポリシーはすべて同種であると見なすことができます。認証用のポリシーラベルは、書き換えなど、異なるタイプのポリシーを使用できません。言い換えると、ポリシーラベル内のすべてのポリシーは、ほとんどの場合、ユーザーからの同じパスワード/クレデンシャルを検証します。PolicyLabel のポリシーの結果は、論理 OR 条件に従います。したがって、最初のポリシーで指定された認証が成功すると、そのポリシーに続く他のポリシーはスキップされます。
ポリシーラベルは、次の CLI コマンドを実行して作成できます。
add authentication policy label mylabel –loginSchema <>
<!--NeedCopy-->
ポリシーラベルは、ログインスキーマをプロパティとして使用します。ログインスキーマは、そのポリシーラベルのビューを定義します。ログインスキーマが指定されていない場合、暗黙的なログインスキーマ LSCHEMA_INT がそのポリシーラベルに関連付けられます。ログインスキーマは、ポリシーラベルがパススルーになるかどうかを決定します。
仮想サーバラベル
Citrix ADCの高度なポリシーインフラストラクチャでは、仮想サーバーも暗黙的なポリシーラベルです。これは、仮想サーバを複数のポリシーにバインドできるためです。ただし、仮想サーバはクライアントトラフィックのエントリポイントであり、異なるタイプのポリシーを取ることができるため、仮想サーバは特殊です。各ポリシーは、仮想サーバ内で独自のラベルの下に配置されます。したがって、仮想サーバはラベルの集合体です。
次の因子
ポリシーが仮想サーバまたはポリシーラベルにバインドされる場合は常に、次の要素で指定できます。次の要素は、特定の認証が成功した場合に何をする必要があるかを決定します。次の要素がない場合、そのユーザーの認証プロセスは終了です。
仮想サーバまたはポリシーラベルにバインドされたポリシーごとに、次の要素が異なる場合があります。これにより、すべてのポリシーが成功したときにユーザー認証の新しいパスを定義できる、究極の柔軟性が得られます。管理者はこの事実を利用して、特定のポリシーを満たしていないユーザーに対して巧妙なフォールバックファクターを作成できます。
認証なしポリシー
nFactor は NO_AUTHN と呼ばれる特別なビルトインポリシーを導入しています。NO_AUTHN ポリシーは常に認証結果として成功を返す。 No-auth ポリシーを作成するには、次の CLI コマンドを実行します。
add authentication policy noauthpolicy –rule <> -action NO_AUTHN
<!--NeedCopy-->
コマンドに従って、 no-authentication ポリシーには任意の高度なポリシー式を指定できるルールが適用されます。認証結果は常に NO_AUTHN から成功する。
no-authポリシー自体は価値を付加するものではないようです。ただし、パススルーポリシーラベルとともに使用すると、ユーザ認証フローを促進する論理的な決定を柔軟に行うことができます。NO_AUTHN ポリシーとパススルーファクターは、nFactor の柔軟性に新たな次元を提供します。
注: 以降のセクションで、 no-auth およびパススルーの使用方法を示す例を確認してください。
パススルー・ファクタ/ラベル
ユーザが仮想サーバで（第 1 要素の）認証に合格すると、以降の認証はポリシーラベルまたはユーザ定義（2 次）要素で行われます。 すべてのポリシーラベル/ファクタはログインスキーマエンティティに関連付けられ、そのファクタのビューが表示されます。これにより、ユーザーが特定の要素に到達するまでの経路に基づいてビューをカスタマイズできます。
ログインスキーマを明示的に指していない特殊な種類のポリシーラベルがあります。特殊なポリシーラベルは、実際にはビューの XML ファイルを指していないログインスキーマを指しています。これらのポリシーラベル/ファクターは「パススルー」ファクターと呼ばれます。
パススルー係数は、次の CLI コマンドを実行して作成できます。
例 1:
add authentication policylabel example1
<!--NeedCopy-->
例 2:
add loginschema passthrough_schema –authenticationSchema noschema
add authentication policylabel example2 –loginschema passthrough_schema
<!--NeedCopy-->
パススルーファクターは、認証、承認、および監査サブシステムがユーザーに戻ってそのファクターのクレデンシャルセットを取得してはならないことを意味します。その代わり、認証、承認、および監査は、すでに取得した認証情報を使用して続行するためのヒントになります。これは、ユーザーの介入が望ましくない場合に便利です。例：
-
ユーザに 2 つのパスワードフィールドが表示された場合、1 つ目のファクタの後に 2 番目のファクタにユーザの介入は必要ありません。
-
あるタイプ (証明書など) の認証が行われ、管理者がそのユーザーのグループを抽出する必要がある場合。
パススルー係数をNO_AUTHポリシーとともに使用して、条件付きジャンプを行うことができます。
nFactor 認証フロー
認証は常に nFactor の仮想サーバで開始されます。仮想サーバーは、ユーザーの第1の要素を定義します。ユーザーに最初に表示されるフォームは、仮想サーバーによって提供されます。ユーザーに表示されるログオンフォームは、ログインスキーマポリシーを使用して仮想サーバーでカスタマイズできます。ログインスキーマポリシーがない場合、ユーザー名とパスワードのフィールドが 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
<!--NeedCopy-->