Weil alles mit allem zusammenhängt

Unsere Auszubildenden bei der Provectus Technologies GmbH erhielten die Aufgabe in unserem Labor eine AAA-Authentifizierung per NetScaler zu einer Webanwendung einzurichten. Wie funktioniert es, wie läuft der Datenfluss ab und was haben sie dabei gelernt? Lesen Sie ihre Erfahrungen in diesem Artikel.

Unter Authentication, Authorization and Auditing (AAA) oder Authentifizierung, Autorisierung und Aufzeichnung, versteht man die Beschreibung eines Systems zur Kontrolle des Zugriffs auf Computerressourcen. Es dient dazu die Identität eines Nutzers festzustellen und ihm gemäß seiner Rechte Zugriff auf für ihn nötige Ressourcen und Services zu gewähren, sowie alle erforderlichen Informationen für Statistiken und die Abrechnung zu sammeln. Im Einzelnen sind dies:
Authentifizierung: Die sichere Identifizierung des Nutzers, mindestens anhand von Namen und Passwort. Es gibt aber weitere und sicherere Möglichkeiten, wie Security-Token oder die Abfrage biometrischer Merkmale, wie Fingerabdruck, Augen Iris oder Gesichtserkennung. Kombiniert man mehrere dieser Möglichkeiten, wie zum Beispiel Passwort und Security-Token, spricht man von einer Multi-Faktor-Authentifizierung.
Autorisierung: Anwendung von Policies, auf welche Ressourcen, Anwendungen und Services der authentifizierte Nutzer zugreifen kann und auf welche nicht.
Aufzeichnung: Auf welche Ressourcen greift der Nutzer zu, inkl. Nutzungsdauer und Menge der Daten, die er nutzt. Die so gewonnen Daten dienen zur Erstellung von Statistiken, zur Planung aktuell und zukünftig benötigter Ressourcen, sowie eventueller Abrechnungszwecke für kostenpflichtige Dienste etc.

Mit dieser Definition, einem recht vereinfachten Ablaufdiagramm und einer kurzen Demonstration unserer wissenden Kollegen bewaffnet, machten wir uns daran den zu erwartenden Traffic-Flow laut der offiziellen Citrix-Doku „How AAA works“ zu erarbeiteten. Dabei stellte sich heraus, dass man dort in zwei Punkten den Application-Server und den Authentication-Server verwechselte, was uns ganz schön aus der Bahn warf und für angeregte Diskussionen sorgte. Denn laut der Doku kontaktet der Client bereits im zweiten Schritt den Application-Server, was unlogisch erscheint, denn zu diesem Zeitpunkt ist der Nutzer noch gar nicht authentifiziert, dürfte also noch gar kein Traffic von ihm bis zum Application-Server durchgehen. Dem ist auch so, wie ein später gezogener Trace bewies. Selbstverständlich fängt der Load-Balancer die erste Anfrage des Client ab und leitet sie zum Authentication-Server weiter. So entstand der folgende von uns erarbeitete Traffic-Flow.

Traffic Flow:

1. Der Client meldet sich mit der URL zur gewünschten Webanwendung an den Application-Server. Diese landet beim NetScaler Traffic-Management-Virtual-Server, der ihn zum Authentication-vServer umleitet.
2. Der Authentication-vServer stellt fest, dass der Nutzer noch nicht authentifiziert ist und sendet eine Response via TM vServer zum Client.
3. Der Client antwortet mit einer Post-Request an den TM vServer.
4. Der Authentication-vServer erstellt eine Session und setzt ein Cookie mit der ursprünglichen URL des TM vServers. Sodann sendet er eine Response zum TM vServer, welche dieser zum Client weiterleitet.
5. Der Client antwortet mit einer Get-Request an den TM vServer.
6. Der TM vServer leitet den Client zur Login-Page auf dem Authentication-vServer.
7. Der Nutzer gibt seine Credentials ein und sendet eine Post-Request mit den Credentials zurück zur Login-Page.
8. Sind die eingegebenen Credentials korrekt, wird der Client vom Authentication vServer angemeldet und zur ursprünglichen URL, wie im ursprünglichen Get-Request angegeben, zum Application Server weitergeleitet.