Our trainees at Provectus Technologies GmbH were given the task in our laboratory to set up an AAA authentication via NetScaler to a web application. How it works, how the data flow expires and what they have learned? Read their experiences in this article.
Authentication, Authorization and Auditing (AAA) refers to the description of a system for controlling access to computer resources. It is used to determine the identity of a user and to grant him access to resources and services required for him in accordance with his rights, as well as to collect all necessary information for statistics and billing. In detail these are:
Authentication: The secure identification of the user, at least based on name and password. But there are more smooth and safer ways like security token or the query biometrics, such as fingerprint, eyes iris or face recognition. Combining several of these options, such as password and security token, speaks of a multi-factor authentication.
Authorization: Applying policies that can and cannot access the resources, applications, and services of authenticated users.
Auditing: Which resources the user accesses, including the duration and amount of data he uses. The data obtained in this way serve to compile statistics, to plan current and future resources required, as well as possible billing purposes for chargeable services, etc.
Armed with this definition, a rather simplified flowchart and a short demonstration of our knowledgeable colleagues, we set about developing the expected traffic flow according to the official Citrix documentary “How AAA works“. It turned out that they confused the application server and the authentication server on two points, which really threw us off course and caused lively discussions. According to the document, the client already contacts the application server in the second step, which seems illogical, because at this point in time the user is not yet authenticated, so no traffic from him to the application server should pass through. This is also the case, as a trace drawn later proved. Of course, the load balancer intercepts the first request from the client and forwards it to the authentication server. This is how we created the following traffic flow.
Traffic flow:
- The client logs on to the application server with the URL to the desired web application. This lands at the NetScaler Traffic Management Virtual Server, which redirects it to the Authentication vServer .
- The Authentication vServer detects that the user is not yet authenticated and sends a response via TM vServer to the client.
- The client responds with a post request to the TM vServer.
- The Authentication vServer creates a session and sets a cookie with the original URL of the TM vServer. He then sends a response to the TM vServer, which forwards this to the client.
- The client responds with a get request to the TM vServer.
- The TM vServer redirects the client to the login page on the Authentication vServer.
- The user enters his credentials and sends a post request with the credentials back to the login page.
- If the credentials entered are correct, the client is logged on by the Authentication vServer and redirected to the original URL, as specified in the original Get request, to the Application Server.
In this flow not shown is the use of an external Authentication Server, but this is quite possible and common in the productive practice. In this case, there is still communication between the Authentication vServer and the external Authentication Server in the individual steps of the authentication. In the case described here, however, the Authentication vServer takes care of all authentication issues.
How did we go about setting up AAA in our lab environment?
We created a virtual server on the Citrix NetScaler VPX (1000) under NetScaler Gateway, based on what already existed, which was wrong. Virtual Server is just not virtual server, there are several. Now we had a VPN tunnel to nowhere but not the desired AAA connection to a web application. Therefore, on the advice of a knowledgeable colleague, we deleted the vServer and started from the beginning.
We created at the second attempt under Security -> AAA Application Traffic a new virtual server. On these we bind the existing wildcard certificate so that an encrypted connection via SSL or TLS can be made. As Authentication Policy we used LDAPS. Finally, we searched for a free address in the IP address directory and gave it to the server.
The goal was to apply AAA authentication to the open source analytics platform Kibana , which already existed. We hijacked the existing Load Balancer and turned off the authentication FQDN and the Authentication Virtual Server on our order. So that the server in the network under the desired FQDN is reachable, we only had to set up a new host (A) with the correct IP address at the DNS. Although it would have worked, at least on our own computer, if we had entered the IP address and FQDN in our Hosts file, it would not have been technically clean. The DNS did its job and promptly after entering the URL we have given the login page of the authentication server, where Kibana waited.
We learned that we should have recognized from the nomenclature of the existing vServers that we were on the wrong track with the virtual gateway server. Another mistake you make as an apprentice, which was fortunately so obvious that you will never forget it again. That’s why this small project can be called a success, because the desired learning effect was achieved.
What do you think of our trainees’ approach? Have they presented what they have learned correctly and comprehensibly, or what suggestions for improvement would you give them? Write it to us in the comments.
