-
HINTERGRUND DER ERFINDUNG
-
1. Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft das Gebiet der elektronischen Authentifizierung.
Insbesondere betrifft die vorliegende Erfindung Verfahren und Systeme
für die
Authentifizierung über
mehrere Proxy-Server, die verschiedene Authentifizierungsdaten wie
beispielsweise Benutzerkennung und Passwort anfordern.
-
2. Hintergrund
und Stand der Technik
-
Ein „Proxy-Server" oder ein „Proxy" ist ein Computer
oder ein Computersystem, der/das als ein Vermittler zwischen einem
Client-Computersystem (im Folgenden als ein „Client" bezeichnet) und einem Server-Computersystem
(im Folgenden als ein „Server" bezeichnet) agiert.
Wenn ein Client eine Anforderung zu einem Server sendet, fordert
der Proxy, den die Anforderung passieren muss, möglicherweise eine Authentifizierung
des Clients an, die unabhängig
von der Authentifizierung des Clients ist, die durch den Server
angefordert wird. Eine typische Art und Weise für den Client (oder einen Benutzer
davon), sich bei dem Proxy zu authentifizieren, besteht darin, dem
Proxy Authentifizierungsdaten, wie beispielsweise eine Benutzerkennung
(ID) und ein Passwort bereitzustellen. Wenn das Authentifizieren bei
dem Server durchgeführt
wird, kann der Client dem Server auch eine separate Benutzerkennung und
ein Passwort bereitstellen.
-
Der
Internet-Standard HyperText Transport Protocol (HTTP) stellt ein
Transportschichtprotokoll für
das Kommunizieren zwischen einem Client und einem Server bereit.
So stellt HTTP unter anderem ein Mittel für die Authentifizierung bei
einem Proxy bereit, selbst wenn dieser Proxy andere Authentifizierungsdaten
als der Server anfordert. Das herkömmliche HTTP lässt ein
Header-Feld zu, das eine Benutzerkennung und ein Passwort zum Authentifizieren bei
dem Proxy enthalten kann. HTTP lässt
darüber hinaus
auch einen separaten Header zu, der eine separate Benutzerkennung
und ein Passwort zum Authentifizieren bei dem Server enthalten kann.
Selbst wenn HTTP-Anforderungen
von dem Client mehrere Proxys passieren, die Authentifizierung auf
dem Weg zu dem Server anfordern, kann, so lange die Proxys jeweils
dieselbe Benutzerkennung und dasselbe Passwort anfordern (wie dies
oftmals der Fall ist, wenn mehrere Proxys durch dieselbe Einheit
verwaltet werden), der Header, der das Passwort für den Proxy
enthält,
zum Authentifizieren bei einem jeden Proxy verwendet werden. Auf
diese Weise ermöglichen
es herkömmliche
Verfahren, dass HTTP zum Authentifizieren bei einem einzelnen Proxy
(oder bei mehreren Proxys, die dieselbe Benutzerkennung und dasselbe
Passwort anfordern) und bei einem Server verwendet werden kann.
-
Diese
herkömmlichen
Verfahren weisen einige Vorteile auf, zu denen beispielsweise der
gehört, dass
sie die Authentifizierung bei mehreren Proxys innerhalb eines einzelnen
Verwaltungsbereiches zulassen, von denen alle dieselben Passwörter verwenden.
Diese herkömmlichen
Verfahren lassen jedoch dann die Authentifizierung über mehrere
Proxy nicht zu, wenn diese Proxys im Vergleich miteinander verschiedene
Authentifizierungsdaten anfordern.
-
Oftmals
können
Proxys, die innerhalb eines gemeinsamen Vertrauensbereiches vorhanden
sind, dieselbe Benutzerkennung und dasselbe Passwort verwenden,
wenn sie einen bestimmten Benutzer authentifizieren. So können beispielsweise
Proxys, die durch dieselbe Einheit verwaltet werden, oftmals dieselbe
Benutzerkennung und dasselbe Passwort zum Authentifizieren eines
bestimmten Benutzers verwenden. Es kann jedoch wünschenswert sein, es Proxys
zwischen dem Client und dem Server zu ermöglichen, verschiedene Authentifizierungsdaten
zu verwenden, wenn der Benutzer des Clients authentifiziert wird.
So sei beispielsweise angenommen, dass der Client eine Funkvarrichtung
und der Server ein Unternehmensserver ist. Die Funkvorrichtung kann über einen
Proxy, der durch den Funkdienst verwaltet wird, ebenso wie durch
einen Proxy, der durch das Unternehmen verwaltet wird, das der Host
des Unternehmensservers ist, kommunizieren. Der Funkdienst und der
Unternehmensserver vertrauen einander möglicherweise nicht so weit,
dass sie eine gemeinsame Benutzerkennung und ein gemeinsames Passwort
für einen
jeweiligen Benutzer gemeinsam nutzen.
-
Aus
diesem Grund sind Systeme und Verfahren für die Authentifizierung über mehrere
Proxys erwünscht,
selbst wenn diese mehreren Proxys verschiedene Benutzerkennun gen
und Passwörter
beim Authentifizieren anfordern. Es wäre darüber hinaus wünschenswert,
wenn eine solche Authentifizierung so ausgeführt werden könnte, dass
jeder Proxy nur auf die Authentifizierungsdaten zugreifen kann,
die für
die Authentifizierung bei diesem bestimmten Proxy relevant sind,
und dass er nicht in der Lage ist, auf andere Authentifizierungsdaten
zuzugreifen, die für andere
Proxys bestimmt sind. Es wäre
darüber
hinaus wünschenswert,
wenn eine solche Authentifizierung ohne Modifizierung vorhandener
Protokolle und Standards durchgeführt werden könnte.
-
M.
Norifusa, „Internet
Security: Difficulties and Solutions", International Journal of Medical Informatics
49 (1998) S. 69-74 beschreibt verschiedene Lösungen für die Internetsicherheit. Es
kann ein SOCKS5-VPN über
eine Proxy-Kette eingerichtet werden, wobei die Proxy-Kette eine
Verbindung zwischen einem Client und einem Anwendungsserver über mehrere
SOCKS5-Server ist. Es kann eine Benutzerauthentifizierung bei allen
oder einigen der Gateways angefordert werden. Jeder SOCKS5-Server
in dem VPN (virtual private network) kann einen Benutzer authentifizieren,
und wenn mehrere Authentifizierungen angefordert werden, wird eine
erneute Authentifizierung zwischen dem Benutzer und diesem SOCKS5-Server
durchgeführt.
Es wird beschrieben, dass dies die Kommunikation zwischen mehreren
Netzwerken mit verschiedenen Sicherheitsprozeduren und Entscheidungskriterien
vereinfacht. Es wird darüber
hinaus beschrieben, dass ein Extranet mit mehreren Benutzerauthentifizierungen und
Datenverschlüsselung
eingerichtet werden könnte.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Es
ist die Aufgabe der Erfindung, ein Verfahren zur Authentifizierung
bereitzustellen, das die voranstehend beschriebenen Probleme des
Standes der Technik löst,
und das im Besonderen einen Client dazu befähigt, mit einem Server selbst
dann zu kommunizieren, wenn sich der Client zuerst bei mehreren Proxys,
die verschiedene Authentifizierungsdaten anfordern, authentifizieren
muss.
-
Diese
Aufgabe wird durch die Erfindung gelöst, wie dies in den unabhängigen Ansprüchen beansprucht
wird.
-
Bevorzugte
Ausführungsbeispiele
sind in den abhängigen
Ansprüchen
definiert.
-
Es
werden Verfahren, Systeme, Computerprogrammerzeugnisse und Datenstrukturen
beschrieben, die die voranstehend beschriebenen Probleme des Standes
des Technik lösen.
Genauer gesagt, befähigen
die Prinzipien der vorliegenden Erfindung einen Client zum Kommunizieren
mit einem Server, selbst dann, wenn sich der Client zuerst bei mehreren
Proxys, die verschiedene Authentifizierungsdaten anfordern, authentifizieren
muss. Die Prinzipien der vorliegenden Erfindung lassen eine solche
Kommunikation zu, ohne dass Authentifizierungsdaten, die einen bestimmten
Proxy betreffen, irgendwelchen beliebigen Proxys offenbart werden müssen, die
dem ursprüngliche
Server näher
sind. Dementsprechend wird ein relativ hohes Maß an Vertraulichkeit zwischen
den mehreren Proxys aufrechterhalten. Zusätzlich dazu kann die vorliegende
Erfindung implementiert werden, ohne dass vorhandene Standards geändert werden
müssen,
obgleich die Art und Weise, wie diese Standards verwendet werden, einzigartig
und erfinderisch ist.
-
In Übereinstimmung
mit einer ersten Ausführungsform
der vorliegenden Erfindung sendet der Client eine Anforderung eines
Dienstes über
einen ersten Proxy ab. Diese erste Anforderung eines Dienstes kann
eine standardmäßige HTTP-Anforderung sein.
Der erste Proxy sendet anschließend
eine Authentifizierungsanforderung, wie beispielsweise eine 407-Proxy-Authentication-Response
gemäß dem HTTP
zurück.
-
Anschließend authentifiziert
der Client den Benutzer bei dem ersten Proxy (oder der ersten Gruppe
von Proxys, die alle dieselben Authentifizierungsdaten anfordern)
durch Empfangen von zunächst
der Authentifizierungsanforderung von dem ersten Proxy. Anschließend ruft
der Client die Authentifizierungsdaten ab, die zum Authentifizieren beim
ersten Proxy geeignet sind. Anschließend integriert der Client
diese Authentifizierungsdaten in eine weitere Anforderung eines
Dienstes und sendet anschließend
diese zweite Anforderung ab.
-
Der
erste Proxy (oder die erste Gruppe von Proxys, die alle dieselben
Authentifizierungsdaten anfordern), der passiert werden muss, empfängt die Anforderung
eines Dienstes, liest die geeigneten Authentifizierungsdaten und
leitet anschließend
die Anforderung eines Dienstes zu dem zweiten Proxy, der passiert
werden muss. Dieser zweite Proxy (oder die Gruppe von Proxys, die
wie alle dieselben Authentifizierungsdaten anfordern), fordert verschiedene
Authentifizierungsdaten von dem ersten Proxy an.
-
Aus
diesem Grund ist der zweite Proxy mit den in der Anforderung enthaltenen
Authentifizierungsdaten nicht zufrieden und ist, je nach dem Authentifizierungsprotokoll,
das verwendet wird, möglicherweise
nicht einmal in der Lage, die Authentifizierungsdaten in der Anforderung
zu lesen. Dementsprechend sendet der zweite Proxy eine Authentifizierungsanforderung über den
ersten Proxy zu dem Client zurück.
-
Anschließend authentifiziert
der Client den Benutzer bei dem zweiten Proxy durch Empfangen von
zunächst
der Authentifizierungsanforderung von dem zweiten Proxy. Anschließend ruft
der Client Authentifizierungsdaten, die zum Authentifizieren des zweiten
Proxy geeignet sind, ab. Anschließend integriert der Client
die Authentifizierungsdaten für
den ersten und den zweite Proxy in eine weitere Anforderung eines
Dienstes und sendet diese Anforderung eines Dienstes ab.
-
Der
erste Proxy empfängt
die Anforderung eines Dienstes, liest die geeigneten Authentifizierungsdaten
und leitet anschließend
die Anforderung eines Dienstes zu dem zweiten Proxy weiter, der
passiert werden muss. Der erste Proxy entfernt darüber hinaus
optional die ersten Authentifizierungsdaten aus der Anforderung
eines Dienstes, so dass die ersten Authentifizierungsdaten nicht
dem zweiten Proxy offenbart werden.
-
Der
zweite Proxy empfängt
anschließend
die Anforderung eines Dienstes, liest die geeigneten Authentifizierungsdaten
und leitet anschließend
die Anforderung eines Dienstes zu dem Server weiter, wenn keine
anderen Proxys vorhanden sind, die passiert werden müssen. Wenn
weitere Proxys vorhanden sind, die noch weitere Authentifizierungsdaten
anfordern, würde
der Prozess der Authentifizierung so lange wiederholt werden, bis
alle Proxys passiert worden sind.
-
Die
zweite Ausführungsform
ist der ersten Ausführungsform
in vielerlei Hinsicht ähnlich,
mit Ausnahme der folgenden Unterschiede. In der zweiten Ausführungsform
richtet der Client, anstatt die Anforderungen eines Dienstes über mehrere
Proxys abzusenden, eine Verbindungsanforderung direkt an den nächsten Proxy,
bei dem die Authentifizierung noch nicht durchgeführt worden
ist. Auf diese Weise richtet der Client zuerst eine Verbindungsanforderung
an den ersten Proxy, der mit einer Authentifizierungsanforderung
antwortet. Anschließend
richtet der Client eine Verbindungsanforderung an den zweiten Proxy,
wobei die Verbindungsanforderung die Authentifizierungsdaten für den ersten Proxy
enthält. Der
erste Proxy empfängt
die Verbindungsanforderungen, führt
Authentifizierung durch und tritt anschließend in einen Byte-Weiterleitmodus
ein, wodurch der erste Proxy dem Client transparent gemacht wird.
Die Verbindungsanforderung wird dem zu dem zweiten Proxy weitergeleitet,
der mit einer Authentifizierungsanforderung antwortet. Anschließend sendet
der Client eine Verbindungsanforderung zu dem Server, wenn keine
weiteren Proxys vorhanden sind, die passiert werden müssen. Die
Verbindungsanforderung würde
die Authentifizierungsdaten sowohl für den ersten als auch für den zweiten
Proxy enthalten. Wenn weitere Proxys vorhanden sind, die passiert
werden müssen,
werden so lange auf die hierein beschriebene Weise Verbindungsanforderungen
an darauffolgende Proxys gerichtet, bis alle Proxys passiert sind,
und es kann eine Verbindungsanforderung direkt an den Server gerichtet
werden, wobei die Verbindungsanforderung alle Authentifizierungsdaten
für alle
eingreifenden Proxys enthält.
-
Die
erste und die zweite Ausführungsform stützen sich
auf die Fähigkeit,
verschiedene Authentifizierungsdaten für verschiedene Proxys in eine
einzelne Anforderung zu integrieren. Um dies zu erreichen, wird
eine einzigartige Datenstruktur einer Anforderung beschrieben. Genauer
gesagt, wird eine HTTP-Anforderung so beschrieben, dass diese einen verbundenen
Authentifizierungs-Header, wie beispielsweise den „WWW-Authenticate-Response-Header" aufweist, der durch
das HTTP-Authentifizierungsverfahren
zugelassen wird. Die verschiedenen Authentifizierungsdaten werden
unter dem Authentifizierungs-Header integriert, wobei jeder Authentifizierungsdatensatz
für jeden
Proxy durch einen Bereich identifiziert wird, wie dies durch das
Authentifizierungsverfahren zugelassen ist. In dieser Anmeldung
wird ein jeweiliger Schritt „zugelassen" oder ist durch ein
jeweiliges Protokoll oder Verfahren „zulässig", wenn der jeweilige Schritt unter Verwendung
des Protokolls oder des Verfahrens durchgeführt werden kann, ohne gegen
Expressstandards für
das Protokoll oder das Verfahren zu verstoßen. Dies bedeutet weder, dass
das Protokoll oder das Verfahren die jeweilige Handlung beschreibt, noch
dass die Handlung in Anbetracht des Wissens über das Protokoll oder das
Verfahren offensichtlich ist. Wenn das Digest-Authentifizierungsverfahren
angewendet wird, werden die Authentifizierungsdaten nicht offen
gesendet, sondern sie werden verschlüsselt. Auf diese Weise kann
nur der geeignete Proxy die Authentifizierungsdaten lesen, die für diesen
Proxy relevant sind, wodurch auf diese Weise Vertraulichkeit zwischen
den Proxys aufrecht erhalten wird.
-
Dementsprechend
ermöglichen
es die Prinzipien der vorliegenden Erfindung einem Client, mit einem
Server selbst dann zu kommunizieren, wenn mehrere Proxys, die verschiedene
Authentifizierungsdaten anfordern, passiert werden müssen, um eine
solche Kommunikation herzustellen. Zusätzlich dazu kann eine solche
Authentifizierung erreicht werden, ohne dass die Authentifizierungsdaten
Proxys offenbart werden müssen,
die verglichen mit dem Proxy, für
den die Authentifizierungsdaten bestimmt sind, dem ursprünglichen
Server näher
sind. Zusätzlich
dazu kann die Authentifizierung erzielt werden, ohne dass vorhandene
Standards geändert
werden müssen.
-
Zusätzliche
Leistungsmerkmale und Vorteile der Erfindung werden in der folgenden
Beschreibung definiert, und sie werden zum Teil auch anhand der Beschreibung
offensichtlich, oder sie können
im Zuge der praktischen Umsetzung der Erfindung erfahren werden.
Die Leistungsmerkmale und Vorteile der Erfindung können mit
Hilfe der Mittel und Kombinationen, auf die insbesondere in den
angehängten Ansprüchen verwiesen
wird, umgesetzt und erzielt werden. Diese sowie weitere Leistungsmerkmale
der vorliegenden Erfindung werden anhand der folgenden Beschreibung
und der angehängten
Ansprüche offensichtlich
oder können
im Zuge der praktischen Umsetzung der Erfindung, wie dies im Folgenden
beschrieben wird, erfahren werden.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Um
die Art und Weise zu beschreiben, mit der die voranstehend erwähnten sowie
weitere Vorteile und Leistungsmerkmale der Erfindung erzielt werden
können,
wird eine ausführlichere
Beschreibung der Erfindung, die voranstehend kurz beschrieben wurde,
in Bezug auf spezifische Ausführungsformen
davon, die in den beigefügten
Zeichnungen illustriert sind, gegeben. In dem Wissen, dass diese Zeichnungen
lediglich typische Ausführungsformen der
Erfindung darstellen und aus diesem Grund nicht als den Umfang derselben
einschränkend
zu erachten sind, wird die Erfindung durch die Verwendung der beigefügten Zeichnungen
mit zusätzlicher
Genauigkeit und Ausführlichkeit
beschrieben und erläutert.
-
In
den Zeichnungen illustriert:
-
1 ein
exemplarisches System, das eine geeignete Betriebsumgebung für die vorliegenden Erfindung
bereitstellt;
-
2 illustriert
eine Netzwerk-Konfiguration, bei der ein Client zwei Proxys, die
verschiedene Authentifizierungsdaten anfordern, passieren muss,
um mit einem Server zu kommunizieren;
-
3 illustriert
eine Netzwerk-Konfiguration, bei der ein Client mehr als zwei Proxys,
die verschiedene Authentifizierungsdaten anfordern, passieren muss,
um mit einem Server zu kommunizieren;
-
4 illustriert
einen Datenfluss in der in 2 dargestellten
Netzwerk-Konfiguration,
bei der der Client eine erste Anforderung für einen Dienst in Übereinstimmung
mit einer ersten Ausführungsform der
vorliegenden Erfindung absendet;
-
5 illustriert
drei geordnete Datenflüsse, die
in das Authentifizieren des Clients bei dem ersten Proxy in Übereinstimmung
mit der ersten Ausführungsform
der vorliegenden Erfindung einbezogen sind;
-
6 illustriert
vier geordnete Datenflüsse, die
in das Authentifizieren des Clients bei dem zweiten Proxy in Übereinstimmung
mit der ersten Ausführungsform
der vorliegenden Erfindung einbezogen sind;
-
7 illustriert
einen Datenfluss, der die Kommunikation über den ersten und den zweiten Proxy
so abschließt,
dass die Kommunikation zwischen dem Client und dem Server in Übereinstimmung
mit der ersten Ausführungsform
der vorliegenden Erfindung hergestellt wird;
-
8 illustriert
einen Ablaufplan eines Verfahrens, mit dem der Client mit dem Server
kommuniziert, obgleich er mehrere Proxys, die verschiedene Authentifizierungsdaten
anfordern, passieren muss, in Übereinstimmung
mit einer ersten Ausführungsform
der vorliegenden Erfindung;
-
9 illustriert
sieben geordnete Datenflüsse,
die der Reihenfolge nach durch den Client abgearbeitet werden, um
mit dem Server zu kommunizieren, obgleich er mehrere Proxys, die
verschiedene Authentifizierungsdaten anfordern, passieren muss, in Übereinstimmung
mit einer zweiten Ausführungsform
der vorliegenden Erfindung;
-
10 illustriert
einen Ablaufplan eines Verfahrens, mit dem der Client mit einem
Server in Übereinstimmung
mit der zweiten Ausführungsform
der vorliegenden Erfindung kommuniziert; und
-
11 illustriert
eine Datenstruktur einer HTTP-Anforderung, die verwendet werden
kann, wenn eine Anforderung gesendet wird, die verschiedene Authentifizierungsdaten
für mehrere
Proxys in Übereinstimmung
mit der vorliegenden Erfindung enthält.
-
AUSFÜHRLICHE
BESCHREIBUNG DER ERFINDUNG
-
Die
vorliegende Erfindung betrifft Verfahren, Systeme, Computerprogrammerzeugnisse
und Datenstrukturen für
einen Client zum Kommunizieren mit einem Server selbst dann, wenn
mehrere Proxys, die verschiedene Authentifizierungsdaten anfordern, passiert
werden müssen,
um eine solche Kommunikation zu ermöglichen. Proxys, die verglichen
miteinander verschiedene Authentifizierungsdaten anfordern, werden
hierin als „heterogene
Authentifizierungs"-Proxys
bezeichnet. Während
des Betriebs authentifiziert sich der Client zunächst bei einem ersten Proxy
unter Verwendung der Authentifizierungsdaten, die für den ersten
Proxy geeignet sind. Anschließend
authentifiziert sich der Client bei einem zweiten Proxy unter Verwendung
verschiedener Authentifizierungsdaten, die für den zweiten Proxy geeignet sind.
Diese Proxy-Authentifizierung wird über so viele Proxys wie notwendig
so lange fortgesetzt, bis sich der Client in Kommunikation mit dem
Server befindet.
-
Die
Prinzipien der vorliegenden Erfindung ermöglichen es einem Client über diese
mehreren heterogenen Authentifizierungs-Proxys unter Verwendung
bereits vorhandener Transportprotokolle, wie beispielsweise des
HyperText Transport Protocol (HTTP), bereits vorhandener Sicherheitsprotokolle, wie
beispielsweise des Secure Socket Layer- (SSL) Protokolls und bereits vorhandener
Protokolle, wie beispielsweise den HTTP- Authentifizierungsverfahren, zu kommunizieren.
Die Prinzipien der vorliegenden Erfindung können auch auf in der Zukunft
entwickelte Protokolle angewendet werden.
-
Die
Ausführungsformen
der vorliegenden Erfindung können
einen Spezial- oder einen Universalcomputer einschließlich verschiedener
Computerhardware, wie dies im Folgenden ausführlicher beschrieben wird,
umfassen. Ausführungsformen
innerhalb des Umfanges der vorliegenden Erfindung können auch
computerlesbare Medien zum Tragen oder Bereitstellen von durch Computer
ausführbaren
Befehlen oder darauf gespeicherten Datenbefehlen umfassen. Solche
computerlesbare Medien können
jegliche beliebige verfügbare
Medien sein, auf die durch einen Universal- oder einen Spezialcomputer
zugegriffen werden kann. Im Sinne eines Beispiels und nicht im restriktiven
Sinne zu erachten, könne
solche computerlesbare Medien physikalische Speichermedien, wie
beispielsweise Direktzugriffsspeicher RAM, Festwertspeicher ROM,
elektronisch löschbare
und programmierbare Lesespeicher EEPROM, CD-ROM und andere optische
Plattenspeicher, magnetische Plattenspeicher oder andere magnetische
Speichervorrichtungen, oder ein beliebiges anderes Medium umfassen,
das zum Tragen oder Speichern eines gewünschten Programmcodemittels
in Form von durch Computer ausführbaren
Befehlen oder Datenstrukturen verwendet werden kann und auf das
durch einen Universalcomputer oder einen Spezialcomputer zugegriffen
werden kann.
-
Wenn über ein
Netzwerk oder eine andere Kommunikationsverbindung (entweder festverdrahtet,
drahtlos oder eine Kombination aus festverdrahteter und drahtloser
Verbindung) Informationen zu einem Computer übertragen oder diesem bereitgestellt werden,
sieht der Computer die Verbindung ganz richtig als computerlesbares
Medium an. Dementsprechend wird solch eine Verbindung auch ganz richtig
als computerlesbares Medium bezeichnet. Kombinationen der oben genannten
Medien sollten ebenfalls in den Umfang der computerlesbaren Medien
aufgenommen werden. Durch Computer ausführbare Befehle umfassen beispielsweise
Befehle und Daten, durch die ein Universalcomputer oder ein Spezialcomputer
oder eine Verarbeitungsvorrichtung für spezielle Zwecke veranlasst
werden, eine bestimmte Funktion oder eine Gruppe von Funktionen auszuführen.
-
1 und
die folgende Diskussion stellen beabsichtigterweise eine allgemeine
Beschreibung einer geeigneten Rechenumgebung dar, in der die Erfindung
implementiert werden kann. Obwohl dies nicht unbedingt erforderlich
ist, wird die Erfindung in dem allgemeinen Kontext von durch Computer
ausführbaren
Befehlen wie beispielsweise Programmmodulen, welche von Computern
in Netzwerkumgebungen ausgeführt
werden, beschrieben. Im Allgemeinen umfassen Programmmodule Routinen,
Programme, Objekte, Komponenten, Datenstrukturen und so weiter,
die bestimmte Aufgaben ausführen oder
bestimmte abstrakte Datentypen implementieren. Durch Computer ausführbare Befehle,
verbundene Datenstrukturen und Programmmodule repräsentieren
Beispiele des Programmcodemittels zum Ausführen der Schritte der hierin
offenbarten Verfahren. Die bestimmte Abfolge solcher ausführbaren
Befehle oder verbundener Datenstrukturen repräsentieren Beispiele von entsprechenden
Handlungen für das
Implementieren der in solchen Schritten beschriebenen Funktionen.
-
Es
wird den Personen mit gewöhnlicher
Erfahrung auf dem Gebiet der Technik offensichtlich sein, dass die
Erfindung in Netzwerk-Rechenumgebungen mit einer Vielzahl von Typen
von Computersystemkonfigurationen, einschließlich Personalcomputern, Handgeräten, Multiprozessorsystemen,
auf Mikroprozessoren basierenden oder programmierbaren Konsumelektronikgeräten, Netzwerk-PCs,
Minicomputern, Großrechnern
und Ähnlichen
umgesetzt werden kann. Darüber
hinaus kann die Erfindung auch in verteilten Rechenumgebungen umgesetzt werden,
in denen Aufgaben durch lokale und dezentrale informationsverarbeitende
Geräte
ausgeführt werden,
die über
ein Kommunikationsnetzwerk angeschlossen sind (entweder durch festverdrahtete
Verbindungen, drahtlose Verbindungen oder durch eine Kombination
aus festverdrahteten und drahtlosen Verbindungen). In einer verteilten
Rechenumgebung können
die Programmmodule sowohl in lokalen als auch in dezentralen Speichereinrichtungen
vorhanden sein.
-
In
Bezug auf 1 enthält ein exemplarisches System
zum Implementieren der Erfindung einen Universalcomputer in Form
eines herkömmlichen
Computers 120, der eine Verarbeitungseinheit 121,
einen Systemspeicher 122 sowie einen Systembus 123 umfasst,
der die verschiedenen Systemkomponenten einschließlich des
Systemspeichers 122 mit der Verarbeitungseinheit 121 koppelt.
Der Systembus 123 kann ein beliebiger von mehreren Typen von
Busstrukturen einschließlich
eines Speicherbuses oder einer Speichersteuereinheit, eines Peripheriebuses
und eines lokalen Buses, der eine beliebige Architektur von einer
Bandbreite an Busarchitekturen verwendet, sein. Der Systemspeicher
enthält
einen Nur-Lese-Speicher (ROM) 124 und einen Schreib-Lese-Speicher (RAM) 125.
Ein Basis-Eingabe-/Ausgabesystem 126 (BIOS), das die allgemeinen Routinen
enthält,
welche das Übertragen
von Informationen zwischen den Elementen innerhalb des Computers 120 wie
beispielsweise während
des Hochfahrens unterstützt,
kann in dem ROM 124 gespeichert sein.
-
Der
Computer 120 kann darüber
hinaus ein magnetisches Festplattenlaufwerk 127 zum Lesen von
und Schreiben auf eine Magnetfestplatte 139, ein Magnetplattenlaufwerk 128 zum
Lesen von oder Schreiben auf eine entnehmbare Magnetplatte 129 und
ein optisches Plattenlaufwerk 130 zum Lesen von oder Schreiben
auf eine entnehmbare optische Platte 131, wie beispielsweise
eine CD-ROM oder andere optische Medien enthalten. Das magnetische Festplattenlaufwerk 127,
das Magnetplattenlaufwerk 128 und das optische Plattenlaufwerk 130 sind
jeweils über
eine Festplattenlaufwerkschnittstelle 132, eine Magnetplattenlaufwerkschnittstelle 133 und
eine Schnittstelle eines optischen Plattenlaufwerkes 134 mit
dem Systembus 123 verbunden. Die Laufwerke und ihre verbundenen
computerlesbaren Medien stellen eine nicht-flüchtige Speicherung von durch Computer
ausführbaren
Befehlen, Datenstrukturen, Programmmodulen und anderen Daten für den Computer 120 bereit.
Obgleich die hierin beschriebene exemplarische Umgebung eine magnetische
Festplatte 139 verwendet, können auch ein entnehmbare Magnetplatte 129 und
eine entnehmbare optische Platte 131, und andere Typen
von computerlesbaren Medien zum Speichern von Daten verwendet werden,
einschließlich
Kassetten, Flash-Speicherkarten, DVDs (Digital Versatile Disks),
Bernoulli-Kartuschen, Direktzugriffsspeicher RAMs, Festwertspeicher ROMs
und Ähnliches.
-
Programmcodemittel,
die ein oder mehrere Programmmodule umfassen, können auf der Festplatte 139,
der magnetischen Platte 129, der optischen Platte 131,
dem Festwertspeicher ROM 124 oder dem Direktzugriffsspeicher
RAM 125 gespeichert werden und enthalten ein Betriebssystem 135, ein
oder mehrere Anwendungsprogramme 136, weitere Programmmodule 137 sowie
Programmdaten 138. Ein Benutzer kann Befehle und Informationen über eine
Tastatur 140, eine Zeigevorrichtung 142, oder
andere Eingabegeräte
(nicht dargestellt), wie beispielsweise ein Mikrophon, ein Joystick,
ein Gamepad, eine Satellitenschüssel,
einen Scanner oder Ähnliches
eingeben. Diese und andere Eingabegeräte sind oftmals über eine
serielle Anschlussschnittstelle 146, die an den Systembus
angeschlossen ist, mit der Verarbeitungseinheit 121 verbunden.
Alternativ dazu können
die Eingabegeräte
durch andere Schnittstellen, wie beispielsweise einen Parallelanschluss,
einen Gameanschluss oder einen Universal Serial Bus (USB) Parallelanschluss,
einen Gameanschluss oder einen Universal Serial Bus (USB) verbunden
sein. Ein Monitor 147 oder ein anderes Anzeigegerät ist ebenfalls über eine
Schnittstelle, wie beispielsweise einen Videoadapter 148 mit
dem Systembus 123 verbunden. Zusätzlich zu dem Monitor umfassen
Personalcomputer typischerweise andere Peripherieausgabegeräte (nicht
dargestellt), wie beispielsweise Lautsprecher und Drucker.
-
Der
Computer 120 kann in einer Netzwerkumgebung unter Verwendung
von logischen Verbindungen zu einem oder mehreren dezentralen Computern,
wie beispielsweise den dezentralen Computern 149a und 149b,
betrieben werden. Die dezentralen Computer 149a und 149b können jeweils
ein Personalcomputer, ein Server, ein Router, ein Netzwerk-PC, ein
Partnergerät
oder ein anderer allgemein verwendeter Netzwerkknoten sein und enthält typischerweise
eine Vielzahl von oder sämtliche
der hinsichtlich des Computers 120 voranstehend beschriebenen
Elemente, obgleich lediglich die Speichervorrichtungen 150a und 150b und
ihre verbundenen Anwendungsprogramme 136a und 136b in 1 dargestellt
wurden. Die in 1 dargestellten logischen Verbindungen
umfassen ein Local Area Network (LAN) 151 und ein Wide
Area Network (WAN) 152, die hier im Sinne eines Beispiels
und nicht im beschränkenden
Sinne dargestellt sind. Solche Netzwerkumgebungen sind in büroweiten
und unternehmensweiten Computernetzwerken, Intranets und dem Internet
weit verbreitet.
-
Wenn
der Computer 120 in einer LAN-Netzwerkumgebung verwendet
wird, ist er über
eine Netzwerkschnittstelle oder einen Adapter 153 an das
lokale Netz LAN 151 angeschlossen. Wenn der Computer 120 in
einer WAN-Netzwerkumgebung verwendet wird, kann er ein Modem 154,
eine Funkverbindung oder eine andere Einrichtung zum Herstellen von
Verbindungen über
das Wide Area Network (WAN) 152 enthalten, wie beispielsweise
dem Internet. Das Modem 154, das ein internes oder ein
externes Modem sein kann, ist über
die serielle Anschlussschnittstelle 146 an den Systembus 123 angeschlossen.
In einer Netzwerkumgebung können die
im Zusammenhang mit dem Computer 120 dargestellten Programmmodule
beziehungsweise Abschnitte davon in der dezentralen Speichervorrichtung
gespeichert sein. Es wird offensichtlich sein, dass die dargestellten
Netzwerkverbindungen exemplarischen Charakter besitzen und dass
andere Vorrichtungen zum Herstellen einer Kommunikationsverbindung
zwischen den Computern verwendet werden können.
-
Die
vorliegende Erfindung kann in einer Umgebung verwendet werden, in
der ein Client sich bei mehreren Proxys, die verschiedene Authentifizierungsdaten
von dem Client anfordern, authentifizieren muss. 2 illustriert
eine Netzwerk-Konfiguration 200, bei der der Client sich
bei zwei Proxys, die auf verschiedenen Seiten eines Vertrauens-Grenzbereichs vorhanden
sind, authentifizieren muss, so dass keiner der beiden Proxys bereit
ist, Authentifizierungsdaten gemeinsam zu nutzen.
-
In
der Netzwerk-Konfiguration muss sich der Client, um zwischen dem
Client-Computersystem (auch „Client" genannt) 201 und
dem Server-Computersystem (auch „Server" genannt) 205 kommunizieren
zu können,
sowohl bei dem erste Proxy 202 als auch bei dem zweiten
Proxy 204 authentifizieren, selbst wenn beide verschiedene
Authentifizierungsdaten anfordern. Da der erste Proxy 202 und
der zweite Proxy 204 verschiedene Authentifizierungsdaten
anfordern, entsprechen sie bererechtigterweise der voranstehend
definierten Definition von „heterogenen
Authentifizierungs"-Proxys.
-
Der
erste Proxy 202 und der zweite Proxy 204 sind
mit einem Vertrauens-Grenzbereich 203 dargestellt, der
diese voneinander abgrenzt, um anzuzeigen, dass sich die Verwaltungseinheit
des ersten Proxy 202 möglicherweise
aus Sicherheitsgründen
dazu entscheidet, andere Authentifizierungsdaten zu erhalten, als
die Verwaltungseinheit des zweiten Proxy 204. Es ist jedoch
nicht unbedingt erforderlich, dass der erste und der zweite Proxy
durch verschiedene Einheiten verwaltet werden, oder dass sie sich
in verschiedenen Vertrauensbereichen befinden.
-
Wenn
die Kommunikation über
mehrere Proxy stattfindet, die dieselben Authentifizierungsdaten anfordern
(im Folgenden auch als „homogene
Authentifizierungs"-Proxys
bezeichnet), ermöglichen
es herkömmliche
Prozesse einem jeden homogenen Authentifizierungs-Proxy, die Authentifizierungsdaten aus
einer Anforderung zu lesen und diese Anforderung weiterzuleiten.
Der erste Proxy 202 kann entweder einen einzelnen Proxy
oder mehrere Proxys darstellen, die dieselben Authentifizierungsdaten
anfordern. In beiden Fällen
wird dadurch, dass dem ersten Proxy 202 die korrekten Authentifizierungsdaten
bereitgestellt werden, die Kommunikation über den ersten Proxy 202 zugelassen.
Auf ähnliche
Weise kann der zweite Proxy 204 entweder einen einzelnen
Proxy oder mehrere Proxys darstellen, die dieselben Authentifizierungsdaten
anfordern (obgleich sich diese von den Authentifizierungsdaten,
die von dem ersten Proxy 202 ange fordert werden, unterscheiden).
In beiden Fällen
wird dadurch, dass dem zweiten Proxy 204 die korrekten
Authentifizierungsdaten bereitgestellt werden, die Kommunikation über den
zweiten Proxy 204 zugelassen.
-
Der
Client 201 ist als eine Funkvorrichtung dargestellt, um
eine potentielle Situation zu beschreiben, in der mehrere Proxys,
die verschiedene Authentifizierungsdaten anfordern, möglicherweise
passiert werden müssen,
um auf ein Server-Computersystem, wie beispielsweise auf den Server 205,
zugreifen zu können.
Der Client 201 kann jedoch ein beliebiges Computersystem
(wie beispielsweise der voranstehend beschriebene Computer 120)
sein, der sich bei mehreren Proxys, die verschiedene Authentifizierungsdaten
anfordern, authentifizieren muss, um mit einem Server kommunizieren
zu können. Wenn
der Client 201 eine Funkvorrichtung ist, muss sich der
Client 201 zuerst möglicherweise
bei einem Proxy (wie beispielsweise dem Proxy 202) authentifizieren,
der durch einen Funkträger
verwaltet wird. Der Client 201 möchte jedoch möglicherweise
mit einem Server kommunizieren, der durch einen anderen Proxy geschützt wird
(wie beispielsweise der Proxy 204), der durch eine Unternehmenseinheit
verwaltet wird. Dieser Proxy 204 fordert möglicherweise ebenfalls
eine Authentifizierung an, bevor er Zugang zu dem Server 205 zulässt. Möglicherweise
vertrauen jedoch die Unternehmenseinheit und der Funkträger einander
nicht ausreichend, um zuzulassen, dass der Benutzer durch dieselben
Authentifizierungsdaten dargestellt wird. Dementsprechend würden in diesem
Fall der erste Proxy 202 und der zweite Proxy 204 verschiedene
Authentifizierungsdaten anfordern. Der Server 205 kann
wie voranstehend für
den Computer 120 beschrieben strukturiert sein, obgleich
dies nicht unbedingt erforderlich ist.
-
3 illustriert
eine Netzwerk-Konfiguration 300, in der der Client 201 mehr
als einen Proxy, die verschiedene Authentifizierungsdaten anfordern, passieren
muss, um mit dem Server 205 zu kommunizieren. 3 wird
bereitgestellt, um darzustellen, dass die Prinzipien der vorliegenden
Erfindung nicht auf Netzwerk-Konfigurationen beschränkt sind,
die zwei Proxy aufweisen, welche verschiedene Authentifizierungsdaten
anfordern. Die Netzwerk-Konfiguration umfasst eine beliebige Anzahl
(„N") von heterogenen
Authentifizierungs-Proxys, wobei die Anzahl N in 2 zwei
ist und mehr als drei in 3 ist. So enthält die Netzwerk-Konfiguration
beispielsweise einen N'-ten
Proxy 303 und weitere Vertrauens-Grenzbereiche 301 und 302.
-
Die 4 bis 7 illustrieren
schematisch einen Datenfluss in Übereinstimmung
mit der vorliegenden Erfindung, so wie dieser in der in 2 dargestellten
Netzwerk-Konfiguration
auftreten würde. Die 4 bis 7 sind 2 ähnlich,
mit Ausnahme der Tatsache, dass ein Speicher, der mit dem Client 201 verbunden
ist, im Sinne einer verständlichen Erklärung dargestellt
ist. Darüber
hinaus wurde der Vertrauens-Grenzbereich
entfernt, um zu betonen, dass es nicht erforderlich ist, dass der
erste Proxy 202 und der zweite Proxy 204 in verschiedenen
Vertrauensbereichen vorhanden sind. Des Weiteren sind Pfeile, die
den Datenfluss illustrieren, dargestellt. Dort, wo mehrere Pfeile
in einer einzelnen Figur dargestellt sind, enthält der Pfeilkopf eine Zahl,
die die Reihenfolge der Operation innerhalb der Figur anzeigt.
-
Obgleich
das Hauptaugenmerk der Beschreibung auf der in 2 dargestellten
Umgebung liegen wird, wird sich ein Teil der Beschreibung auch der
Frage widmen, wie die Prinzipien der vorliegenden Erfindung auf
die in 3 dargestellte Netzwerk-Konfiguration, bei der mehr als zwei
heterogene Authentifizierungs-Proxys vorhanden sind, angewendet
werden können.
Ein entsprechender Ablaufplan eines Verfahrens zum Authentifizieren
bei mehreren heterogenen Authentifizierungs-Proxys ist in 8 dargestellt.
Die 4 bis 7 werden unter häufiger Bezugnahme
auf 8 beschrieben.
-
In
Bezug auf die 4 und 8 sendet
der Client 201 eine erste Anforderung eines Dienstes (Schritt 801).
Diese erste Anforderung kann eine Anforderung gemäß des Internet-Standards
HTTP sein. Der Client 201 führt anschließend einen
Schritt des Authentifizierens bei dem ersten Proxy durch (Schritt 802),
der in der in den 4 bis 8 dargestellten Ausführungsform
den entsprechende Schritt 803, den Schritt 804 und
den Schritt 805 umfasst. Genauer gesagt bedeutet dies,
dass in Bezug auf 5 und auf 8 der
erste Proxy 202 eine erste Authentifizierungsanforderung
absendet, die schließlich
der Client 201 empfängt
(Schritt 803). Die erste Authentifizierungsanforderung
kann beispielsweise eine Proxy-Authentication-Response gemäß HTTP sein. In
Reaktion auf diese Authentifizierungsanforderung ruft der Client 201 erste
Authentifizierungsdaten 402 aus dem Speicher 401 ab,
und zwar die ersten Authentifizierungsdaten 402, die mit
dem ersten Proxy verbunden sind (Schritt 804). Der Client 201 sendet anschließend eine
zweite Anforderung eines Dienstes 205 ab, wobei die zweite
Anforderung die ersten Authentifizierungsdaten 402 enthält (Schritt 805). Möglicherweise
ruft der Client 201 bei Empfang der Authentifizierungsanforderung
automatisch von dem ersten Proxy 202 die ersten Authentifizierungsdaten 402 ab
und sendet automatisch die zweite Anforderung, ohne dass ein Benutzereingriff
erforderlich ist.
-
Anschließend führt der
Client 201 einen Schritt zum Authentifizieren bei dem zweiten
Proxy (Schritt 806) durch, der in der in den 4 bis 8 dargestellten
Ausführungsform
den entsprechenden Schritt 807, den Schritt 808 und
den Schritt 809 umfasst. Genauer gesagt bedeutet dies,
dass in Bezug auf 6 und auf 8 der
zweite Proxy 204 eine zweite Authentifizierungsanforderung
absendet, die der Client 201 schließlich über den ersten Proxy 202 empfängt (Schritt 807).
Der erste Proxy 202 hat die zweite Anforderung eines Dienstes
empfangen, hat die ersten Authentifizierungsdaten 402 verwendet, um
den Benutzer des Client 201 zu authentifizieren und hat
anschließend
die zweite Anforderung zu dem zweiten Proxy 204 weitergeleitet.
Da der zweite Proxy 204 die ersten Authentifizierungsdaten 402 nicht erkennt,
und da keine weiteren Authentifizierungsdaten in der zweiten Anforderung
bereitgestellt wurden, hat der zweite Proxy 204 die zweite
Authentifizierungsanforderung abgesendet. Die zweite Authentifizierungsanforderung
kann ebenfalls eine 407-Proxy-Authentication-Response sein.
-
In
Reaktion auf diese zweite Authentifizierungsanforderung ruft der
Client 201 die zweiten Authentifizierungsdaten 403 aus
dem Speicher 401, nämlich
die zweiten Authentifizierungsdaten 403, die mit dem zweiten
Proxy 204 verbunden sind, ab (Schritt 808). Der
Client 201 sendet anschließend eine dritte Anforderung
eines Dienstes ab, wobei die dritte Anforderung die ersten Authentifizierungsdaten 402 und
die zweiten Authentifizierungsdaten 403 enthält (Schritt 809).
Möglicherweise
ruft der Client 201 bei Empfang der Authentifizierungsanforderung
von dem zweiten Proxy 204 die zweiten Authentifizierungsdaten 403 automatisch
ab und sendet die dritte Anforderung automatisch ab, ohne dass ein
Benutzereingriff erforderlich ist. Der erste Proxy 202 verwendet
anschließend
die ersten Authentifizierungsdaten 402 in der dritten Anforderung,
um den Benutzer des Clients 201 zu authentifizieren und
leitet anschließend
die dritte Anforderung zu dem zweiten Proxy 204 weiter.
Optional kann der erste Proxy 202 die ersten Authentifizierungsdaten
so entfernen, dass die Authentifizierungsdaten dem zweiten Proxy 204 nicht
offenbart werden. Der zweite Proxy 204 verwendet anschließend die
zweiten Authentifizierungsdaten 403 in der dritten Authentifizierungsanforderung,
um den Benutzer zu authentifizieren.
-
Wie
dies in 7 dargestellt ist, leitet der zweite
Proxy 204 anschließend
die dritte Anforderung zu dem Server 205 weiter, um dadurch
Kommunikation zwischen dem Client 201 und dem Server 205 herzustellen,
selbst dann, wenn mehrere heterogene Authentifizierungs-Proxys passiert
werden müssen.
Wenn mehr als zwei heterogene Authentifizierungs-Proxys einbezogen
wären,
wie dies der Fall in 3 ist, dann würde die
dritte Anforderung zu dem dritten Proxy weitergeleitet werden. Die
voranstehend beschriebenen Prozesse würden so lange wiederholt werden,
bis die Anforderung eines Dienstes sämtliche Authentifizierungsdaten
enthält,
die für sämtliche
der relevanten heterogenen Authentifizierungs-Proxys angefordert
werden. Die Formulierung der dritten Anforderung zum Integrieren
von sowohl der ersten als auch der zweiten Authentifizierungsdaten
(und weiterer Authentifizierungsdaten, wenn mehr als zwei heterogene
Authentifizierungs-Proxys vorhanden sind) kann unter Verwendung
von bereits vorhandenen Protokollen erzielt werden, um eine einzigartige
Datenstruktur zu erzeugen, wie dies im Folgenden in Bezug auf 11 beschrieben
wird.
-
9 zeigt
einen Datenfluss in Übereinstimmung
mit einer zweiten Ausführungsform
zum Herstellen einer Kommunikation zwischen dem Client 201 und
dem Server 205. 10 illustriert
einen Ablaufplan eines Verfahrens, das in der in 9 dargestellten
Umgebung ausgeführt
wird. Die zweite Ausführungsform
wird im Folgenden in Bezug auf sowohl 9 als auch 10 beschrieben.
-
In
Bezug auf die 9 und 10 sendet der
Client 201 zuerst eine Verbindungsanforderung zu dem ersten
Proxy 202 ab (Schritt 1001). Diese Verbindungsanforderung
kann eine Anforderung gemäß dem Internet-Standard
HTTP sein. Die Verbindungsanforderung sollte dennoch unter Verwendung eines
Protokolls erstellt werden, das es zulässt, dass Verbindungsanforderungen
an Proxys gerichtet werden. Ein solches Protokoll ist das Secure
Socket Layer-(SSL)Protokoll, das in Übereinstimmung mit HTTP implementiert
sein kann.
-
Anschließend führt der
Client 201 einen Schritt des Authentifizierens bei dem
ersten Proxy durch (Schritt 1002), der in der in den 9 und 10 dargestellten
Ausführungsform
den entsprechenden Schritt 1003, den Schritt 1004 und
den Schritt 1005 umfasst. Die erste Authentifizierungsanforderung
kann beispielsweise eine 407-Proxy-Authentication-Response gemäß HTTP sein.
In Reaktion auf diese Authentifizierungsan forderung ruft der Client 201 erste
Authentifizierungsdaten 402 aus dem Speicher 401 ab,
und zwar die ersten Authentifizierungsdaten 402, die mit
dem ersten Proxy verbunden sind (Schritt 1004). Der Client 201 sendet
anschließend
eine Verbindungsanforderung zu dem zweiten Proxy 204 ab,
wobei die zweite Anforderung die ersten Authentifizierungsdaten 402 enthält (Schritt 1005).
Möglicherweise
ruft der Client 201 bei Empfang der Authentifizierungsanforderung
automatisch von dem ersten Proxy 202 die ersten Authentifizierungsdaten 402 ab
und sendet automatisch die zweite Anforderung, ohne dass ein Benutzereingriff erforderlich
ist.
-
Der
Client 201 führt
anschließend
einen Schritt des Authentifizierens bei dem zweiten Proxy durch
(Schritt 1006), der, in der in den 9 und 10 dargestellten
Ausführungsform
den entsprechenden Schritt 1007, Schritt 1008 und
Schritt 1009 enthält.
Genauer gesagt, sendet der zweite Proxy 204 eine zweite
Authentifizierungsanforderung ab, die der Client schließlich über den
ersten Proxy 202 empfängt
(Schritt 1007). Der erste Proxy 202 hat die zweite
Verbindungsanforderung, die für
den zweiten Proxy 204 bestimmt war, empfangen, er hat die
ersten Authentifizierungsdaten 402 verwendet, um den Benutzer
des Client 201 zu authentifizieren, und er ist in einen
Byte-Weiterleitmodus
eingetreten und hat auf diese Weise zugelassen, dass der erste Proxy 202 dem
Client 201 effektiv transparent ist. Die Verbindungsanforderung
wird dementsprechend auf geeignete Weise zu dem zweiten Proxy 204 weitergeleitet.
Da der zweite Proxy 204 die ersten Authentifizierungsdaten 402 nicht
erkennt, und da keine weiteren Authentifizierungsdaten in der Verbindungsanforderung
bereitgestellt wurden, hat der zweite Proxy 204 die zweite
Authentifizierungsanforderung abgesendet. Die zweite Authentifizierungsanforderung
kann ebenfalls eine 407 Proxy Authentication Response sein.
-
In
Reaktion auf diese zweite Authentifizierungsanforderung ruft der
Client 201 zweite Authentifizierungsdaten 403 aus
dem Speicher 401 ab, und zwar die zweiten Authentifizierungsdaten 403,
die mit dem zweiten Proxy 204 verbunden sind (Schritt 1008).
Der Client 201 sendet anschließend eine Verbindungsanforderung
zu dem Server 205 ab, wobei die dritte Anforderung die
ersten Authentifizierungsdaten 402 und die zweiten Authentifizierungsdaten 403 enthält (Schritt 1009).
Möglicherweise
ruft der Client 201 bei Empfang der Authentifizierungsanforderung
von dem zweiten Proxy 204 automatisch die zweiten Authentifizierungsdaten 403 ab
und sendet automatisch die Verbindungsanfor derung zu dem Server 205,
ohne dass ein Benutzereingriff erforderlich ist. Der erste Proxy 202 verwendet
anschließend die
ersten Authentifizierungsdaten 402 in der dritten Verbindungsanforderung,
um den Benutzer des Client 201 zu authentifizieren und
leitet anschließend die
dritte Anforderung zu dem zweiten Proxy 204 weiter. Der
zweite Proxy 204 verwendet anschließend die zweiten Authentifizierungsdaten 403 in
der dritten Verbindungsanforderung, um die Authentifizierung bei
dem zweiten Proxy 204 durchzuführen.
-
Wie
dies in 9 dargestellt ist, leitet der zweite
Proxy 204 anschließend
die dritte Verbindungsanforderung zu dem Server 205 weiter,
um auf diese Weise eine Kommunikation zwischen dem Client 201 und
dem Server 205 selbst dann herzustellen, wenn mehrere heterogene
Authentifizierungs-Proxys passiert werden müssten. Wenn mehr als zwei heterogene
Authentifizierungs-Proxys einbezogen wären, wie dies in 3 der
Fall ist, dann würde
die dritte Verbindungsanforderung zu dem dritten Proxy weitergeleitet
werden. Die in Bezug auf die 9 und 10 beschriebenen
Prozesse würden so
lange wiederholt werden, bis die Verbindungsanforderung zu dem Server 205 abgesendet
wäre und sämtliche
Authentifizierungsdaten enthalten würde, die durch einen beliebigen
eingreifenden Proxy angefordert würde.
-
Die
zweite Ausführungsform
erfordert, dass ein Protokoll, wie beispielsweise das SSL-Protokoll implementiert
wird, das es ermöglicht,
dass Verbindungen zu Proxys hergestellt werden. Die zweite Ausführungsform
erfordert darüber
hinaus, dass der Client 201 Kenntnis über die Adresse von sämtlichen eingreifenden
Proxys zwischen dem Client 201 und dem Server 205 besitzt.
Bei der ersten Ausführungsform
müssen
solche Bedingungen nicht erfüllt
werden.
-
In
beiden Ausführungsformen
kann die Formulierung der dritten Anforderung, um sowohl die ersten
als auch die zweiten Authentifizierungsdaten (sowie weitere Authentifizierungsdaten,
wenn mehr als zwei heterogene Authentifizierungs-Proxys vorhanden
sind) zu integrieren, ebenfalls unter Verwendung von bereits vorhandenen
Protokollen erzielt werden, um eine einzigartige Datenstruktur zu
erzeugen, wie dies im Folgenden in Bezug auf 11 beschrieben
wird.
-
11 illustriert
die relevanten Komponenten einer Datenstruktur einer HTTP-Anforderung 1100,
die als dritte Anforderung eines Dienstes (wie in den 4 bis 8)
oder als die Verbindungsanforderung zu dem Server (wie in den 9 und 10)
verwendet werden kann. Die HTTP-Anforderung 1100 enthält ein Datenfeld,
das die Proxy-Authentifizierungsdaten 1101 darstellt.
Die Authentifizierungsdaten 1101 enthalten sämtliche
der Authentifizierungsdaten, die erforderlich sind, um alle heterogenen
Authentifizierungs-Proxys zwischen dem Client 201 und dem
Server 205 zu passieren, so wie dies beschrieben wird.
Die HTTP-Anforderung 1100 enthält darüber hinaus andere Daten 1102,
die gemäß dem Standard
HTTP zulässig
sind. Diese anderen Daten 1102 können beispielsweise Authentifizierungsdaten
für die
Verwendung durch den Server 205 enthalten.
-
Die
Proxy-Authentifizierungsdaten 1101 enthalten ein Datenfeld 1103,
das die Proxy-Authentifizierungsdaten 1101 als
Proxy-Authentifizierungsdaten identifiziert. In Übereinstimmung mit dem Digest-Authentifizierungsverfahren
und zulässig
gemäß HTTP,
kann der Proxy-Authentifizierungs-Header 1103 beispielsweise
der WWW-Authentication-Response-Header
sein. Die Proxy-Authentifizierungsdaten 1101 enthalten
Authentifizierungsdaten für
den ersten Proxy (Datenfeld 1104), Authentifizierungsdaten
für den
zweiten Proxy (Datenfeld 1105) ebenso wie Authentifizierungsdaten
für andere
heterogene Authentifizierungs-Proxys, falls welche vorhanden sind
(Datenfeld 1106).
-
Die
Authentifizierungsdaten für
den ersten Proxy enthalten eine Bereichskennung (realm identifier) 1107,
die identifiziert, dass die Authentifizierungsdaten tatsächlich für den ersten
Proxy 202 sind. Die Authentifizierungsdaten für den zweiten
Proxy enthalten ebenfalls eine Bereichskennung 1108, die identifiziert,
dass die Authentifizierungsdaten tatsächlich für den zweiten Proxy 204 sind.
Bereichskennungen werden durch die HTTP-Authentifizierungsverfahren zugelassen,
obgleich Bereichskennungen herkömmlicherweise
nicht zum Trennen von Authentifizierungsdaten für die Verwendung durch heterogene
Authentifizierungs-Proxys eingesetzt wurden. Die Bereichskennungen 1107 und 1108 befähigten den
ersten Proxy 202 und den zweiten Proxy 204 zum
Lokalisieren der geeigneten Authentifizierungsdaten.
-
Die
Authentifizierungsdaten für
den ersten Proxy enthalten die ersten Authentifizierungsdaten 1109 (beispielsweise
die ersten Authentifizierungsdaten 402), die eine erste Benutzerkennung 1111 und ein
erstes Passwort 1112 für
die Verwendung durch den ersten Proxy 202 enthalten können. Auf ähnliche Weise
enthalten die Authentifizierungsdaten für den zweiten Proxy die zweiten
Authentifizierungsdaten 1110 (beispielsweise die zweiten
Authentifizierungsdaten 403), die eine zweite Benutzerkennung 1113 und
ein zweites Passwort 1114 für die Verwendung durch den
zweiten Proxy 204 enthalten können.
-
Das
Digest-Authentifizierungsverfahren ist deshalb nützlich, da dadurch Daten unter
Verwendung von Bereichskennungen definiert werden können, wodurch
es ermöglicht
wird, dass die geeigneten Authentifizierungsdaten für einen
jeweiligen Proxy auf geeignete Weise gekennzeichnet werden. Darüber hinaus
ermöglicht
es eine geeignete Verschlüsselung
des Passwortes, so dass die ersten Authentifizierungsdaten 402 nicht
dem zweiten Proxy 204 offenbart werden und dass die zweiten
Authentifizierungsdaten 403 nicht dem ersten Proxy 202 offenbart
werden. Auf diese Weise wird der Vertrauens-Grenzbereich 203, wenn einer
vorhanden ist, dahingehend respektiert, dass vertrauliche Authentifizierungsdaten
nicht den Vertrauens-Grenzbereich passieren.
-
Es
sind dementsprechend Verfahren, Systeme, Computerprogrammerzeugnisse
und Datenstrukturen beschrieben, die es einem Client ermöglichen,
mit einem Server zu kommunizieren, selbst dann, wenn mehrere Proxys,
die verschiedene Authentifizierungsdaten anfordern, zwischen dem
Client und dem Server eingreifen. Darüber hinaus können die
Prinzipien der vorliegenden Erfindung unter Verwendung von bereits
vorhandenen Protokollen und ohne dass dabei vertrauliche Authentifizierungsdaten zwischen
heterogenen Authentifizierungs-Proxys zwangsweise offenbart werden
müssen,
implementiert werden.