Projektstudium SS98 - distributed computing

Clients als Java Applets

Ein Java Applet kann wie in Abbildung 1 zeigt auch ein CORBA Client sein. Für CORBA macht es keinen Unterschied, ob eine Java Application oder ein Applet CORBA Objekte aufruft. Allerdings macht das Sicherheitsmodell des Webs für Applets einige Einschränkungen.

Abbildung 1: Clients Java Applets

Sicherheitsaspekte

Zum Vorbeugen gegen nicht vertrauenswürdige Applets und insbesondere zu Sicherung der Geheimhaltung, ist es Applets nur erlaubt, Netzwerkverbindungen nur zum Host von dem sie heruntergeladen wurden sind zu öffnen. Dieses Modell steht mit dem von CORBA, das Clients den Aufruf von Operationen von Objekten unabhängig von deren physischen Aufenthalt erlaubt, im Konflikt.

Es existieren mehrere Punkte an denen Kritik gegenüber dem CORBA Modell ausgeübt wird. Zunächst ist nicht jeder Host, der beim Surfen durch das Internet angewählt wird gleich zwingend vertrauenswürdig. Weiterhin kann ein Programm, das auf dem Host residiert, Informationen, die vom Applet an jeden anderen Host, der eine Verbindung zu ihm öffnen kann, weitergegeben werden. Somit wird einem Applet indirekt erlaubt, arbiträr Netzwerkverbindungen zu öffnen.

Auf der anderen Seite kann ein Applet jedem Host in einem Intranet wegen der privaten Natur des Netzwerks trauen. Die Sicherheitspolitik beschränkt Applets dadurch, das nur Verbindungen zu ihrem Source Host erlaubt sind.

Ein weiteres Problem entsteht durch Firewalls. Firewalls beschränken die Kommunikation zwischen Intranet und Internet. Sie können verschieden konfiguriert werden–beispielsweise nur das Beschränken einkommender Daten zur Vermeidung von Attacken, die von Hackern ausgehen. Gewöhnlich erlauben Firewalls Email und Web basierten Verkehr den Firewall zu passieren. Protokolle, die für Intra-ORB Kommunikation (gewöhnlich UDP/IP oder TCP/IP basiert) und IIOP (Internet InterORB Protocol: Das von der OMG spezifizierte Netzwerkprotokoll für die Kommunikation zwischen ORBs ) verwendet werden, können daher nicht jenseits des Firewalls eingesetzt werden. Zur Behebung dieser beiden Probleme bieten verschiedene Java ORBs verschiedene Lösungsansätze an.

HTTP Tunneling

Visibroker und Joe bieten einen Ansatz, der als HTTP Tunneling bezeichnet wird und in Abbildung 2 illustriert ist.

Abbildung 2: IIOP Tunneling durch HTTP

HTTP Tunneling macht das folgende:

Es packt die IIOP Calls in einen "HTTP Umschlag" um ihnen das Überwinden von Firewalls zu ermöglichen.
Es sendet sämtliche Anfragen zu einen Daemon, der auf dem Host des heruntergeladenen Applets residiert. Dieser Daemon leitet Anfragen an den Host, der durch die Objektreferenz festgelegt ist, weiter.

Visibroker und Joe implementieren HTTP Tunneling auf zwei verschiedenen Arten.

Visibroker bietet einen solchen speziellen HTTP Daemon, der in der Klasse pomoco.iiop.GateKeeper implementiert ist. Dieser Daemon ist auch in Netscape ONE HTTP Servern enthalten.

Joe wird mit einem Modul für den Apache HTTP Server ausgeliefert. Dieses Modul erlaubt Anfragen zu anderen Servern durch das "Einwickeln" von IIOP in HTTP.

Wonderwall

OrbixWeb besitzt eine andere Herangehensweise bezüglich der Lösung der beiden Probleme, die Wonderwall genannt wird.

Es bietet einen Daemon, der IIOP Anfragen vom Client erhält und sie an das richtige Objekt weiterleitet. Die Antwort wird auf die gleiche Weise zurückgegeben.

Abbildung 3: Wonderwall

Bezüglich dem Firewall Problem verfolgt Wonderwall gegenüber HTTP Tunneling einen anderen Ansatz. Anstelle existierende Firewalls zu verwenden, besitzt Wonderwall seinen eigenen Firewall.