In high security applications, the use of two-factor authentication (2FA) is often a hard requirement to provide enhanced security and meet more stringent compliance requirements.
With 2FA, users are required to provide two means of identification credentials for authentication. The most common example of 2FA is the use of traditional user name and password credentials in combination with a personal identification number (PIN) or token.
2FA can be implemented using RADIUS, which is an industry-standard protocol for providing authentication, authorization, and accounting services. The RADIUS server matches data from the authentication/authorization request with information in a trusted database, such as RSA SecurID, SQL or LDAP. If a match is found and the user’s credentials are correct, the RADIUS server sends a “success” response to the client, which is then allowed access to a corporate resource. A similar solution can be deployed using a Web Authentication server, which connects to a trusted backend database with user security information, where user credentials are sent through HTTP headers.
NetScaler version 10.5 and later with the AAA-TM feature can now authenticate users to a Web Authentication server, providing the credentials that the web server requires in an HTTP request and subsequently analyzing the web server response to determine that user authentication was successful.
Previously, a similar exercise would be done using the HTTP Callout feature, where a client would send the user name and password through HTTP headers in the request. A typical implementation of an HTTP callout would include creating an HTTP callout on the appliance and configuring it with details about the external server and other required parameters, configuring a responder policy to analyze the response and then creating a callout agent on the remote server.
The new Web Authentication feature now simplifies this process, where configuration is similar to creating a standard authentication server and a policy that can be bound to a virtual server for single FA or 2FA.
As with other types of authentication policies, a Web authentication policy is comprised of an expression and an action. After creating an authentication policy, you bind it to an authentication virtual server and assign a priority to it. When binding it, you also designate it as either a primary or a secondary policy.
To set up web-based authentication with a specific web server, first you create an Authentication WEB Server that contains the following items:
- Name—Name for the Web Authentication action.
- Web Server IP Address— The IP address of the authentication Web server.
- Port— The port of the authentication Web server.
- Protocol—HTTP (for unencrypted web authentication) or HTTPS (for encrypted web authentication).
- HTTP Request Expression— An expression in NetScaler default syntax that contains the user’s credentials in the format that the Web server expects.
- Expression to validate the Authentication—An expression in NetScaler default syntax that matches the web server response string that signifies that the user authenticated successfully.
Authentication Rule & Expression to validate the Authentication are the most important items in the list above, which have to be formatted precisely to ensure the NetScaler request and response matches the exact POST expression that the Web server expects. In this example we will use a sample POST request and response to configure Web authentication on NetScaler 10.5. At high level we need to complete following 5 steps:
- Create a Netscaler Gateway VIP or AAA-TM Virtual Server and associated configuration.
- Create Web authentication server “HTTP Request Expression” & “Expression to validate the Authentication”
- Create Web authentication server and tie in the details from step 2.
- Create Web authentication policy and associate it with the Web Authentication Server.
- Bind the Web Authentication Policy to the Netscaler Gateway or AAA-TM VIP in question.
We will assume, at this point, that you are implementing this solution because of a specific requirement where the credentials from Netscaler Gateway or AAA-TM needs to be sent to a specific server in a specific manner that requires this approach.
At this point, one should also validate that the basic Netscaler Gateway ICA proxy functionality is working with standard LDAP based authentication. Once done, it’s now time to get to the exciting stuff!