-
Technisches
Gebiet
-
Diese
Erfindung bezieht sich auf Verfahren und Vorrichtungen zum Liefern
eines sicheren Zugriffs zwischen einem Dienst außerhalb einer Netzfirewall
(wie beispielsweise einem Webseitenserver) und einem Client (Klient)
innerhalb der Firewall (wie beispielsweise einem Web-Browser).
-
Technischer
Hintergrund
-
Einrichtungen
für einen
globalen Zugriff auf Informationen, wie beispielsweise das World
Wide Web, unterliegen immensem Wachstum und immenser Expansion sowohl
bei einem übertragenen
Datenvolumen als auch bei einer Höherentwicklung von Werkzeugen
(Tools), wie beispielsweise Web-Browsern, zum Zugreifen auf diese
Daten. Dies erfordert wiederum, dass die Flexibilität und Fähigkeit
der Datennetzinfrastruktur erhöht
wird, ohne gleichzeitig die Sicherheitsmerkmale desselben zu gefährden. Häufig stehen
diese Zielsetzungen in Konflikt miteinander.
-
Webbasierte
Anwendungen sind von „Client-Server"-Natur. Ein Clientbasierter
Browser läuft
auf einem Computer eines Endbenutzers und kommuniziert über Netzverbindungen
mit einem Web-Server, der durch einen Dienstanbieter betrieben wird.
Der Server liefert Daten, die den Inhalt von Webseiten definieren,
die durch den Browser des Benutzers aufbereitet und angezeigt werden;
typischerweise ist der Webseiteninhalt unter Verwendung einer Markup-Sprache
definiert, wie beispielsweise der Hypertext-Markup-Sprache (HTML
= Hypertext Markup Language). Die Kommunikationen zwischen dem Browser
und dem Web-Server werden gemäß einem
Protokoll namens Hypertext-Transfer-Protokoll (HTTP = Hypertext
Transfer Protocol) durchgeführt, das
in der RFC 1945 der Internet Engineering Task Force definiert ist.
HTTP ist ein einfaches textbasiertes Protokoll, das die besondere
Eigenschaft aufweist, dass Nachrichten, die konform zu denselben
sind, vertraut wird und dieselben sich in den Internets, Intranets
und Extranets bewegen dürfen,
die das heutige „Internet" bilden. Dieses Internet
ist in Wirklichkeit eine Reihe von eng gekoppelten Netzen, die miteinander
durch „Firewalls" (Brandmauern) verbunden
sind: Netzknoten, die einen gesteuerten, beschränkten Zugriff zwischen zwei
Netzen ermöglichen.
Die Fähigkeit
jedoch, „das
World Wide Web zu durchstöbern", wird als ein allgemeiner
gemeinsamer Nenner betrachtet und an sich dürfen HTTP-Nachrichten diese
Firewalls ungeprüft
durchlaufen. Es gab eine Anzahl von Verbesserungen an dem HTTP-Protokoll:
Die Beschreibung hierin bezieht sich durch ein Beispiel auf die
Grundversion, HTTP/1.0, das allgemein unterstützt wird und mit dem spätere Versionen
von HTTP rückwärts kompatibel
sind. Dennoch ist die Erfindung nicht auf eine Verwendung mit HTTP/1.0
oder tatsächlich
irgendeiner anderen spezifischen Version von HTTP begrenzt und die
Ansprüche
derselben sind entsprechend aufzufassen.
-
Webseiten,
die unter Verwendung der Markup-Sprache definiert sind, können durch
die Verwendung eines Codes verbessert werden, der in der Java-Programmiersprache
geschrieben ist; dies ermöglicht,
dass ein dynamischer Inhalt und eine Interaktivität zu Webseiten
hinzugefügt
werden können.
Java-Komponenten können
entweder an dem Serverende der Netzverbindung als „Servlets" oder an der Client-Browser-Maschine laufen,
in welchem Fall dieselben als „Applets" bekannt sind. Viele
potentielle Sicherheitsprobleme wurden bei der Einführung von
Applets betrachtet, wie beispielsweise „Viren" und „Trojanische Pferde", so dass ein strikter Satz
von Sicherheitsbeschränkungen
darauf auferlegt wurde, was Applets dürfen und was nicht. Zu diesem Zweck
stehen Applets, die an der Client-Maschine ausgeführt werden,
in Wechselwirkung mit den verfügbaren Ressourcen
in der Rechenplattform, auf der das Applet läuft, über eine begrenzte Anwendungsprogrammierungsschnittstelle
(API = Application Programming Interface). Zum Beispiel kann das
Applet typischerweise nicht mit der lokalen Platte in Wechselwirkung
treten und kann keine Verbindung mit anderen Computern in dem Netz
in uneingeschränkter
Weise herstellen. Jedoch kann das Applet typischerweise eine Verbindung
zurück
zu dem Webserver herstellen, von dem aus es bedient wurde, obgleich
lediglich durch eine HTTP-Verbindung. Bezugnahmen auf Java beziehen
sich hierin durch ein Beispiel auf Java/1.1, das häufig eingesetzt
wird; spätere
Versionen von Java liefern eine verbesserte Netzunterstützung, aber
sind mit dieser Grundversion rückwärts kompatibel.
-
Die
erste Generation eines Webinhalts war hauptsächlich sehr statischer Natur – wie Seiten
aus einem Magazin mit Text und Bildern. Die zweite Generation eines
Webinhalts wurde zunehmend dynamisch und sah eine Benutzerschnittstelle
(Benutzeroberfläche)
für Anwendungen
vor, wie beispielsweise Datenbankabfragen. Die dritte Generation
eines Webinhalts wird zunehmend interaktiv, wobei Echtzeitkommunikationen,
wie beispielsweise Video, Text-Chat und Internettelefonie, als ein
wichtiger Teil hinzugefügt
sind. Internetbasierte Client-Server-Anwendungen sind normalerweise
durch ein Öffnen
von „Sockeln" zwischen dem Klient
und dem Server unter Verwendung des Transaction Control Protocol/Internet
Protocol (TCP/IP) wirksam. TCP/IP-Sockel liefern bidirektionale,
zuverlässige
Kommunikationswege. Diese können
verwendet werden, um dynamische oder interaktive Client-Server-basierte Anwendungen
zu implementieren, wie dieselben beispielsweise durch die zweite
und die dritte Generation eines Webinhalts benötigt werden.
-
Diese
höher entwickelten
Anwendungen stellen jedoch dahingehend ein Problem dar, dass die
Kommunikationsprotokolle, die dieselben häufig für eine Wechselwirkung mit dem
Webserver benötigen,
wie beispielsweise TCP/IP, durch Firewalls und Proxy-Server absichtlich
blockiert werden. Es ist deshalb eine Aufgabe dieser Erfindung,
Clients, wie beispielsweise Java-Applets in einer Sandbox, mit einer
gewissen gesteuerten Fähigkeit
(in dem Kontext einer spezifischen webbasierten Anwendung) zu schaffen,
um durch eine Firewall mit anderen Ressourcen, wie beispielsweise
Web-Servern, unter
Verwendung von Protokollen zusätzlich zu
HTTP in Wechselwirkung zu treten.
-
Offenbarung
der Erfindung
-
Gemäß einem
Aspekt dieser Erfindung ist ein Verfahren zum Kommunizieren zwischen
einem Dienst außerhalb
einer Netz-Firewall
und einem Client (Klient) innerhalb der Firewall vorgesehen, das
folgende Schritte aufweist:
- (a) Senden einer
anfänglichen
HTTP-GET-Anforderung von dem Client zu dem Dienst, wobei diese GET-Anforderung
einen global eindeutigen Identifizierer von dem Client zu dem Dienst überträgt;
- (b) Empfangen der anfänglichen
HTTP-GET-Anforderung bei dem Dienst und daraufhin Einrichten eines Kommunikationssockels
bei dem Dienst zum Kommunizieren von Daten von dem Dienst zu dem
Client und Aufzeichnen einer Zuordnung zwischen dem Identifizierer
und dem Sockel;
- (c) Senden einer weiteren GET-Anforderung von dem Client zu
dem Dienst nach einem vorbestimmten Intervall, wobei die weitere
HTTP-GET-Anforderung den Identifizierer umfasst;
- (d) Schließen
des Kommunikationssockels, der in der Zuordnung angegeben ist, Öffnen eines
neuen Kommunikationssockels bei dem Dienst zum Kommunizieren von
Daten zwischen dem Dienst und dem Client und Aktualisieren der Zuordnung,
um den neuen Kommunikationssockel dem Identifizierer zuzuordnen,
bei dem Dienst ansprechend auf die weitere HTTP-GET-Anforderung;
und
- (e) Wiederholen der Schritte (c) und (d), während ein Zugriff zwischen
dem Dienst und dem Client weitergehen muss;
wobei der
Dienst Daten zu dem Client über
den Kommunikationssockel liefert, der durch die Zuordnung gegenwärtig dem
Identifizierer zugeordnet ist.
-
Der
hierin als ein Beispiel dieser Erfindung beschriebene HTTP-Tunnel-Sockel
(HTTP Tunneling Socket) ist ein Sockel, der über dem HTTP-Protokoll wirksam
ist. Für
eine Wechselwirkung mit einer Java-basierten Anwendung stellt derselbe
die Standard-APIs bereit, wie dieselben für einen Sockel in der Java/1.1-API-Spezifikation
definiert sind. Für
eine Wechselwirkung mit dem Netz verwendet derselbe das HTTP/1.0-Protokoll.
Diese Technik, bei der ein Protokoll in Nachrichten getragen ist,
die über
ein anderes Protokoll gefördert
werden, ist als Tunneln bekannt. Die Verwendung eines Tunnelns hat
zwei Vorteile. Es ermöglicht,
dass der Tunnel in der Browser-Sandbox ausgeführt werden kann, da die APIs
zum Zugreifen auf eine HTTP-Verbindung mit einem Web-Server keine
Sicherheitseinschränkungen
aufweisen. Zweitens ermöglicht dasselbe,
dass die Client-Server-Verbindung
Firewalls zwischen Intranets und Internets durchläuft, da
HTTP das Protokoll ist, das alle Firewalls dieselben durchlaufen
lassen.
-
Das
Java-Applet und der Server sind somit mit einem Kommunikationsprotokoll
(wie beispielsweise TCP/IP) versehen, das vielseitiger und fähiger als
die HTTP-Verbindung ist, auf die dieselben normalerweise durch die
Firewall und/oder den Proxy-Server beschränkt wären. Jedoch verhindern die
durch die Sandbox auferlegten Einschränkungen einen bösartigen
oder unangebrachten Zugriff auf die Ressourcen der Client-Maschine
durch das getunnelte Protokoll.
-
Kurze Beschreibung
der Zeichnungen
-
Ein
Verfahren und eine Vorrichtung gemäß dieser Erfindung zum Gestatten
eines sicheren Zugriffs zwischen einem Client hinter einer Firewall
und einem Dienst, der durch einen Knoten (wie beispielsweise einen
Server) außerhalb
der Firewall geliefert wird, werden nun durch ein Beispiel mit Bezug
auf die zugehörigen Zeichnungen
beschrieben, in denen:
-
1 eine
schematische Darstellung von Umständen ist, in denen die Erfindung
verwendet werden kann;
-
2 einen
Umriss einer Implementierung der Erfindung in der Java-Programmiersprache
zeigt;
-
3 die
Grundprinzipien eines Betriebs der Erfindung darstellt;
-
4 den
Mechanismus für
Kommunikationen von dem Client zu dem Server detaillierter zeigt;
und
-
5 den
Mechanismus für
Kommunikationen von dem Server zu dem Client detaillierter zeigt.
-
Bester Modus
zum Ausführen
der Erfindung und industrielle Anwendbarkeit
-
Es
gibt prinzipiell zwei Firewalls betreffende Aspekte, die betrachtet
werden sollen, wenn eine Verbindung zwischen einem Applet in einem
Endgerät
eines Benutzers und einem Web-Server eingerichtet wird. Der erste
Aspekt ist der Fall eines firewallgeschützten Web-Servers, zu dem ein
Browser, der auf einer Maschine außerhalb der Firewall läuft, versucht,
eine Verbindung herzustellen. Dieser Aspekt stellt kein ernsthaftes
Problem dar, da der Web-Server-Besitzer die Firewall konfigurieren
kann, um zu ermöglichen,
dass diese Verbindung hergestellt wird.
-
Der
zweite Aspekt ist der Fall einer Web-Browser-Maschine in einem Firmen-Intranet,
die versucht, durch die Firmen-Firewall
eine Verbindung mit einem Web-Server in dem öffentlichen Internet herzustellen,
wie es in 1 dargestellt ist. Das Problem
hier ist, dass der Web-Server-Besitzer
entwurfsbedingt keine Steuerung über
die Firewall hat. Das vollständige
Szenario besteht darin, dass der Browser 10, der einen
Java-Applet-Code auf dem Endgerät
des Benutzers ausführt,
anfänglich
eine Verbindung mit einer Maschine 12, die ein Proxy genannt
wird, innerhalb des Firmen-Internets 14 herstellt. Dieses
Proxy stellt die erforderlichen Verbindungen durch die Firewall 16 mit
dem Internet-basierten Web-Server 18 im Auftrag des Browsers 10 her, ohne
sensible Informationen über
den Browser und das Host-Endgerät
desselben einer Betrachtung in dem öffentlichen Internet auszusetzen.
Das Proxy 12 führt
ferner verschiedene Sicherheitsprüfungen durch, um beispielsweise
sicherzustellen, dass die Anforderungen gültige HTTP-Anforderungen sind.
-
Aufgrund
der Beschränkung
der Verwendung von HTTP jedoch ist der Web-Server nicht in der Lage, erwünschte Dienste
zu dem Client zu liefern, wie beispielsweise Echtzeit-Audio, Video
oder interaktiven Chat, die bei der Verwendung von leistungsfähigeren
Protokollen, wie beispielsweise TCP/IP, möglich sind. Diese leistungsfähigeren
Protokolle sind aufgrund der Bedrohung, die dieselben bezüglich eines
Ermöglichens
eines unangebrachten oder eindringenden Zugriffs auf Ressourcen
innerhalb des Firmen-Intranets darstellen, normalerweise an einer
uneingeschränkten
Verwendung gehindert.
-
Dieses
Problem wird durch ein Verwenden der Erfindung überwunden, um einen „Tunnel" durch die Firewall,
der durch die HTTP-Nachrichten getragen ist, und somit offene Kommu nikationssockel
einzurichten, die das Java-Applet und der Web-Server verwenden können, um
miteinander zu kommunizieren. Auf diese Weise ist es dem Web-Server
ermöglicht,
Ressourcen an der Host-Maschine des Browsers zu verwenden, wenn
auch immer noch innerhalb der engen Beschränkungen, die durch die Java-Sandbox
auferlegt sind.
-
Der
Tunnel umfasst zwei Java-Programmierklassen, eine (der TunnelSockel
genannt), die die „Sockel"-Klasse implementiert,
wie es in der Java/1.1-Spezifikation definiert ist, und eine andere
(TunnelServerSockel genannt), die die „ServerSockel"-Klasse implementiert,
die in dieser Spezifikation definiert ist. Wie es in 2 gezeigt
ist, kann ein Client-basierter Java-Code auf die Standard-APIs zugreifen
(wie beispielsweise Öffnen,
Lesen, Schreiben, Schließen,
etc.), die durch eine Klasse geliefert werden, die konform zu der
Sockel-Klassendefinition ist, um mit einer anderen Java-Anwendung
zu kommunizieren, wie beispielsweise einer, die auf dem Web-Server
läuft.
Die Server-basierte Java-Anwendung kann gleichermaßen dieselben
Sockel-APIs plus die Standard-APIs, wie beispielsweise Annehmen
etc., die für
Servlets durch die ServerSockel-Klasse
vorgesehen sind, verwenden, um mit dem Clientbasierten Java-Applet
zu kommunizieren. Nachrichten zwischen der Sockel-Klasse und der
ServerSockel-Klasse werden innerhalb HTTP-Nachrichten ausgeführt, die
die Firewall zwischen dem Client und dem Server durchlaufen.
-
Der
HTTP-Tunnel verwendet das zugrundeliegende einfache textbasierte
HTTP-Protokoll, um ein zuverlässiges
verbindungsbasiertes Protokoll zwischen der TunnelSockel- und der
TunnelServerSockel-Klasse herzustellen. Grundlegende HTTP-Transaktionen verwenden
eines von zwei Verfahren bei der HTTP-Anforderungsnachricht. Das
GET-Verfahren ist entworfen, um eine Webseite von einem Web-Server
zu „bekommen" (Get), und das POST-Verfahren
wird verwendet, um Daten zu einer entfernten Webressource oder Webanwendung
zu senden. Bei einem Implementieren der vorliegenden Erfindung wird ein
GET-basiertes Protokoll für
die Client-zu-Server-Richtung
verwendet und wird ein POST-basiertes Protokoll für die umgekehrte,
die Server-zu-Client-Richtung verwendet, wie es in 3 gezeigt
ist. In dem Fall, dass HTTP durch ein funktional äquivalentes
Protokoll ersetzt ist, wird betrachtet, dass die Erfindung bei Operationen
in diesem Protokoll verwendet werden könnte, die äquivalent zu der HTTP-GET-
und der POST-Operation sind.
-
Eine
einzige Verbindung zwischen der TunnelSockel- und der TunnelServerSockel-Klasse
weist wahrscheinlich mehrere HTTP-Transaktionen auf. Um diese Transaktionen
einander zuzuordnen, wird eine numerische global eindeutige ID (GUID
= Globally Unique ID) unter Verwendung einer Kombination von Zufallszahlen,
Netzwerkadresse und Tageszeit erzeugt, so dass jede erzeugte GUID
sowohl bezüglich
Zeit als auch Position in dem Netz eine eindeutige Größe ist.
Diese GUID ist in jeder HTTP-Anforderung enthalten, sowohl GET als
auch POST, so dass das HTTP-Protokoll erkennen kann, dass sich dieselben
auf den gleichen Kommunikationssockel beziehen. Genauer gesagt wird
die GUID als der einheitliche Ressourcenindikator (URI = Uniform
Resource Indicator) von HTTP (das Feld, das verwendet wird, um einen
Dokumentennamen bei einer normalen Verwendung von HTTP zu spezifizieren)
geleitet.
-
Eine
Client-zu-Server-Verbindung ist unter Verwendung der POST-HTTP-Operation
implementiert. Jedes Mal, wenn ein Schreibvorgang zu dem Client-Sockel
(TunnelSockel-Klasse) durchgeführt
wird, wird die Anforderung verpackt und als die Nutzlast einer HTTP-POST-Nachricht
gesendet, einschließlich
der relevanten GUID, wie es in 4 gezeigt
ist. Jede derartige Schreiboperation sendet eine getrennte POST-Nachricht durch
die Firewall.
-
Die
Server-zu-Client-Richtung ist aufgrund von Einschränkungen,
die durch den Proxy-Server 12 und die Firewall 16 auferlegt
sind, komplexer. Wie es in 5 gezeigt
ist, erteilt der Client eine HTTP-GET-Nachricht, die dem Server
sagt, dass ein neuer getunnelter Sockel eingerichtet wird. Die HTTP-GET-Anforderung erzeugt
einen temporären
Server-Client-Sockel,
der ermöglicht,
dass Daten von dem Server zu dem Client geschrieben werden. Als
eine Sicherheitsvorkehrung schließen jedoch die meisten Proxy-Server-Implementierungen
einen derartigen Server-Client-Sockel nach einem Zeitintervall P,
typischerweise in der Größenordnung von
zehn Minuten Dauer. Folglich erzwingt der Tunnel, der bei dieser
Erfindung eingerichtet ist, periodisch selbst eine präventive
Beendigung der Verbindung mit einer gewissen Periodizität T, die
kürzerer
Dauer als das Intervall P ist. Dies wird durch ein Erteilen einer
weiteren GET-Anforderung erzielt, um die TunnelServerSockel-Klasse zu zwingen,
den existierenden Sockel zu dem Client zu schließen und unmittelbar einen neuen Sockel
einzurichten. Es ist zu beachten, dass diese Schließung (und
nachfolgende Wiederöffnung)
durchgeführt
wird, obwohl Daten immer noch ausstehen, um von dem Server zu dem
Client übertragen
zu werden. Dieser Ansatz vermeidet den Mehraufwand vorhergehender
Techniken, bei denen der Client den Server in einem vorausgewählten Abfrageintervall
abfragt, für
gewöhnlich
in der Größenordnung
von 20 Millisekunden. Diese häufigen
Abfragen sind äquivalent
zu mehreren Webseitenanforderungen, so dass der Server eine große Anzahl
von Webtreffern pro Sekunde empfängt,
was einen erheblichen Mehraufwand auferlegt und die Skalierbarkeit
derartiger bekannter Techniken, große Anzahlen von Clients simultan
zu handhaben, stark einschränkt.
-
Eine
Darstellung der Implementierung der Erfindung ist unten in der Form
eines Pseudocodes vorgesehen, der die erheblichen Aspekte der Implementierung
unterstreicht, aber der Klarheit halber kleinere Details auslässt, die
gut innerhalb der Fähigkeit
eines Fachmanns auf dem Gebiet liegen, obwohl dieselben in der Praxis
erforderlich sind. Gleichermaßen
wird die Existenz bestimmter Unterfunktionen angenommen, wie beispielsweise
guidFactory zum Erzeugen einer GUID und
createFiFoInputStream zum Reservieren und Konfigurieren eines Speichers
für eine
Verwendung als ein Zuerst-Hinein-Zuerst-Hinaus-Puffer (FIFO-Puffer;
FIFO = First-In-First-Out); diese Funktionen sind wiederum einzeln
gut auf dem Gebiet bekannt, so dass die internen Details derselben
nicht spezifiziert werden müssen.
Abhängig
von der speziellen Implementierungsweise können zusätzliche Parameter enthalten
sein, beispielsweise bei einigen Funktionsaufrufen; dies ist durch
eine Auslassung (...) angegeben.
-
1.
Server-zu-Client-Richtung. 1a.
TunnelSockel-EingangsStrom-Code – läuft auf Client
-
-
-
-
1b.
TunnelServerSockel-AusgangsStrom – läuft auf dem Server
-
-
-
2.
Client-Server-Richtung. 2a.
Client-seitiger TunnelSockel-AusgangsStrom
-
2b.
Server-seitiger TunnelServerSockel-EingangsStrom
-
