nFactor concepts, entities, and terminology
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 login schema’. Login schema is an entity that defines what user sees and specifies how to extract the data from user.
For defining view, login schema points to a file on disk that defines the logon form. This file should be according to the specification of “Citrix Common Forms Protocol.” This file is essentially an XML definition of the logon form.
In addition to the XML file, 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 current set of credentials should be used as default SingleSignOn credentials.
Policy label
A policy label is a collection of policies. It is a construct not alien to Citrix ADC’s policy infrastructure. Policy label defines an authentication factor. That is, it contains all the policies necessary to determine whether credentials from 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 same password/credential from user, mostly. The result of policies in a policyLabel follows logical OR condition. Hence, if the authentication specified by first policy succeeds, other policies following it are skipped.
Policy label can be created by executing the following CLI command:
add authentication policy label mylabel –loginSchema <>
<!--NeedCopy-->
A policy label takes login schema as the property. Login schema defines the view for that policy label. If 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 Citrix ADC’s advanced policy infrastructure, a virtual server is also an implicit policy label. That’s because 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, 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 next factor. Next factor determines what should be done if a given authentication succeeds. If there is no next factor, that concludes 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 kind of built-in policy called NO_AUTHN. NO_AUTHN policy always returns success as authentication result. No-auth policy can be created by executing the following CLI command:
add authentication policy noauthpolicy –rule <> -action NO_AUTHN
<!--NeedCopy-->
As per the command, 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 virtual server (for 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 view for that factor. This allows for customizing views based on the path 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 executing 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 authentication, authorization, and auditing subsystem should not go back to user to get 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 user is presented two password fields. After the first factor, second factor does not need user intervention
-
When authentication of a type (say certificate) is done, and administrator needs to 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 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 user sees can be customized at 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 authentication virtual server, the first factor. Because 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 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, 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 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