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:

For details about each parameter, see authentication-loginSchema.

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:

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.

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.

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.

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:

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.

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:

Example 2:

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,

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

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.