Product Documentation
ADC
14.1-Current Release 13.1
View PDF

nFactor concepts, entities, and terminology

October 22, 2025
Contributed by: 
C

This topic captures some of the major entities involved in nFactor authentication and their significance.

Login schema

nFactor decouples the ‘view’, the user interface, with the ‘model’ that is the runtime handling. nFactor’s view is defined by the login schema. Login schema is an entity that defines what the user sees and specifies how to extract the data from the user.

For defining a view, the login schema points to a file on disk that defines the logon form. This file must be according to the specification of the “Citrix® Common Forms Protocol.” This file is essentially an XML definition of the logon form.

In addition to the XML file, the login schema contains advanced policy expressions to glean user name and password from the user’s login request. These expressions are optional, and can be omitted if user name and password from user arrive with expected form variable names.

Login schema also defines, whether the current set of credentials must be used as default SingleSignOn credentials.

Login schema can be created by running the following CLI command:

   add authentication loginSchema <name> -authenticationSchema <string> [-userExpression <string>] [-passwdExpression <string>] [-userCredentialIndex <positive_integer>] [-passwordCredentialIndex <positive_integer>] [-authenticationStrength <positive_integer>] [-SSOCredentials ( YES | NO )]
<!--NeedCopy-->

Note:

  • SSOCredentials indicate whether the current factor credentials are the default SSO credentials. Default value is NO.

  • By default, the last factor’s credentials are used for SSO in nFactor authentication. However, by configuring SSOCredentials, you can opt to use the current factor’s credentials. If SSOCredentials is configured in multiple factors, the final factor with this setting takes precedence.

  • For nFactor authentication, we recommend enabling SSOCredentials only on the factor that actually validates user credentials (like a password), and not on factors that gather user information or metadata.

    For example, if your nFactor flow first collects user attributes (such as group membership) and a later factor verifies the password, make sure SSOCredentials is enabled only on that password verification factor.

For details about each parameter, see authentication-loginSchema.

Policy label

A policy label is a collection of policies. It is a construct not alien to NetScaler’s policy infrastructure. Policy label defines an authentication factor. That is, it contains all the policies necessary to determine whether credentials from the user are satisfied. All the policies in a policy label can be assumed as homogenous. Policy label for authentication cannot take policies of different type, say rewrite. To put in a different way, all the policies in a policy label validate the same password/credential from the user, mostly. The result of policies in a policyLabel follows the logical OR condition. Hence, if the authentication specified by the first policy succeeds, other policies following it are skipped.

Policy label can be created by running the following CLI command:

add authentication policy label mylabel –loginSchema <>
<!--NeedCopy-->

A policy label takes the login schema as the property. Login schema defines the view for that policy label. If the login schema is not specified, an implicit login schema, LSCHEMA_INT, is associated with that policy label. Login schema decides whether a policy label becomes a passthrough or not.

Virtual server label

In NetScaler’s advanced policy infrastructure, a virtual server is also an implicit policy label. That’s because the virtual server can also be bound with more than one policy. However, a virtual server is special because it is the entry point for client traffic and can take policies of a different type. Each of the policies it put under its own label within the virtual server. Hence, the virtual server is a conglomeration of labels.

Next factor

Whenever a policy is bound to a virtual server or a policy label, it can be specified with the next factor. Next factor determines what must be done if a given authentication succeeds. If there is no next factor, that concludes the authentication process for that user.

Each policy bound to a virtual server or policy label can have a different next factor. This allows for ultimate flexibility where in every policy’s success can define a new path for user’s authentication. Administrator can take advantage of this fact and craft clever fallback factors for users who do not meet certain policies.

No-Auth policy

nFactor introduces a special built-in policy called NO_AUTHN. NO_AUTHN policy always returns success as the authentication result. The No-auth policy can be created by running the following CLI command:

add authentication policy noauthpolicy –rule <> -action NO_AUTHN
<!--NeedCopy-->

As per the command, the no-authentication policy takes a rule that can be any advanced policy expression. Authentication result is always success from NO_AUTHN.

A no-auth policy in itself does not seem to add value. However, when used along with passthrough policy labels, it offers great flexibility to make logical decisions to drive user authentication flow. NO_AUTHN policy and passthrough factors offer a new dimension to nFactor’s flexibility.

Note: Check the examples that depict the usage of no-auth and passthrough in subsequent sections.

Passthrough factor/label

Once the user has passed the authentication at the virtual server (for the first factor), subsequent authentications happen at policy labels or user defined (secondary) factors. Every policy label/factor is associated with a login schema entity to display the view for that factor. This allows for customizing views based on the path the user would have taken to arrive at a given factor.

There are specialized kinds of policy labels which do not point explicitly to a login schema. Specialized policy labels point to a login schema that does not actually point to the XML file for the view. These policy labels/factors are called ‘passthrough’ factors.

Passthrough factors can be created by running the following CLI commands:

Example 1:

add authentication policylabel example1
<!--NeedCopy-->

Example 2:

add loginschema passthrough_schema –authenticationSchema noschema

add authentication policylabel example2 –loginschema passthrough_schema
<!--NeedCopy-->

Passthrough factor implies that the authentication, authorization, and auditing subsystem must not go back to the user to get the credential set for that factor. Instead, it is a hint for authentication, authorization, and auditing to continue with already obtained credentials. This is useful in cases where user intervention is not desired. For example,

  • When the user is presented two password fields, after the first factor, the second factor does not need user intervention.

  • When authentication of a type (say certificate) is done, and the administrator must extract groups for that user.

Passthrough factor can be used with NO_AUTH policy to make conditional jumps.

nFactor authentication flow

Authentication always begins at the virtual server in nFactor. Virtual server defines the first factor for the user. The first form that the user sees is served by the virtual server. The logon form that the user sees can be customized at the virtual server using login schema policies. If there are no login schema policies, a single user name and password field are displayed to the user.

If more than one password fields must be displayed to the user on customized form, login schema policies must be used. They allow for displaying different forms based on the configured rules (such as intranet user versus external user, service provider A versus service provider B).

Once user credentials are posted, authentication begins at the authentication virtual server, the first factor. Because the authentication virtual server can be configured with multiple policies, each of them is evaluated in a sequence. At any given point, if an authentication policy succeeds, the next factor specified against it is taken. If there is no next factor, the authentication process ends. If the next factor exists, it is checked if that factor is a passthrough factor or a regular factor. If that is passthrough, authentication policies on that factor are evaluated without user intervention. Otherwise, the login schema associated with that factor is displayed to the user.

Example of using passthrough factor and no-auth policies to make logical decisions

Administrator would like to decide nextFactor based on groups.

add authentication policylabel group check

add authentication policy admingroup –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-->
nFactor concepts, entities, and terminology
October 22, 2025
Contributed by: 
C
October 22, 2025
Contributed by: 
C

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.