nFactor 概念、实体和术语
本主题介绍了参与 nFactor 身份验证的一些主要实体及其重要性。
登录架构
nFactor将 “视图”（用户界面）与作为运行时处理的 “模型” 分离。nFactor的视图由登录架构定义。登录架构是一个实体，它定义用户看到的内容并指定如何从用户中提取数据。
为了定义视图，登录架构指向磁盘上定义登录表单的文件。此文件必须符合“Citrix 通用表单协议”的规范。此文件本质上是登录表单的 XML 定义。
除了 XML 文件之外，登录架构还包含高级策略表达式，用于从用户的登录请求中收集用户名和密码。这些表达式是可选的，如果用户提供的用户名和密码带有预期的表单变量名称，则可以省略这些表达式。
登录架构还定义了是否必须将当前的凭据集用作默认的 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 凭据。默认值为 “否”。
在 nFactor 身份验证配置中，默认情况下将最后一个因素凭据用于 SSO。通过使用 SSOCredentials 配置，可以使用当前因子凭据。如果此配置是在不同的因子中设置的，则具有此配置集的最后一个因子优先。
有关每个参数的详细信息，请参见 https://developer-docs.citrix.com/projects/citrix-adc-command-reference/en/13/authentication/authentication-loginSchema/#add-authentication-loginS。
策略标签
策略标签是策略的集合。这是一个对 Citrix ADC 的策略基础结构并不陌生的结构。策略标签定义了身份验证因素。也就是说，它包含确定是否满足用户的凭证所需的所有策略。策略标签中的所有策略都可以假定为同质策略。身份验证的策略标签不能采取不同类型的策略，例如重写。换句话说，策略标签中的所有策略都验证来自用户的相同密码/凭证，大多数情况下。策略标签中策略的结果遵循逻辑 OR 条件。因此，如果第一个策略指定的身份验证成功，则会跳过其后的其他策略。
可以通过运行以下 CLI 命令来创建策略标签：
add authentication policy label mylabel –loginSchema <>
<!--NeedCopy-->
策略标签将登录架构作为属性。登录架构定义该策略标签的视图。如果未指定登录架构，则隐式登录架构 LSCHEMA_INT 将与该策略标签关联。登录架构决定策略标签是否成为直通。
虚拟服务器标签
在 Citrix ADC 的高级策略基础结构中，虚拟服务器也属于隐式策略标签。这是因为虚拟服务器也可以绑定多个策略。但是，虚拟服务器是特殊的，因为它是客户端流量的入口点，可以采取不同类型的策略。它在虚拟服务器中放置在自己的标签下的每个策略。因此，虚拟服务器是标签的集合。
下一个因素
每当策略绑定到虚拟服务器或策略标签时，都可以使用下一个因素进行指定。下一个因素决定了给定身份验证成功时必须执行的操作。如果没有下一个因素，那么该用户的身份验证过程就结束了。
绑定到虚拟服务器或策略标签的每个策略都可以有不同的下一个因素。这提供了极大的灵活性，在每项策略成功后，都可以为用户的身份验证定义一条新的路径。管理员可以利用这一事实，为不符合某些策略的用户制定巧妙的回退因素。
无身份验证策略
nFactor 引入了一个名为 NO_AUTH 的特殊内置策略。NO_AUTHN 策略始终将成功作为身份验证结果返回。可以通过运行以下 CLI 命令来创建 No-auth 策略：
add authentication policy noauthpolicy –rule <> -action NO_AUTHN
<!--NeedCopy-->
根据命令， no-authentication 策略采用可以是任何高级策略表达式的规则。NO_AUTHN 的身份验证结果始终成功。
no-auth 策略本身似乎没有增加值。但是，当与直通策略标签一起使用时，它可以提供极大的灵活性来做出逻辑决策以推动用户身份验证流程。NO_AUTHN 策略和直通因素为 nFactor 的灵活性提供了一个新的维度。
注意： 请查看后续章节中描述用法 no-auth 和直通的示例。
直通因素/标签
用户在虚拟服务器上通过身份验证后（作为第一个因素），后续身份验证将在策略标签或用户定义的（次要）因素处进行。 每个策略标签/因子都与登录架构实体相关联，以显示该因子的视图。这允许根据用户为达到给定因子而采取的路径自定义视图。
有一些专门的策略标签没有明确指向登录架构。专用的策略标签指向实际上并不指向视图的 XML 文件的登录架构。这些政策标签/因素被称为 “直通” 因素。
可以通过运行以下 CLI 命令来创建直通因子：
示例 1：
add authentication policylabel example1
<!--NeedCopy-->
示例 2：
add loginschema passthrough_schema –authenticationSchema noschema
add authentication policylabel example2 –loginschema passthrough_schema
<!--NeedCopy-->
直通因素意味着身份验证、授权和审核子系统不得返回给用户以获取为该因子设置的凭据。相反，这是对于继续使用已获得的凭据的身份验证、授权和审核的提示。这在不需要用户干预的情况下很有用。例如，
-
当向用户显示两个密码字段时，在第一个因素之后，第二个因素不需要用户干预。
-
完成某一类型（例如证书）的身份验证后，管理员必须为该用户提取组。
直通因子可以与 NO_AUTH 策略一起使用以进行有条件的跳转。
nFactor 身份验证流程
身份验证始终从 nFactor 中的虚拟服务器开始。虚拟服务器为用户定义了第一个因素。用户看到的第一种形式由虚拟服务器提供。用户看到的登录表单可以在虚拟服务器上使用登录架构策略进行自定义。如果没有登录架构策略，则会向用户显示单个用户名和密码字段。
如果必须在自定义表单上向用户显示多个密码字段，则必须使用登录架构策略。它们允许根据配置的规则显示不同的表单（例如 Intranet 用户与外部用户、服务提供商 A 与服务提供商 B）。
发布用户凭据后，身份验证将从身份验证虚拟服务器开始，这是第一个因素。由于身份验证虚拟服务器可以配置多个策略，因此将按顺序对每个策略进行评估。在任何给定时刻，如果身份验证策略成功，则采用针对该策略指定的下一个因素。如果没有下一个因素，身份验证过程将结束。如果下一个因子存在，则检查该因子是直通因子还是正则因子。如果是直通，则在无需用户干预的情况下评估该因素的身份验证策略。否则，将向用户显示与该因子关联的登录架构。
使用直通因素和无身份验证策略做出逻辑决策的示例
管理员希望根据组决定下一个因素。
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-->