This article describes the following scenario:
- Administrator configures a first factor with username, password and domain drop-down option.
- User enters credentials and selects their domain.
- Credentials arrive at NetScaler along with the domain.
- NetScaler chooses appropriate LDAP policy based on the domain information.
These steps are described in detail in the following sections. The first section briefly introduces the entities that are encountered in this article, and in general for nFactor authentication. The next section pictographically demonstrates the flow. The following sections have example “LoginSchema” that can be used to realize the logon form, and the relevant configuration.
Entities used in nFactor
Login Schema is an XML construct that is aimed at providing sufficient information to the UI tier so that it can generate user interface based on the information that is sent in this XML blob. Put another way, LoginSchema is a logical representation of logon form in XML medium.
It can be added as below:
add authentication loginSchema <name> -authenticationSchema <XML-Blob> -userExpression <Expression> -passwordExpression <Expression>
where authenticationSchema is a well-structured XML that defines the way login form is rendered. UserExpression is used to extract username from login attempt. Likewise passwordExpression is used to extract password.
Auth Policy label is a collection of authentication policies for a particular factor. It is recommended that these are pseudo-homogenous policies, which means, the credentials received from user apply to all the policies in the cascade. However, there are exceptions to this when a fallback option is configured or feedback mechanism is intended.
Authentication policy labels constitute secondary/user-defined factors. With nFactor, there is no single “secondary” cascade. There could be “N” secondary factors based on configuration. There could be as many policy labels as desired and the number of factors for a given authentication is defined by the longest sequence of policylabels beginning with the virtual server cascade.
When we bind an authentication policy to authentication virtual server, we specify nextFactor, which represents a policylabel/factor that would be taken if the policy succeeds. Likewise, when policies are bound to policylabels, nextFactor specifies the next policylabel to continue if the policy succeeds.
It can be added as below:
add authentication policylabel <name> -loginSchema <loginSchemaName>
Where, loginSchemaName will be the login schema that you want to associate with this authentication factor.
You can bind authentication policies to this label.
bind authentication policylabel <name> -policy LDAP –priority 10 –nextfactor <nextFactorLabelName>
Use Case Description
Upon accessing the login page (which is preceded by a redirect from TM virtual server) at authentication virtual server, users will see a logon form such as the one depicted in the next section. Once user enters their credentials along with choosing his domain, specific policies get selected on NetScaler for authentication. Each of these policies can have follow-up policies. However, this article only describes getting credentials from user once. For more factors, refer to appropriate document.
LoginSchema for this Use Case
Users see a drop-down with two domains. These values can be pre-filled by administrator in the loginSchema. Other fields such as labels for username and password can also be customized.
The following is an example used for this specific representation of logon form:
<?xml version="1.0" encoding="UTF-8"?><AuthenticateResponse xmlns="http://citrix.com/authentication/response/1"><Status>success</Status><Result>more-info</Result><StateContext></StateContext><AuthenticationRequirements><PostBack>/nf/auth/doAuthentication.do</PostBack><CancelPostBack>/Citrix/Authentication/ExplicitForms/CancelAuthenticate</CancelPostBack><CancelButtonText>Cancel</CancelButtonText><Requirements><Requirement><Credential><ID>login</ID><SaveID>ExplicitForms-Username</SaveID><Type>username</Type></Credential><Label><Text>User name</Text><Type>plain</Type></Label><Input><AssistiveText>Please supply either domainusername or firstname.lastname@example.org</AssistiveText><Text><Secret>false</Secret><ReadOnly>false</ReadOnly><InitialValue></InitialValue><Constraint>.+</Constraint></Text></Input></Requirement><Requirement><Credential><ID>passwd</ID><SaveID>ExplicitForms-Password</SaveID><Type>password</Type></Credential><Label><Text>Password:</Text><Type>plain</Type></Label><Input><Text><Secret>true</Secret><ReadOnly>false</ReadOnly><InitialValue></InitialValue><Constraint>.+</Constraint></Text></Input></Requirement><Requirement><Credential><ID>domain</ID><Type>none</Type></Credential><Label><Type>none</Type></Label><Input><ComboBox><InitialSelection>unspecified</InitialSelection><DisplayValues><DisplayValue><Display>(Select a domain)</Display><Value>unspecified</Value></DisplayValue><DisplayValue><Display>AAATM.COM</Display><Value>AAATM.COM</Value></DisplayValue><DisplayValue><Display>NSI-TEST.COM</Display><Value>NSI-TEST.COM</Value></DisplayValue></DisplayValues></ComboBox></Input></Requirement><Requirement><Credential><Type>none</Type></Credential><Label><Text> Please select domain to continue Login ...</Text><Type>confirmation</Type></Label><Input/></Requirement><Requirement><Credential><ID>loginBtn</ID><Type>none</Type></Credential><Label><Type>none</Type></Label><Input><Button>Log On</Button></Input></Requirement></Requirements></AuthenticationRequirements></AuthenticateResponse>
All the customizable portions of the logon form are highlighted here. Administrators can modify these values to suit their needs.
Policies for this use case
add lb vserver lbn HTTP 10.217.28.166 80 -persistenceType NONE -cltTimeout 180 -AuthenticationHost auth.nsi-test.com -Authentication ON -authnVsName avn
add authentication vserver avn SSL 10.217.28.167 443 -AuthenticationDomain nsi-test.com
add authentication login Schema nfactor-domain -authenticationSchema domain-dropdown.xml
add authentication policylabel nfactor-domain-pol -loginSchema nfactor-domain
add authentication Policy radius-auth -rule “HTTP.REQ.BODY(500).AFTER_STR(“domain=”).CONTAINS(“NSI-TEST.COM”)” -action <RADIUS-ACTION>
add authentication Policy next_ldap -rule “HTTP.REQ.BODY(500).AFTER_STR(“domain=”).CONTAINS(“AAATM.COM”)” -action <LDAP-ACTION>
bind authentication vserver avn -policy radius-auth -priority 10 -gotoPriorityExpression NEXT
bind authentication vserver avn -policy next_ldap -priority 20 -gotoPriorityExpression END
The preceding configuration describes adding a TM virtual server for resource access, adding authentication virtual server for securing TM virtual server, and relevant policies for this use-case. Portions highlighted in Yellow are to replaced with appropriate authentication actions by the administrators. Portions in Red describe the proposed rules to pick a particular authentication server based on incoming domain.
The Login Schema does not work unless we add “/nf” to the Content Switching policy expression, when using Unified Gateway.
Without “/nf”, we will get “Cannot Complete your Request”. This is such that you could have parallel authentication and vpn vservers, just in case.