Tag: Digest access authentication

nFactor is the new authentication framework that allows an administrator to configure complex authentication scenarios fairly easily. It reduces complexity through flexible and extensible authentication mechanisms. This framework could be used to configure all the authentication modes currently possible with NetScaler.

In the following section we are explaining the major entities involved in nFactor authentication and their significance:

LoginSchema:

nFactor decouples the ‘view’, the user interface, with the ‘model’ that is the run time handling. nFactor’s view is defined by ‘loginSchema’. LoginSchema is an entity that defines what user sees and specifies how to extract the data from user.

For defining view, loginSchema 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, loginSchema contains advanced policy expressions to glean username and password from user’s login request. These expressions are optional, and could be omitted if username and password from user arrive with expected form variable names.

LoginSchema also defines, whether current set of credentials should be used as default SingleSignOn credentials.

Policy Label:

A policyLabel is a collection of policies. It is a construct not alien to NetScaler’s Policy Infrastructure. PolicyLabel 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 policyLabel can be assumed as homogenous. PolicyLabel for authentication cannot take policies of different type, say rewrite. To put in a different way, all the policies in a policylabel validate same password/credential from user, for the most part. 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.

Policylabel can be created as follows:

>add authentication policylabel mylabel –loginSchema <>

A policylabel takes loginSchema as the property. loginSchema defines the view for that policylabel. If loginschema is not given, an implicit loginschema, LSCHEMA_INT, is associated with that policylabel. LoginSchema decides whether a policylabel becomes passthrough (described below).

Vserver Label:

In NetScaler’s advanced policy infrastructure world, a virtual server is also an implicit policylabel. 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 types. Each of the policies it put under its own label within the virtual server. Hence, virtual server is a conglomeration of labels.

Nextfactor:

Whenever a policy is bound to a virtual server (vserver) or a policylabel, it can be specified with “nextFactor”. nextFactor determines what should be done if a given authentication succeeds. If there is no nextFactor, that concludes authentication process for that user.

Each policy bound to a vserver or policylabel can have a different nextFactor. 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. It is created as shown below:

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

As can be seen above, no-authentication policy takes a rule that could 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 in conjunction with passthrough policylabels (described below), 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.

Please check example that depicts 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 policylabels or user defined (secondary) factors.

Every policylabel/factor is associated with a loginSchema 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 kind of policylabels which do not point explicitly to a loginschema. Or they point to a loginschema that does not actually point to the XML file for the view. These policylabels/factors are called ‘passthrough’ factors.

Given below are the ways to create passthrough factors.

example 1:

add authentication policylabel example1

example 2:

add loginschema passthrough_schema –authenticationSchema noschema

add authentication policylabel example2 –loginschema passthrough_schema

Passthrough factor implies that AAA subsystem should not go back to user to get credential set for that factor. Instead, it is a hint for AAA to continue with already obtained credentials. This is useful in cases where user intervention is not desired. below are some examples:

1. When user is presented two password fields. After the first factor, second factor does not need user intervention
2. When authentication of a type (say certificate) is done, and administrator needs to extract groups for that user.
3. Passthrough factor could be used with NO_AUTH policy to make conditional jumps. It is described below in a separate section.

nFactor Authentication flow

Authentication always begins at virtual server in nFactor. Virtual server defines the first factor for the user. The very 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 loginSchema policies. If there are no loginSchema policies, a single username, single password field is shown to the user.

If user needs to be shown more than one password field on customized form, loginschema policies should be used. They allow for showing different forms based on the configured rules (such as intranet user vs external user, service provider A vs service provider B, etc).

Once user credentials are posted, authentication begins at authentication virtual server, the first factor. Since authentication virtual server can be configured with multiple policies, each of them is evaluated in sequence. At any given point, if an authentication policy succeeds, ‘nextFactor’ specified against it will be taken. If there is no nextFactor, authentication process ends. If nextFactor 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, loginSchema associated with that factor is shown to the user.

Using passthrough factor and no-auth policies to make logical decisions

Example: Administrator would like to decide nextFactor based on groups

• Add authentication policylabel groupcheck
• 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 authencation policylabel groupcheck –policy admingroup –pri 1 –nextFactor factor-for-admin
• Bind authentication policylabel 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

nFactor authentication flow is depicted in the following diagram: