How authentication, authorization, and auditing works
Authentication, authorization, and auditing provides security for a distributed internet environment by allowing any client with the proper credentials to connect securely to protected application servers from anywhere on the Internet. This feature incorporates the three security features of authentication, authorization, and auditing. Authentication enables the Citrix ADC to verify the client’s credentials, either locally or with a third-party authentication server, and allow only approved users to access protected servers. Authorization enables the ADC to verify which content on a protected server it allows each user to access. Auditing enables the ADC to keep a record of each user’s activity on a protected server.
To understand how authentication, authorization, and auditing works in a distributed environment, consider an organization with an intranet that its employees access in the office, at home, and when traveling. The content on the intranet is confidential and requires secure access. Any user who wants to access the intranet must have a valid user name and password. To meet these requirements, the ADC does the following:
- Redirects the user to the login page if the user accesses the intranet without having logged in.
-
Collects the user’s credentials, delivers them to the authentication server, and caches them in a directory that is accessible through LDAP. For more information, see Determining Attributes in Your LDAP Directory.
- Verifies that the user is authorized to access specific intranet content before delivering the user’s request to the application server.
- Maintains a session timeout after which users must authenticate again to regain access to the intranet. (You can configure the timeout.)
- Logs the user accesses, including invalid login attempts, in an audit log.
The following section discusses about the two authentication mechanism:
-
Forms based AAA-TM.
-
401 Authentication enabled AAA-TM.
Forms based AAA-TM
With Forms based authentication, a logon form is presented to the end-user. This type of authentication form supports both multifactor (nFactor) authentication and Classic authentication.
Ensure the following for the Forms based authentication to work:
-
The load balancing virtual server must have authentication turned ON.
-
‘authenticationHost’ parameter must be specified to which the user must be redirected for authentication. The command for configuring the same is as follows:
set lb vs lb1 -authentication on –authenticationhost aaavs-ip/fqdn -
Form based authentication works with browser that supports HTML
The following steps walk through how the Forms based authentication works:
-
The client (browser) sends a GET request for a URL on the TM (load balancing/CS) virtual server.
- The TM virtual server determines that the client has not been authenticated, and sends an HTTP 302 response to the client. The response contains a hidden script that causes the client to issue a GET request for /cgi/tm to the authentication virtual server.
- The client sends GET /cgi/tm containing the target URL to the authentication virtual server.
- The authentication virtual server sends out a redirect to the login page.
- The user sends out its credentials to the authentication virtual server with a POST /doAuthentication.do. Authentication is done by the authentication virtual server.
- If the credentials are correct, the authentication virtual server sends an HTTP 302 response to the cgi/selfauth url on the load balancing server with a one time token (OTP).
- The load balancing server sends HTTP 302 to the client.
-
The client sends a GET request for their initial URL target URL along with a 32 byte cookie.
401 Authentication Enabled AAA-TM
With 401 based Authentication, the Citrix ADC appliance present a pop-up dialog box as follows to the end user.
Form based AAA-TM works on the redirect messages. However, some applications do not support redirects. In such applications, 401 authentication enabled AAA-TM is used.
Ensure the following for 401 Authentication Enabled AAA-TM to work:
-
‘authnVsName’ parameter value for the load balancing virtual server must be the name of the authentication virtual server to be used to authenticate users.
-
‘authn401’ parameter must be enabled. The command for configuring the same is as follows:
set lb vs lb1 –authn401 on –authnvsName <aaavs-name>
The following steps walk through how the 401 Authentication works:
-
User tries to access a particular URL using the load balancing virtual server.
- The load balancing virtual server sends a 401 HTTP response back to the user indicating that authentication is required for the access.
- The user sends its credentials to the load balancing virtual server in the authorization header.
-
The load balancing virtual server authenticates the user and then connects the user to the back end servers.
Configuring the No_Auth policy to bypass certain traffic
You can now configure No_Auth policy to bypass certain traffic from authentication when 401-based authentication is enabled on traffic management virtual server. For such traffic, you must bind a “no-authentication” policy.
To configure the No_Auth policy to bypass certain traffic by using the CLI
At the command prompt, type:
add authentication policy <name> -rule <expression> -action <string>
Example:
add authentication policy ldap -rule ldapAct1 -action