-
Hintergrund der Erfindung
-
Gebiet der Erfindung
-
Die
vorliegende Erfindung bezieht sich allgemein auf Computer und Software,
und insbesondere auf die Sicherheit im Zusammenhang mit dem Zugriff auf
eine Web-Ressource auf einem Server mit einem Klientbrowser.
-
Beschreibung
des Stands der Technik
-
Wie
es in der Technik bekannt ist, ist das Internet eine weltweite Sammlung
von Netzwerken und Gateways bzw. Netzübergängen, die die TCP/IP-Protokollfolge
verwenden, um miteinander zu kommunizieren. Das Herz des Internets
ist ein Backbone von Hochgeschwindigkeitsdatenkommunikationsleitungen
zwischen Hauptknoten oder Hostcomputern, die aus Tausenden von kommerziellen Regierungs-,
Erziehungs- und anderen Computersystemen bestehen, die Daten und
Mitteilungen leiten.
-
World
Wide Web (WWW) bezieht sich auf den gesamten Satz von miteinander
verbundenen Hypertext-Dokumenten, die sich auf Hypertext-Transfer-Protokoll-(HTTP-)Servern
auf der ganzen Welt befinden. Dokumente auf dem WWW, die als Seiten
oder Webseiten bezeichnet werden, sind in Hypertext-Markup-Sprache (HTML; HTML
= hypertext mark-up language) geschrieben, die durch Einheitsressourcenlokatoren
(URL; URL = uniform resource locators) identifiziert werden, die
die bestimmte Maschine und den Pfadnamen spezifizieren, durch die
auf eine Datei zugegriffen werden kann und dieselbe von Knoten zu
Knoten zu dem Endnutzer unter HTTP übertragen werden kann. Eine
Website ist eine verwandte Gruppe dieser Dokumente und zugeordneten
Dateien, Scripte, Teilprozeduren und Datenbanken, die durch einen
HTTP-Server auf dem WWW angeboten werden.
-
Benutzer
benötigen
ein Browser-Programm und eine Internetverbindung, um auf eine Website zuzugreifen.
Browser-Programme,
die auch als „Web-Browser" bezeichnet werden,
sind Klient-Anwendungen, die es einem Benutzer ermöglichen,
im Internet zu navigieren und HTML-Dokumente auf dem WWW, einem
anderen Netzwerk oder dem Computer des Benutzers zu betrachten.
Web-Browser ermöglichen
es Benutzern auch, Codes zu folgen, die als „Kennungen" bezeichnet werden, die in einem HTML-Dokument
eingebettet sind, die bestimmte Wörter und Bilder in dem Dokument
URLs zuordnen, so dass ein Benutzer auf eine andere Datei zugreifen
kann, die sich irgendwo auf der Welt befinden kann, mit nur einem
Tastendruck oder einem Mausklick.
-
Diese
Dateien können
Text (in einer Vielzahl von Schriftarten und -typen), Graphikbilder,
Filmdateien und Töne
sowie Java-Applets, Perl-Anwendungen, andere Script-Sprachen, aktive
X-Steuerungen oder andere kleine eingebettete Softwareprogramme enthalten,
die ausgeführt
werden, wenn der Benutzer dieselben durch Klicken auf eine Verknüpfung aktiviert.
Scripte sind Anwendungen, die durch einen HTTP-Server ansprechend auf eine Anforderung durch
einen Klient-Benutzer
ausgeführt
werden. Diese Scripts werden durch den HTTP-Dämon aufgerufen, um einen einzelnen
Auftrag auszuführen,
und dann enden.
-
Ein
Typ von Script ist ein CGI-Script (CGI = common gateway interface
= gemeinsame Gateway-Schnittstelle). Allgemein wird ein CGI-Script
aufgerufen, wenn ein Benutzer auf ein Element in einer Webseite
klickt, wie z. B. eine Verknüpfung
oder ein Bild. CGI-Scripts werden verwendet, um Interaktivität in einer
Webseite zu liefern. CGI-Scripts können in vielen Sprachen geschrieben
sein, einschließlich
C, C++ und Perl. Ein CGI-BIN ist eine Bibliothek von CGI-Script- Anwendungen, die
durch einen HTTP-Server ausgeführt
werden können.
-
Eine
Hauptschwierigkeit bei dem Zugriff auf diese Dokumente und zugeordnete
Dateien, Scripte, Teilprozeduren und Datenbanken, die durch einen HTTP-Server
auf dem WWW angeboten werden, ist die der Sicherheit. Wie kann man
sicherstellen, dass nur erlaubte Benutzer von erlaubten Klient-Systemen Zugriff
zu der Server-Anwendung erhalten, und auch sicherstellen, dass der
Zugriff nicht für
böswillige Zwecke
missbraucht werden kann?
-
Das
Verfahren, das derzeitig verwendet wird, umfasst die Verwendung
eines „Cookie". Cookies sind Datenblöcke, die
ein Server ansprechend auf eine Anforderung von dem Klient zu einem
Klient zurücksendet.
Der Datenblock wird dann auf dem System eines Klienten gespeichert.
Wenn der Klient zu der gleichen Website zurückkehrt, sendet der Klient eine
Kopie des Cookie zurück
zu dem Server und identifiziert dadurch den Klient für den Server. Cookies
werden verwendet, um Benutzer zu identifizieren, um den Server anzuweisen,
eine kundenspezifische Version der angeforderten Webseite zu senden,
um Account-Informationen für
den Benutzer vorzulegen und für
andere Verwaltungszwecke. Bei den meisten Systemen wird ein Cookie-Programm
während
der Anmeldung des Benutzers ausgeführt.
-
Die
bisherige Lösung
zum Liefern von Sicherheit, wenn auf Web-Ressourcen zugegriffen wird,
leidet an den folgenden Sicherheitsschwächen. Es wird später gezeigt,
wie die vorliegende Erfindung bestimmte dieser Schwierigkeiten adressiert
und überwindet.
-
Ein
Problem der herkömmlichen
Lösungen ist,
dass die Host-Adressen
und Benutzernamen (d. h. Benutzer-Anmeldungsinformationen) in Klartext gesendet
werden, der sehr leicht „manipuliert" werden kann. Ein
versierter Hacker kann Pakete übertragen,
und vorgeben, von einer anderen Maschine zu sein oder ein anderer
Benutzer zu sein, und dadurch unbefugten Zugriff zu dem Server erhalten.
-
Noch
ein weiteres Problem ergibt sich, wenn mehrere Benutzersicherheitspegel
angestrebt werden. Das Cookie-Verfahren ermöglicht nur einen einzigen Sicherheitspegel.
Darüber
hinaus ermöglicht die
Verwendung von Cookies nicht, dass eine Benutzeranwendung mit einem
Sicherheitssystem integriert wird. Derzeit sind Cookies Teil des
Klientbrowser-Programms
und sind getrennt von einer Benutzeranwendung.
-
Ein
weiteres Problem im Stand der Technik ist, dass die Authentifizierung
schwach ist. Dies liegt daran, dass der Server den Benutzer- und
Hostnamen in der Übertragung
ohne Beweis als identifiziert annimmt. Ferner gibt es das Problem,
dass kein Zustand beibehalten wird, da jede Befehlstransaktion alleine
steht. Dies öffnet
diese Verfahren für „Wiedergabe-Attacken", bei denen ein Hacker
ein gültiges Netzwerkpaket
erfasst, einige Details ändert
(wie den Namen des Benutzers oder den Befehl, der auszuführen ist)
und dasselbe neu sendet.
-
Die
US-A-5,740,361 offenbart ein System und Verfahren zum Authentifizieren
von Benutzern und Diensten, die über
ein unsicheres Netzwerk kommunizieren. Jeder Benutzer und Dienst
hat eine Zugangsphrase, die für
Identifikation verwendet wird. Herausforderung-Antwort-Techniken
werden verwendet, um die Zugangsphrasen während des Authentifizierungsprozesses
geheim zu halten. Zugangsphrasen sind einer Identifikationsentität bekannt,
mit der der Dienst kommuniziert, um sowohl den Dienst als auch den
Benutzer zu identifizieren.
-
Die
WO98/03927A lehrt die Verwendung von persönlichen Informationsagenten,
um Agentenregel-basierte Befehle und Steuerung von Informations-Werten
in einer Computernetzwerkumgebung zu implementieren. Vertrauenswürdige elektronische Gemeinschaften
werden gebildet, in denen Mitglieder ihre digitalen Rollen befehlen
und steuern, und die vertrauenswürdige
Verwendung von Informations-Anteilen austauschen oder deren Wert
vermitteln.
-
Bis
jetzt hatten Netzwerksysteme jedoch nicht die Fähigkeit, flexible und erhöhte Sicherheit
für Web-Dokumente
auf dem Internet oder anderen Netzwerktypen zu liefern.
-
Zusammenfassung
der Erfindung
-
Bestimmte
Objekte, Vorteile und neuartige Merkmale der Erfindung werden teilweise
in der folgenden Beschreibung offensichtlich und werden für Fachleute
auf diesem Gebiet bei der Untersuchung des Folgenden teilweise offensichtlich
oder können bei
der Anwendung der Erfindung erlangt werden. Die Objekte und Vorteile
der Erfindung können
realisiert und erhalten werden durch die Vorrichtungen und Kombinationen,
die in den angehängten
Ansprüchen
besonders dargestellt sind.
-
Bei
einem ersten Aspekt schafft die vorliegende Erfindung ein Verfahren
zum Sichern von Web-Ressourcen in einem Netzwerksystem, wobei das
Verfahren folgende Schritte umfasst: Erzeugen eines einmaligen Tokens,
jedes Mal, wenn ein Klientbrowser eine Dienstanforderung empfängt; Senden des
einmaligen Tokens an einen Sicherheitsserver, jedes Mal, wenn der
Klientbrowser auf die Dienstanforderung anspricht; Senden der Dienstanforderung und
des einmaligen Tokens an einen Anwendungsserver zum Erfüllen der
Dienstanforderung, wobei der Anwendungsserver das einmalige Token
an den Sicherheitsserver weiterleitet, um das einmalige Token zu
verifizieren; Empfangen eines angeforderten Dienstes von dem Anwendungsserver,
wenn eine Übereinstimmungsmitteilung
von dem Sicherheitsserver dem Anwendungsserver anzeigt, dass das einmalige
Token von dem Klientbrowser und das einmalige Token von dem Anwendungsserver übereinstimmen;
und Empfangen einer Fehlermitteilung von dem Anwen dungsserver, wenn
eine vorbestimmte Auszeitperiode abläuft, zwischen dem Zeitpunkt, wenn
das einmalige Token von dem Klientbrowser empfangen wird und wenn
das zweite einmalige Token von dem Anwendungsserver empfangen wird.
-
Das
Erzeugen eines einmaligen Tokens kann ferner das Verwenden eines
Zufallszahlgenerators umfassen, um das einmalige Token zu erzeugen. Eine
Tornummer für
die Sicherheitsserververbindung zu dem Klientbrowser kann bestimmt
werden, und diese Tornummer kann dem einmaligen Token hinzugefügt werden.
-
Der
Klientbrowser kann mit dem Sicherheitsserver registriert werden.
-
Bei
einem weiteren Aspekt schafft die vorliegende Erfindung ein System
zum Liefern von Sicherheit von Web-Ressourcen an eine Klientvorrichtung, das
jedes Mal ein einmaliges Token erzeugt, wenn die Klientvorrichtung
eine Dienstanforderung erzeugt, und ein Anwendungsgerät zum Liefern
eines angeforderten Dienstes, wobei das Computersystem folgende
Merkmale umfasst: eine Sicherheitsvorrichtung zum Verifizieren des
einmaligen Tokens, das durch die Klientvorrichtung mit der Dienstanforderung
erzeugt wurde, wobei die Sicherheitsvorrichtung ferner folgende
Merkmale umfasst: einen ersten Sicherheitsmechanismus, der das einmalige
Token, das von der Klientvorrichtung empfangen wurde, und ein zweites
einmaliges Token, das von der Anwendungsvorrichtung empfangen wurde,
vergleicht; einen zweiten Sicherheitsmechanismus, der eine Übereinstimmungsmitteilung
erzeugt, wenn das einmalige Token, das von der Klientvorrichtung
empfangen wurde, und das zweite einmalige Token, das von der Anwendungsvorrichtung
empfangen wurde, übereinstimmen,
wobei die Übereinstimmungsmitteilung
die Anwendungsvorrichtung autorisiert, den angeforderten Dienst
an die Klientvorrichtung zu liefern, wenn die Übereinstimmungsnotiz empfangen
wird; und einen dritten Sicherheitsmechanismus, der eine Nicht-Übereinstimmungsmitteilung erzeugt,
wenn eine vorbestimmte Auszeitperiode abläuft, zwischen dem Zeitpunkt,
wenn das einmalige Token von der Klientvorrichtung empfangen wird,
und wenn das zweite einmalige Token von der Anwendungsvorrichtung
empfangen wird, wobei die Nicht-Übereinstimmungsmitteilung
die Anwendungsvorrichtung daran hindert, den angeforderten Dienst
an die Klientvorrichtung zu liefern, wenn die Nicht-Übereinstimmungsmitteilung
empfangen wird.
-
Der
dritte Sicherheitsmechanismus kann die Nicht-Übereinstimmungsmitteilung
erzeugen, wenn das einmalige Token, das von dem Klientbrowser empfangen
wird und das zweite einmalige Token, das von dem Anwendungsserver
empfangen wird, nicht übereinstimmen.
-
Das
System kann ferner einen vierten Sicherheitsmechanismus zum Empfangen
des einmaligen Tokens von der Klientbrowser-Vorrichtung und einen fünften Sicherheitsmechanismus
zum Empfangen des zweiten einmaligen Tokens von der Anwendungsvorrichtung
umfassen. Alternativ kann das System einen vierten Sicherheitsmechanismus
umfassen, zum Senden der Mitteilung, die erzeugt wurde, an den Anwendungsserver,
um anzuzeigen, ob die Dienstanforderung verifiziert ist.
-
Kurze Beschreibung
der Zeichnungen
-
Die
beiliegenden Zeichnungen, die einen Teil der Beschreibung bilden
und in derselben enthalten sind, stellen mehrere Aspekte der vorliegenden
Erfindung dar, und dienen zusammen mit der Beschreibung dazu, die
Prinzipien der Erfindung zu erklären.
-
1 ist
ein Blockdiagramm des Klient/Server-Systems, das das Internet verwendet.
-
2 ist
ein Blockdiagramm, das ein Browser-Programm darstellt, das in einem
computer-lesbaren Medium angeordnet ist, beispielsweise in einem
Computersystem der Klient-Systeme.
-
3 ist
ein Blockdiagramm, das ein Dienstanwendungsprogramm eines Servers,
das CGI-BIN-Programm und den Sicherheitsserver darstellt, die in
einem computerlesbaren Medium angeordnet sind, beispielsweise in
einem Computersystem der Serversysteme.
-
4 ist
ein Blockdiagramm, das den Prozess für Klientbrowser und die Serveranwendung des
Servers, das CGI-BIN-Programm und die Sicherheitsserverprozesse
darstellt, wie es in 2 und 3 gezeigt
ist.
-
5 ist
ein Flussdiagramm des Prozesses für den Klientbrowser der vorliegenden
Erfindung, wie es in 4 gezeigt ist.
-
6 ist
ein Flussdiagramm des Prozesses für die Serveranwendung des Servers
der vorliegenden Erfindung, wie es in 4 gezeigt
ist.
-
7 ist
ein Flussdiagramm des Prozesses für das Sicherheitsserverprogramm
der vorliegenden Erfindung, wie es in 4 gezeigt
ist.
-
8 ist
ein Flussdiagramm des Prozesses für den CGI-BIN-Programmprozess der vorliegenden Erfindung,
wie es in 4 gezeigt ist.
-
Detaillierte
Beschreibung des bevorzugten Ausführungsbeispiels
-
Die
vorliegende Erfindung wird nun mit besonderer Bezugnahme auf die
Zeichnungen näher beschrieben.
Obwohl die Erfin dung in Verbindung mit diesen Zeichnungen beschrieben
wird, gibt es keine Absicht, dieselbe auf das oder die hierin offenbarten Ausführungsbeispiele
zu begrenzen. Im Gegenteil, die Absicht ist es, alle Alternativen,
Modifikationen und Äquivalente
abzudecken, die in der Offenbarung enthalten sind, wie sie durch
die angehängten
Ansprüche
definiert ist.
-
Mit
Bezugnahme auf die Zeichnungen ist 1 ein Blockdiagramm
von nur einer Systemkonfiguration, die die Flexibilität, Erweiterbarkeit
und Plattformunabhängigkeit
der vorliegenden Erfindung darstellt. Obwohl die Systemkonfiguration
viele Formen annehmen könnte,
stellt das Diagramm von 1 eine Mehrzahl von unterschiedlichen
Workstationen 12, 14 und 16 dar, die
direkt mit einem Netzwerk verbunden sind, beispielsweise, aber nicht
begrenzt auf, einem LAN 18. Zusätzliche Workstationen 21, 22 können gleichartig
entfernt angeordnet sein und in Kommunikation mit dem Netzwerk 18 sein, durch
eine Einwähl-
oder andere Verbindung 24. Jede der Workstationen in 1 ist
einzeln dargestellt, um zu betonen, dass Workstationen eine unterschiedliche
Hardware-Plattform umfassen können.
-
Wie
es gut bekannt ist, sind Browser-Anwendungen für eine Vielzahl von Hardware-Plattformen vorgesehen
und ohne weiteres verfügbar.
Browser sind üblicherweise
bekannt für
ihren Nutzen zum Zugreifen auf Informationen über das Internet 32.
Wie es vorher erwähnt
wurde, ist ein Browser eine Vorrichtung oder eine Plattform, die
es einem Benutzer ermöglicht,
eine Vielzahl von Dienstsammlungen zu betrachten. Der Browser gewinnt
Informationen von einem Web-Server 31 oder Netzwerk-Server 26 wieder,
unter Verwendung von HTTP, interpretiert dann HTML-Code, formatiert
und zeigt das interpretierte Ergebnis auf einer Workstationanzeige
an.
-
Zusätzliche
Workstationen 33 und 34 können gleichartig angeordnet
sein und in Kommunikation sein mit den Web- Servern 31, für einen
Zugriff auf Webseiten auf dem lokalen Server und dem Internet. Workstationen 33 und 34 kommunizieren
mit dem Web-Server 31 auf einem LAN-Netzwerk 35.
Die Netzwerke 18 und 35 können beispielsweise Ethernet-Typ-Netzwerke sein, auch
bekannt als 10 BASE 2, 10 BAS 5, 10 BSAF, 10 BAST, BASE BAN network, CO-EX
cable, und dergleichen.
-
Wie
es in 2 dargestellt ist, umfassen Klient-Systeme heutzutage
allgemein nur ein Browser-Programm 100 (z. B. Netscape,
Internet-Explorer oder ein anderes Browser-Programm) für die Verwendung beim Zugreifen
auf Positionen auf einem Netzwerk 11. Diese Browser-Programme 100 befinden
sich in einem Computerspeicher 51 und greifen auf ein Kommunikationseinrichtungsmodem 47 zu, um
den Benutzer zu anderen Ressourcen zu bringen, die mit dem Netzwerk 11 verbunden
sind. Um eine Ressource zu finden, sollte der Benutzer die Netzwerkposition
der Ressource kennen, die durch einen Netzwerkpositionsidentifizierer
oder URL (URL = Uniform Resource Locator) bezeichnet ist. Diese Identifizierer
sind häufig
kryptisch und folgen sehr komplexen Schemata und Formaten in ihren
Benennungskonventionen.
-
Systeme
identifizieren heutzutage diese Ressourcen, greifen auf dieselben
zu und verarbeiten, dieselben, die durch einen Benutzer gewünscht werden,
durch Verwenden des Prozessors 41, der Speichervorrichtung 42 und
des Speichers 51 mit einem Betriebssystem 52 und
einem Fensterverwalter 53. Der Prozessor nimmt Daten von
dem Speicher 51 und der Speicherung 42 über den
Bus 43 an. Anordnungen von dem Benutzer können signalisiert
werden durch Verwenden der Eingabegeräte Maus 44 und Tastatur 45.
Die Aktionseingabe und Ergebnisausgabe werden auf dem Anzeigeanschluss 46 angezeigt.
-
Das
erste Ausführungsbeispiel
der vorliegenden Erfindung umfasst das Browser-Programm 100.
Das Browser-Programm 100 ist die Software, die mit dem
Server interagiert, um die erforderlichen Daten und erforderliche
Funktionalität
zu erhalten, die durch den Klient-Benutzer angefordert werden. Das
Klientbrowser-Programm 100 wird hierin nachfolgend mit
Bezugnahme auf 4 und 5 näher beschrieben.
-
In 3 ist
die Architektur des Serversystems 26 und 31 dargestellt.
Der Hauptunterschied zwischen den Servern 31 und 26 und
den Klienten 12, 16, 21, 22, 33 und 34,
die in 1 dargestellt sind, ist, dass die Klient-Systeme
eine Schnittstelle bilden mit dem Benutzer und die Funktionalität anfordern
durch das Browser-Programm 100, während die Server 26 und 31 die
Dienste liefern, die durch das Klient-System angefordert werden, unter Verwendung
des Serveranwendungsprogramms 120, des Sicherheitsservers 140 und
des CGI-BIN-Programms 160.
-
Ansonsten
sind die Funktionalität
des Prozessors 61, der Speicherung 62, der Maus 64,
der Tastatur 65, der Anzeige 66 und des Modems 67 im Wesentlichen
gleich wie entsprechende Elemente von 2, die oben
beschrieben sind. Wie es in der Technik bekannt ist, können sich
die Klient-Systeme 12, 14, 16, 21, 22, 33 und 34 und
die Dienst-Systeme 26 und 27 auf
der gleichen physikalischen Maschine befinden.
-
Der
Hauptunterschied bei dem Server ist, dass der Speicher 71,
der mit dem Betriebssystem 72 und dem Fensterverwalter 37 interagiert,
die Dienste liefert, die durch den Klient angefordert werden, unter Verwendung
der Serveranwendung 120, des CGI-BIN-Programms 160 und
des Sicherheitsservers 140. Die Serveranwendung 120,
das CGI-BIN-Programm 160 und der Sicherheitsserver 140 werden
hierin mit Bezugnahme auf 4 und 6, 7 und 8 näher definiert.
-
Mit
Bezugnahme auf 4 kann das Klient-System 12, 16, 21, 22, 33 oder 34 Dienste
von dem Web-Server 31 anfordern durch Verwenden des Klient-System-Browser-Programms 100.
Das Browser-Benutzer-Schnittstellenprogramm empfängt zuerst eine Anforderung
von dem Benutzer und prüft, um
sicherzustellen, dass der Benutzer befugt ist, auf eine bestimmte
Funktion zuzugreifen.
-
Als
Nächstes
erzeugt der Web-Browser ein Token durch Verwenden jedes geeigneten
Algorithmus und Generators. Bei dem bevorzugten Ausführungsbeispiel
ist der Token keine fortlaufende Zahl, sondern ist in der Tat eine
Zahl, die durch einen Zufallszahlgenerator erzeugt wird.
-
Der
Klient-Benutzer-Schnittstellen-Browser verbindet mit dem Sicherheitsserver.
Diese Verbindung kann beispielsweise durch Verwenden von Sockets
erreicht werden. Die Klient-Benutzer-Schnittstelle 100 sendet
das Token an den Sicherheitsserver 140 unter Verwendung
der hergestellten Verbindung. Als Nächstes führt der Klient-Benutzer-Schnittstellen-Browser 100 einen
Aufruf an die Dienstanwendung für
einen Dienst durch, und sendet das Token an die Dienstanwendung
als eines der Argumente für den
angeforderten Dienst. Diese Dienstanforderung geht auf einer Netzwerkleitung
zu dem Server 31 und wird durch die Serveranwendung 120 empfangen.
-
Die
Serveranwendung 120 empfängt eine Dienstanforderung
von der Klient-Benutzer-Schnittstelle 100. Als Nächstes findet
die Serveranwendung 120 das aufgeforderte Programm und
ruft das aufgeforderte Programm auf durch Aufrufen der CGI-BIN-Anwendung 160 unter
Verwendung des Programmnamens und der –argumente.
-
Das
CGI-BIN-Anwendungsprogramm 160 empfängt die Programmnamen-Ausführungsargumente.
Vor dem Ausführen
der angeforderten Subroutine, die den angeforderten Dienst liefert,
richtet das CGI-BIN-Programm 160 ein Socket mit dem Sicherheitsserver 140 ein.
Sobald das Socket mit dem Sicherheitsserver 140 eingerichtet
ist, sendet das CGI-BIN-Anwendungsprogramm 160 eine
Token-Verifizierungsanforderung an den Sicherheitsserver 140.
-
Der
Sicherheitsserver 140 richtet auf die Initialisierung hin
stellt eine Hör-Socket
ein. Der Sicherheitsserver 140 wartet, um ein Token von
der Klient-Benutzer-Schnittstelle 100 zu empfangen, auf dem
Socket, das auf der Verbindung eingerichtet wurde, die erzeugt wurde,
wenn der Klient-Benutzer 100 verifiziert
wurde. Sobald ein Token von der Klient-Benutzer-Schnittstelle empfangen
wird, wird derselbe zu der Token-Verifizierungstabelle des Sicherheitsservers
hinzugefügt.
Der Sicherheitsserver 100 wartet, um eine Token-Verifizierungsanforderung
von dem CGI-BIN-Programm 160 auf einem CGI-BIN-Token-Verifizierungs-Socket
zu empfangen. Wenn die Anforderung, ein Token zu verifizieren, von
dem CGI-BIN-Programm 160 empfangen wird, prüft der Sicherheitsserver 140 die
Token-Verifizierungstabelle und sendet eine Mitteilung an das CGI-BIN-Programm 160 zurück, darüber, ob
das Token von der Klient-Benutzer-Schnittstelle empfangen wurde
oder nicht, und daher ein gültiges
Token ist.
-
Wenn
das CGI-BIN-Programm 160 die Token-Verifizierungsmitteilung von dem Sicherheitsserver 140 empfängt, prüft das CGI-BIN-Programm 160 die
Autorisierung des Tokens. Falls die Token-Autorisierungsmitteilung,
die von dem Sicherheitsserver 140 empfangen wird, zufriedenstellend
ist, dann führt das
CGI-SIN-Programm 160 die angeforderte Operation aus und
schreibt die Ausgabe an ein stdout, das dann zu einer Serveranwendung 120 zurückgesendet
wird. Falls die Token-Autorisierungsmitteilung, die von dem Sicherheitsserver 140 empfangen
wird, nicht zufriedenstellend ist, dann wird eine Fehlermitteilung
an die Serveranwendung 120 gesendet. Wenn die Ausgabe an
die Serveranwendung 120 gesendet wird, dann endet das CGI-BIN-Programm 160 und
hört daher
auf, zu existieren.
-
Die
Serveranwendung 120 empfängt die Ausgabe der CGI-BIN-Anwendung 160 und
den Ende-Status des CGI-BIN-Anwendungsprogrammprozesses 160 und
sendet die Ausgabe über ein
Netzwerk zu dem Klientbrowser-Programm 100 zurück. Das
Browser-Programm 100 sendet dann die Ausgabe zu dem Anwendungsprogramm
zurück,
das den Dienst in dem Klient-System 12 angefordert hat.
Dieser Prozess wird hierin nachfolgend mit Bezugnahme auf 5–9 näher
erklärt.
-
Der
Prozess, der durch das Browser-Programm 100 in dem Klient-System 12 implementiert wird,
ist in 5 dargestellt. Der erste Schritt des Browser-Programms 100 ist
es, das Klientbrowser-Programm 100 bei Schritt 101 zu
initialisieren. Das Browser-Programm 100 akzeptiert dann
das Login des Benutzernamens und Passworts von dem Benutzer und
erzeugt eine Verbindung zu dem Sicherheitsserver 140 bei
Schritt 102. Das Browser-Programm 100 empfängt die
Dienstanforderung von dem Benutzer bei Schritt 103.
-
Das
Browser-Programm 100 erzeugt bei Schritt 104 ein
Token. Bei dem bevorzugten Ausführungsbeispiel
ist das Token eine Zufallszahl, die von einer Zufallszahlerzeugungsfunktion
erzeugt wird. Es ist jedoch in der Technik bekannt, dass es andere Verfahren
zum Erzeugen eines einmaligen Tokens gibt, die verwendet werden
können.
-
Das
Benutzer-Browser-Programm 100 sendet dann das Token, das
in Schritt 104 erzeugt wurde, bei Schritt 105 an
den Sicherheitsserver 140. Das Browser-Programm 100 empfängt die
Dienstanforderung von dem Benutzer bei Schritt 103. Das
Browser-Programm 100 verbindet mit der Serveranwendung 120 bei
Schritt 106. Das Browser-Programm 100 macht einen
Aufruf zu der Serveranwendung 120 und sendet das Token
als Argumentdaten bei Schritt 107 an die Serveranwendung 120.
Das Benutzer-Browser-Programm 100 wird dann ausgesetzt, bis
zu dem Zurücksenden
der Daten bei Schritt 108.
-
Wenn
Daten zu der Klient-Benutzer-Schnittstelle zurückgesendet werden, ist das
Browser-Programm 100 bei Schritt 88 nicht ausgesetzt,
und das Browser-Programm 100 zeigt die Daten, die von der Serveranwendung 120 empfangen
wurden, dem Benutzer bei Schritt 109 an. Der Klient-Benutzer-Schnittstellen-Browser 100 kehrt
dann zu Schritt 103 zurück
und wartet auf die nächste
Dienstanforderung von dem Benutzer.
-
In 6 ist
das Flussdiagramm der Architektur und des Prozesses dargestellt,
der durch die Serveranwendung 120 implementiert ist. Die
Serveranwendung 120 wird bei Schritt 121 initialisiert.
Die Serveranwendung 120 wartet, um bei Schritt 122 eine Klient-Dienstanforderung
zu empfangen.
-
Wenn
eine Klient-Anforderung bei Schritt 122 empfangen wird,
bestimmt die Serveranwendung 120, welches Anwendungsprogramm 100 den Dienst
liefern wird, der durch das Klient-System angefordert wird, und die Serveranwendung 120 verbindet
mit der spezifizierten CGI-BIN-Anwendung 160 bei Schritt 123.
Die Serveranwendung 120 ruft die spezifizierte CGI-BIN-Anwendung 160 mit
den spezifizierten Argumenten auf, wovon eine das Token ist, und
sendet die notwendigen Daten bei Schritt 124. Der Prozess
der Serveranwendung 120 wird bei Schritt 125 ausgesetzt,
bis Daten von der spezifizierten CGI-BIN-Anwendung 160 empfangen
werden.
-
Wenn
die Ausgabe von der spezifizierten CGI-BIN-Anwendung 160 empfangen
wird, empfängt die
Serveranwendung 120 die Ausgabe bei Schritt 126.
Die Serveranwendung 120 schreibt dann die Ausgabe, die
von der CGI-BIN-Anwendung 160 empfangen wird, und sendet
diese Ausgabe zurück
zu dem Klientanforderungsdienst bei Schritt 127. Die Serveranwendung 120 verlässt dann
diese Sitzung, kehrt in einer Schleife zurück zu Schritt 122 und
setzt sich selber aus, bis eine neue Anforderung empfangen wird.
-
Mit
Bezug auf 7 ist der Prozess des Sicherheitsservers 140 gezeigt.
Zunächst
wird der Sicherheitsserver 140 bei Schritt 141 initialisiert.
Als Nächstes
nimmt der Sicherheitsserver 140 eine Verbindung von einem
Benutzer-Browser 100 an, durch Erhalten des Benutzer-Login-Namens
und Pass worts bei Schritt 142. Der Sicherheitsserver 140 authentifiziert
dann den Benutzernamen und das Passwort. Sobald die Authentifizierung
des Login-Benutzernamens und Passworts abgeschlossen ist, setzt der
Sicherheitsserver 140 aus, bis er ein Token von einer Klient-Benutzer-Schnittstelle
auf der Socket-Verbindung bei Schritt 143 empfängt.
-
Der
Sicherheitsserver 140 nimmt das Verbindungs-Socket von
dem CGI-BIN-Programm 160 bei Schritt 144 an. Als
Nächstes
empfängt
der Sicherheitsserver 140 eine Token-Verifizierungsanforderung von dem CGI-BIN-Programm 160 auf
der CGI-BIN-Socket bei Schritt 145. Der Sicherheitsserver 140 verifiziert
das Token, das von dem CGI-BIN-Programm auf der CGI-BIN-Socket empfangen
wurde, mit dem Token, das von der Klient-Benutzer-Schnittstelle
auf einem Socket bei Schritt 143 empfangen wurde.
-
Falls
das Token, das bei Schritt 143 empfangen wurde, übereinstimmt
mit dem Token, das bei Schritt 145 empfangen wurde, ist
die Token-Verifizierung erfolgreich. Falls das Token, das von der
Klient-Benutzer-Schnittstelle auf einem Socket bei Schritt 143 empfangen
wurde, nicht mit dem Token übereinstimmt,
das bei Schritt 145 von dem CGI-BIN-Programm 160 empfangen
wurde, dann versagt die Token-Verifizierung. Der Sicherheitsserver 140 wartet
eine vorbestimmte Zeitperiode, dass die Token-Verifizierungsanforderung
von dem CGI-BIN-Programm 160 ankommt, vor der Zeitüberschreitung.
Jede nachfolgende Token-Verifizierungsanforderung von dem CGI-BIN-Programm 160 auf
einem Token, das die Zeit überschritten
hat, führt
zu einem Token-Verifizierungsausfall.
-
Das
Ergebnis der Token-Verifizierungsaufgabe wird bei Schritt 147 an
das CGI-BIN-Programm 160 gesendet, und der Sicherheitsserver 140 schließt das bei
Schritt 144 erzeugte CGI-BIN-Socket. Der Sicherheitsserver
kehrt dann zu Schritt 143 zurück, um zu warten, bis derselbe
ein weiteres Token von einer Benutzer-Klient-Schnittstelle empfängt.
-
In 8 ist
das Flussdiagramm für
die CGI-BIN-Anwendung 160 dargestellt. Zunächst wird die
CGI-BIN-Anwendung 160 bei Schritt 161 initialisiert.
Die CGI-BIN-Anwendung 160 empfängt die Anforderung für den angeforderten
Dienst mit dem Programmnamen und -argumenten, einschließlich des Tokens
bei Schritt 163. Die CGI-BIN-Anwendung 160 richtet
bei Schritt 163 ein Socket zu dem Sicherheitsserver 140 ein.
Bei dem bevorzugten Ausführungsbeispiel
ist ein TCP/IP-Socket eingerichtet.
-
Die
CGI-BIN-Anwendung 160 sendet das Token, das von der Serveranwendung 120 empfangen wird,
an den Sicherheitsserver 140 für eine Verifizierung bei Schritt 164.
Das CGI-BIN-Programm 160 setzt
das Verarbeiten aus, bis zur Rückkehr
der Token-Verifizierungsmitteilung von dem Sicherheitsserver bei
Schritt 165.
-
Sobald
die Token-Verifizierungsmitteilung von dem Sicherheitsserver 140 empfangen
wurde, wird bei Schritt 166 ein Test an der Token-Verifizierung
durchgeführt.
Falls das Token durch den Sicherheitsserver 140 verifiziert
wurde, dann fließt
der Prozess zu Schritt 167, bei dem das CGI-BIN-Programm 160 das
angeforderte Dienstprogramm ausführt. Nachdem
das angeforderte Dienstprogramm bei Schritt 167 ausgeführt wurde,
empfängt
das CGI-BIN-Programm 160 die stdout- und Standardfehler-Mitteilungen
von dem angeforderten Dienstprogramm bei Schritt 168. Das
CGI-BIN-Programm 160 sendet die stdout- und Standardfehler-Daten
an die Serveranwendung 120 bei Schritt 169 und
endet dann bei Schritt 172.
-
Falls
die Token-Verifizierungsprüfung
bei Schritt 166 dazu führt,
dass das Token nicht verifiziert wird, dann sendet das CGI-BIN-Programm 160 eine Fehlermitteilung
an die Serveranwendung 120, die anzeigt, dass die Token-Verifizierung mit
dem Sicherheitsserver 140 ausgefallen ist. Die CGI-BIN-Anwendung 160 endet
dann ihre Ausführung
bei Schritt 172.
-
Bei
einem alternativen Ausführungsbeispiel sendet
das CGI-BIN-Programm 160 den
Sicherheitspegel des Befehls, der ausgeführt wird, an den Sicherheitsserver 140,
zusammen mit dem Token. Der Sicherheitsserver 160 verifiziert
das Token und prüft auch
den Sicherheitspegel des Klient-Benutzers 100. Um sicherzustellen,
dass der Sicherheitsserver 140 den richtigen Klient-Benutzer 100 prüft, würde das Token
aus der Zufallszahl + Torzahl der Verbindung der Benutzerschnittstelle
mit dem Sicherheitsserver 140 bestehen. Der Sicherheitspegel
des Klient-Benutzers 100 wird zu dem Zeitpunkt bestimmt,
wenn der Sicherheitsserver 140 den Klient-Benutzer 100 auf
der anfänglichen
Verbindung zu dem Sicherheitsserver 140 authentifiziert.
-
Die
vorhergehende Beschreibung wurde zu Darstellungs- und Beschreibungszwecken
präsentiert.
Dieselbe soll nicht erschöpfend
sein oder die Erfindung auf die genau offenbarte Form begrenzen. Offensichtliche
Modifikationen oder Variationen hinsichtlich der obigen Lehren sind
möglich.
Das hier diskutierte Ausführungsbeispiel
oder die Ausführungsbeispiele
wurden gewählt
und beschrieben, um die beste Darstellung der Prinzipien der Erfindung und
deren praktische Anwendung zu liefern, um es dadurch einem Durchschnittsfachmann
auf diesem Gebiet zu ermöglichen,
die Erfindung in verschiedenen Ausführungsbeispielen und mit verschiedenen Modifikationen
zu verwenden, wie sie für
die bestimmte in Betracht gezogene Verwendung geeignet sind. Alle
solchen Modifikationen und Variationen liegen innerhalb des Schutzbereichs
der Erfindung, wie er durch die angehängten Ansprüche bestimmt ist, wenn dieselben
gemäß der Breite
interpretiert werden, die ihnen tatsächlich und rechtlich zusteht.