7.8 Webserver Agent

Um den HTTP-Kanal sichern zu können wurde der Webserver Agent komplett neu implementiert. Dabei wurde die Protokollabwicklung und die Anfragebearbeitung auf verschiedene Klassen aufgeteilt (vgl. Abbildung 7.4).

Die neue Implementierung des Webserver Agenten unterstützt das HTTP Protokoll sowohl über ``blanke'' TCP-Ströme als auch über SSL-Ströme. Die Klassen HttpServer und HttpsServer implementieren die jeweiligen Varianten, die Klasse RequestHandler ist dann für die eigentliche Bearbeitung der Anfrage zuständig.

Abbildung 7.4: Klassendiagramm des Webserver Agenten

7.8.1 HTTP über TCP/IP und SSL

Die beiden Protokolle HTTP und HTTPS^7.5 werden von den beiden Klassen HttpServer und HttpsServer bereitgestellt. In Abhängigkeit von Betriebsmodus des Agentensystems (vgl. Abschnitt 7.11) wird beim Start des Agentensystems eine Instanz der jeweiligen Klasse erzeugt.

Beide Klassen erzeugen eigene Threads, in denen für das jeweilige Protokoll ein ServerSocket Objekt erstellt wird, welches auf eingehende Verbindungen wartet.

Wird eine eingehende Verbindung erkannt, so wird eine neuer TCP-Strom zum Anfragenden aufgebaut. Das weitere Vorgehen unterscheidet sich zwischen den beiden Protokollen.

7.8.1.1 HTTP

Für das HTTP-Protokoll wird einfach ein java.net.Socket-Objekt erzeugt, und eine neue Instanz von RequestHandler übergeben.

7.8.1.2 HTTPS

Beim HTTPS Protokoll erfolgt dann der Zertifikataustausch. Das dabei benutzte Server-Zertifikat erhält der Webserver Agent vom AgentSystemCertManager. Sind die Zertifikate ausgetauscht und bis dahin kein Protokollfehler aufgetreten, dann wird das Client-Zertifikat mit der Klasse HttpsTrustDecider auf seine Gültigkeit überprüft. War dieser Schritt ebenfalls erfolgreich, so wird ein neues RequestHandler erzeugt und daran ein SSLSocket-Objekt übergeben.

Um nicht bei jeder HTTPS-Anfrage von neuem die gesamte Prozedur des Zertifikataustauschs und der Zertifikatüberprüfung durchführen zu müssen, werden mit der Klasse HttpsSessionManager einfache SSL-Sessions unterstützt.

7.8.2 Anfragebearbeitung

Objekte von Typ RequestHandler übernehmen die protokollunabhängige Anfragebearbeitung des Webserver Agenten.

Um die dezentrale Verwaltung von Agenten-Applets und agentenspezifischen HTML-Seiten deutlich zu machen wurde das alte URL Schema des Webserver Agenten durch das folgende abgelöst:

• GET / Anfrage nach dem AgentSystemApplet.

• GET /ImplementedAgents Anfrage nach einer Liste der zur Verfügung stehenden Agentengattungen ([Gerb 99]).

• GET /filename Anfrage nach einer Datei aus dem HTGUI/-Verzeichnis des Agentensystems.

• GET /agentname/agentapplet Anfrage nach dem Applet eines Agenten. Die HTML-Seite, die das Applet einbettet, wird dabei dynamisch erzeugt.

• GET /agentname/certID.appletcert Anfrage nach einem Applet-Zertifikat (vgl. Abschnitt 7.8.3).

• GET /agentname/ior Anfrage nach der IOR einer Agenteninstanz (vgl. [Gerb 99]).

• GET /agentname/url Anfrage nach der URL einer Agenteninstanz (vgl. [Gerb 99]).

• GET /agentname/.../filename Anfrage nach einer Datei aus dem HTGUI/-Verzeichnis der Agentengattung.

7.8.3 Applet-Zertifikate

Für die CORBA/IIOP-Kommunikation zwischen dem Applet und der Agenteninstanz wird ein ORB-Objekt im Applet benötigt. Damit dieses ORB-Objekt SSL-Verbindungen benutzen kann, benötigt es wiederum ein Zertifikat. Nach dem Sicherheitsmodell muß dies das Zertifikat des Anwenders sein, der das Applet bedient.

Nun ist es dem Applet allerdings nicht möglich, das im Browser vorliegende Anwenderzertifikat auszulesen, da dies einer Kompromittierung des Zertifikats gleichkäme. Deshalb wurde folgender Mechanismus implementiert, mit dem das Applet mit einem eigenen Zertifikat versorgt wird, welches aus dem Anwenderzertifikat abgeleitet ist:

1. Der Anwender fordert am Webbrowser über eine HTTPS-Verbindung ein Applet an. Dabei wird das Zertifikat des Anwenders übermittelt.

2. Der Webserver Agent fordert vom AgentSystemCertManager die Erstellung eines Applet-Zertifikats aus dem Anwenderzertifikat an. Dabei werden die Daten des Anwenderzertifikats in ein neues Zertifikat übertragen und dieses dann vom Agentensystem signiert. Das neue Zertifikat wird, mit einer ID-Nummer versehen, vom AgentSystemCertManager zwischengespeichert und die ID-Nummer an den Webserver Agenten zurückgegeben.

3. Der Webserver Agent erstellt eine HTML-Seite, in der ein Verweis auf den Applet-Code und die ID-Nummer des Zertifikats eingebettet sind. Hierzu werden die HTML-Tags APPLET und PARAM benutzt. Die HTML-Seite wird an den Webbrowser über die HTTPS-Verbindung geschickt.

4. Der Webbrowser lädt über die HTTPS-Verbindung den Applet-Code und startet das Applet.

5. Das Applet fordert das Zertifikat über die in der HTML-Seite eingebetteten ID-Nummer vom Weberserveragenten an.

6. Der Webserver Agent fordert das Zertifikat vom AgentSystemCertManager an und sendet es an das Applet.

7. Das Applet erzeugt mit dem empfangenen Zertifikat eine neue SSL-fähige ORB-Instanz.

Damit verfügt dann das Applet über ein eigenes Zertifikat, das es für die SSL-Verbindungen benutzt und aus dem der Anwender des Applets ersichtlich ist.

Fußnoten

... HTTPS^7.5

Streng genommen ist HTTPS kein eigenständiges Protokoll, sondern nur die Kombination von HTTP mit SSL-Strömen