-
Die
vorliegende Erfindung betrifft ein Verfahren und ein System, die
das Einsetzen eines Diensts der Zugriffskontrolle zu Internetseiten
ermöglichen.
-
Sie
betrifft insbesondere, aber nicht ausschließlich, die Zugriffsanbieter,
die einen Zugriff zum Internet anbieten und ihre Zugriffsangebote
erweitern möchten,
indem sie ihren Kunden, die über
ein ortsfestes oder mobiles Terminal verfügen, das mit Internet-Browser
versehen ist, Mehrwertdienste anbieten. Sie betrifft ebenfalls die
Inhalte- oder Dienstanbieter, die kostenpflichtige Informationen
aussenden oder kostenpflichtige Dienste liefern möchten.
-
In
diesem Kontext ist es wünschenswert,
zumindest bestimmten Adressen von Internetseiten einen Verbindungstarifierungsbereich
zuordnen zu können,
wobei dieser Bereich von der Gratisbenutzung bis zu einer Gesamttarifierung
des Zugriffs auf den Dienst reicht. Auf diese Weise können die
Internet-Zugriffsanbieter,
die den Verbindungsdienst nach Verbindungszeit fakturieren, für bestimmte
Internetseiten eine Gratisverbindung oder eine Verbindung zu einem
unter dem normalen Preis liegenden Preis anbieten.
-
Dies
erfordert es, die Zieladresse und die Sendeseite jeder vom Internet
empfangenen Antwort erkennen und identifizieren zu können, und
folglich einen Dialogsitzungs-Verwaltungsdienst einzusetzen.
-
Die
Zugriffe auf das Internet mittels eines Browsers basieren aber auf
dem HTTP-Protokoll (HyperText Transfer Protocol), das als "zustandslos" bezeichnet wird,
d.h. dass die Internetserver, auf die über das Netz zugegriffen wird,
nicht die vorhergehenden von dem gleichen Benutzer empfangenen Anforderungen
speichern.
-
Daraus
folgt, dass das HTTP-Protokoll keine Dialogsitzung-Verwaltungsmechanismen
vorsieht. Man muss also vorsehen, dass einerseits der Internetserver
eine solche Verwaltung gewährleistet,
indem er eine Dialogsitzungskennung erzeugt, und indem er einen
Zustand und ein Gültigkeitsgrenzdatum verwaltet,
die der Dialogsitzungskennung zugeordnet sind, und dass andererseits
der Benutzer die Dialogsitzungskennung jedes Mal zurückschickt,
wenn er eine neue Anforderung an den Internetserver sendet.
-
Um
eine solche Dialogsitzungsverwaltung zu implementieren, werden heute
mehrere Mechanismen verwendet.
-
So
gibt es einen ersten Mechanismus, der darin besteht, in ein Formular
ein verstecktes Feld einzufügen,
das eine Dialogsitzungskennung enthält. Jede vom Server an den
Benutzer gelieferte Antwort besteht aus einem Formular, das eine
in einer "Hidden"-Eingabe versteckte
Dialogsitzungskennung enthält,
wobei dieses Formular vom Benutzer vervollständigt und an den Server zurückgesendet
wird. Dieser Mechanismus hat den Nachteil, die Verwendung von Formularen
zu erfordern. Wenn der Benutzer Rückwärtsbewegungen befiehlt (Zugriff
auf die vorher angezeigten Seiten), d.h. Reihen von Aktionen annulliert,
kann die Dialogsitzungskennung außerdem verloren gehen.
-
Es
ist ebenfalls bekannt, einen Mechanismus des Umschreibens einer
Internetadresse oder URL (Universal Resource Locator) zu verwenden. Dieser
Mechanismus besteht darin, in den vom Server gesendeten Adressen
von Interseiten eine Dialogsitzungskennung aufzubewahren. Dieser
Mechanismus erfordert es, die gesendete Internetseite systematisch
zu analysieren, um dort jede URL-Adresse zu ändern, die dort erwähnt wird.
Wenn die Internetseite Skripts vom Typ Java oder Visual Basic enthält, können außerdem Fehlfunktionen auftreten,
wenn diese Skripts ebenfalls URL-Adressen erzeugen.
-
Es
ist ebenfalls bekannt, "Cookies" zu verwenden, um
eine Dialogsitzungskennung aufzubewahren. Ein Cookie ist eine Datei,
die vom Server im Terminal des Benutzers gespeichert wird. Daraus folgt,
dass die Lebensdauer eines Cookies diejenige einer Dialogsitzung übertrifft.
Diese Datei ist in den Vorspann jeder HTTP-Anforderung integriert, die vom Benutzer
zum Server gesendet wird, und findet sich in der Antwort des Servers
wieder. Es stellt sich heraus, dass diese Lösung weitgehend von der Konfiguration
der Parameter des Browsers abhängt,
der im Terminal des Benutzers installiert ist. Diese Softwareprogramme
verfügen
nämlich über einen
Parameter, den der Benutzer verändern
kann, um die Verwendung von Cookies zu verbieten.
-
Um
eine Dialogsitzungsverwaltung einzusetzen, ist es auch bekannt,
eine SSL-Verbindung (Secure Sockets Layer) zu verwenden, die vom
HTTPS-Protokoll (gesichertes HTTP) spezifiziert wird, das eine Dialogsitzungsverwaltung
enthält.
Diese Lösung
erfordert das Einsetzen einer gesicherten Verbindung zwischen dem
Server und dem Benutzer. In diesem Fall sind alle Anforderungen
vom Protokoll her gesehen für
die Einrichtungen mit Flussunterbrechung vom Typ Proxy transparent.
Außerdem
muss die Verwaltung der Dialogsitzungskennungen von einer Instanz
des Informationssystems durchgeführt werden,
was ihre Implementierung verbietet.
-
Um
eine Dialogsitzungskennung aufzubewahren, ist es ebenfalls bekannt,
Mechanismen zu verwenden, die auf den "Dialogsitzungsobjekten" ASP (Active Server
Pages) oder JSP (Java Server Pages) basieren, die von einem für ASP oder
JSP spezifischen Emulator stammen. Diese Lösung erfordert die Implementierung
eines HTTP- Servers,
der zwingend eine ASP- oder JSP-Maschine verwendet, was ziemlich
selten ist.
-
Die
oben beschriebenen Lösungen
sind also für
die Benutzer alles andere als transparent.
-
Außerdem wurde
das Protokoll ICAP (Internet Content Adaptation Protocol) entwickelt,
um die Austauschvorgänge
zwischen den in die Internetarchitekturen integrierten Einrichtungen
(Internetserver, Cache, Router, ...) und den Inhaltstransformationssystemen
zu standardisieren. Dieses Protokoll beruht auf dem einfachen Prinzip,
dass jeder HTTP-Anforderung eine von einem Internetserver oder einem
Cache kommende Antwort entspricht. Es genügt also, die Anforderung und/oder
die Antwort zu transformieren, um einen Inhaltstransformationsdienst
anzubieten. Dieses Protokoll beschränkt sich also darauf, die Kommunikationen
zwischen ICAP-Kunden und ICAP-Servern zu definieren, die den Transformationsdienst
gewährleisten.
Die Transformationsdienste bestehen zum Beispiel darin, eine Viren-
oder Inhaltsfilterung durchzuführen.
-
Dieses
Protokoll ist aber nicht spezifisch konzipiert, um eine HTTP-Dialogsitzungsverwaltung durchzuführen.
-
Die
Druckschrift WO 02/48830 beschreibt ein System, das es ermöglicht,
Anforderungen und Antwortseiten zu analysieren, die zwischen Benutzern
und Servern ausgetauscht werden, um die Online-Aktivität der Benutzer
zu analysieren. Diese Druckschrift beschreibt einen Mechanismus
zum Auffangen der ausgetauschten Daten und zur Verwaltung einer
Navigations-Dialogsitzung,
der es ermöglicht,
diese Daten pro Benutzer und für
eine Navigationszeit zusammenzufassen.
-
Die
vorliegende Erfindung hat zum Ziel, diese Nachteile zu beseitigen.
Dieses Ziel wird durch das Vorsehen eines Verfahrens der Zugriffskontrolle zu
Internetseiten von Inhalte- oder Dienst-Anbietern erreicht, um den
Zugriff von Terminals zu diesen Seiten über ein Datenübertragungsnetz
zu kontrollieren.
-
Erfindungsgemäß weist
dieses Verfahren folgende Schritte auf:
- – Implementierung
eines Zugriffskontrolldiensts, der alle von den Seiten gesendeten
Antworten auffängt,
die für
die Benutzerterminals bestimmt sind,
- – Analyse
jeder der aufgefangenen Antworten, um daraus eine Benutzeridentifikationsinformation, eine
Internet-Adresse und einen Internet-Zugriffscode zu entnehmen,
- – Bestimmen,
ob die entnommene Internet-Adresse einer Internetseite entspricht,
deren Zugriff kontrolliert wird, und Bestimmen, ob es eine laufende
Dialogsitzung gibt, die der entnommenen Benutzeridentifikationsinformation
entspricht,
- – wenn
es keine der entnommenen Benutzeridentifikationsinformation entsprechende
laufende Dialogsitzung gibt, und wenn der entnommene Zugriffscode
gültig
ist, Starten einer Dialogsitzung für den Benutzer entsprechend
der entnommenen Benutzeridentifikationsinformation,
- – Verändern aller
aufgefangenen Antworten, die eine Benutzeridentifikationsinformation
und einen Internet-Zugriffscode entsprechend einer laufenden Dialogsitzung
enthalten, um im Terminal des Benutzers die Anzeige eines Befehls
zum Beenden der Dialogsitzung auszulösen, den der Benutzer aktivieren
kann, wenn er keinen Zugriff zur Internetseite mehr möchte, und
- – Rückübertragung
der aufgefangenen und veränderten
Antworten an die Benutzer.
-
Gemäß einer
Besonderheit der Erfindung ist die aus den aufgefangenen Antworten
entnommene Benutzeridentifikationsinformation eine Benutzeradresse im
Datenübertragungsnetz,
wobei das Verfahren weiter einen Schritt der Bestimmung einer Benutzerkennung
ausgehend von der aus jeder aufgefangenen Antwort entnommenen Benutzeradresse mit
Hilfe einer Entsprechungstabelle aufweist.
-
Gemäß einer
weiteren Besonderheit der Erfindung wird, wenn die aus einer aufgefangenen
Antwort entnommene Benutzeradresse keiner Benutzerkennung entspricht,
die aufgefangene Antwort ohne Veränderung an den Benutzer übertragen.
-
Gemäß noch einer
weiteren Besonderheit der Erfindung wird, wenn es keine der entnommenen Benutzeridentifikationsinformation
entsprechende laufende Dialogsitzung gibt, wenn die aus einer aufgefangenen
Antwort entnommene Benutzeradresse einer Benutzerkennung entspricht,
und wenn die entnommene Internet-Adresse einer Internetseite entspricht,
deren Zugriff kontrolliert wird, die aufgefangene Antwort so verändert, dass
im Terminal des Benutzers die Anzeige einer Seite ausgelöst wird,
die den Benutzer auffordert, einen Zugriffscode zur Internetseite
entsprechend der entnommenen Internet-Adresse einzugeben.
-
Gemäß noch einer
weiteren Besonderheit der Erfindung wird, wenn es keine der entnommenen Benutzeridentifikationsinformation
entsprechende laufende Dialogsitzung gibt, und wenn die entnommene
Internet-Adresse keiner Internetseite entspricht, deren Zugriff
kontrolliert wird, die aufgefangene Antwort ohne Veränderung
an den Benutzer zurück übertragen.
-
Gemäß noch einer
weiteren Besonderheit der Erfindung wird, wenn es eine der entnommenen Benutzeridentifikationsinformation
entsprechende laufende Dialogsitzung gibt, und wenn die entnommene
Internet-Adresse keiner Internetseite entspricht, deren Zugriff
kontrolliert wird, die aufgefangene Antwort so verändert, dass
im Terminal des Benutzers die Anzeige einer Seite ausgelöst wird,
die den Benutzer auffordert, einen Befehl zum Beenden der laufenden
Dialogsitzung auszugeben.
-
Gemäß noch einer
weiteren Besonderheit der Erfindung weist es, wenn eine aufgefangene
Antwort einen Befehl zum Beenden der Dialogsitzung enthält, außerdem einen
Schritt des Beendens der Dialogsitzung auf, um eine Dialogsitzung
entsprechend der aus der Antwort entnommenen Benutzeridentifikationsinformation
zu beenden.
-
Vorteilhafterweise
wird das Beenden einer Dialogsitzung von der Veränderung der entsprechenden
Antwort begleitet, die den Befehl zum Beenden der Dialogsitzung
enthält,
um im Terminal des Benutzers die Anzeige einer Seite auszulösen, die
den Benutzer auffordert, sich wieder mit einer Internetseite zu
verbinden, deren Zugriff geschützt
ist.
-
Die
Erfindung betrifft auch ein System der Zugriffskontrolle zu Internetseiten
von Inhalte- oder Dienst-Anbieter, um den Zugriff von Terminals
zu diesen Seiten über
ein Datenübertragungsnetz
zu kontrollieren.
-
Erfindungsgemäß weist
dieses System einen Zugriffskontrollserver auf, der mit einem Cache-Server
verbunden ist, der zwischen die Benutzerterminals und das Datenübertragungsnetz
geschaltet ist, wobei der Cache-Server so gestaltet ist, dass er
alle Antworten auffängt,
die vom Netz kommen und für
die Benutzerterminals bestimmt sind, und dass er die aufgefangenen
Antworten an den Zugriffskontrollserver überträgt, wobei der Zugriffskontrollserver
aufweist:
- – Mittel,
um aus jeder der aufgefangenen Antworten eine Benutzeridentifikationsinformation,
eine Internet-Adresse und einen Internet-Zugriffscode zu entnehmen,
- – Mittel,
um zu bestimmen, ob die entnommene Internet-Adresse einer Internetseite
entspricht, deren Zugriff kontrolliert wird, und ob es eine laufende
Dialogsitzung entsprechend der entnommenen Benutzeridentifikationsinformation
gibt,
- – Mittel,
um eine Dialogsitzung für
den Benutzer entsprechend der entnommenen Benutzeridentifikationsinformation
zu starten, wenn es keine der entnommenen Benutzeridentifikationsinformation entsprechende
laufende Dialogsitzung gibt und wenn der entnommene Zugriffscode
gültig
ist,
- – Mittel,
um alle aufgefangenen Antworten, die eine Benutzeridentifikationsinformation
und einen Internet-Zugriffscode entsprechend einer laufenden Dialogsitzung
enthalten, zu verändern,
um im Terminal des Benutzers die Anzeige eines Befehls zum Beenden
der Dialogsitzung auszulösen,
den der Benutzer aktivieren kann, wenn er keinen Zugriff mehr zur
Internetseite möchte,
und
- – Mittel,
um die aufgefangenen und veränderten Antworten
zum Cache-Server an die Adresse der Benutzerterminals zurück zu übertragen.
-
Vorteilhafterweise
ist die aus den aufgefangenen Antworten entnommene Benutzeridentifikationsinformation
eine Benutzeradresse im Datenübertragungssystem,
wobei das System außerdem
Mittel aufweist, um ausgehend von der Adresse des Benutzers mit
Hilfe einer Entsprechungstabelle eine Benutzerkennung zu bestimmen.
-
Vorzugsweise
ist die Entsprechungstabelle ein Verzeichnis vom Typ LDAP.
-
Gemäß einer
Besonderheit der Erfindung weist dieses System einen Cache-Speicher
auf, der so gestaltet ist, dass er Antworten auf Benutzerkennungsabfragen speichert,
die vom Verzeichnis vom Typ LDAP geliefert werden, um schneller
eine Antwort auf eine Abfrage liefern zu können, wenn die Antwort im Cache-Speicher
gespeichert ist.
-
Gemäß einer
weiteren Besonderheit der Erfindung weist dieses System eine Dialogsitzung-Ablaufdatei
auf, die für
jede Dialogsitzung eine Benutzerkennung, eine Internet-Kennung,
einen laufenden oder beendeten Zustand der Dialogsitzung, eine Dialogsitzungsdauer
und eine Anfangszeit der Dialogsitzung enthält.
-
Vorzugsweise
entsprechen die aufgefangenen Antworten dem HTTP-Protokoll, und
die Kommunikationen zwischen dem Cache-Server und dem Zugriffskontrollserver
entsprechen dem ICAP-Protokoll.
-
Nachfolgend
wird eine bevorzugte Ausführungsform
der Erfindung als nicht einschränkend
zu verstehendes Beispiel unter Bezugnahme auf die beiliegenden Zeichnungen
beschrieben. Es zeigen:
-
1 ein
erfindungsgemäßes Zugriffskontrollsystem,
das in die Verbindung zwischen Benutzerterminals und Servern von
Inhalte- oder Dienst-Anbietern integriert ist, auf die über das
Internet zugegriffen werden kann;
-
2 ausführlicher
das in 1 dargestellte System;
-
3 in
Form eines Organigramms ein erfindungsgemäßes Zugriffskontrollverfahren,
das im in 2 dargestellten System implementiert
wird;
-
4 im
Einzelnen einen Teil des in 2 dargestellten
Systems.
-
Das
in 1 gezeigte Zugriffskontrollsystem zu Internetseiten
ist so gestaltet, dass es sich zwischen feste oder mobile Benutzerterminals 10a-10c und
das Internet 1 zwischenschaltet, das Zugriff zu Servern 4 von
Inhalte- oder Dienst-Anbietern gestattet. In üblicher Weise sind die Benutzerterminals 10a-10c mit
dem Internet 1 über
ein öffentliches Fernsprechnetz 2,
wie zum Beispiel ein festes oder mobiles Telefonnetz, und über einen
Internet-Zugriffsanbieter 6 verbunden.
-
Ein
solcher Zugriffsanbieter implementiert im Allgemeinen einen Cache-Server 3,
der sich auf der Verbindung zwischen dem Fernsprechnetz 2 und dem
Internet 1 befindet.
-
Um
eine Zugriffskontrolle zu den Servern 4 einzusetzen, wird
erfindungsgemäß der Server 3 mit einem
Zugriffskontrollserver 5 verbunden und kommuniziert mit
letzterem gemäß dem ICAP-Protokoll, damit
die von den Servern 4 an die Benutzerterminals 10a-10c ausgegebenen
HTTP-Antworten vom Cache-Server 3 zum Zugriffskontrollserver 5 umgeleitet
werden. Außerdem
ist der Server 5 in Form eines ICAP-Diensts ausgebildet,
der erfindungsgemäß konzipiert
ist, um eine Dialogsitzungsverwaltung zu gewährleisten.
-
2 zeigt
ausführlicher
den Cache-Server 3 und den Zugriffskontrollserver 5.
Der Cache-Server 3 enthält
einen Modul 21, der so gestaltet ist, dass er alle von
den mit dem Server 3 verbundenen Benutzerterminals 10a-10c gesendeten
Anforderungen an das Internet 1 zurück überträgt, sowie einen Modul 22,
der so gestaltet ist, dass er alle HTTP-Antworten an den Zugriffskontrollserver 5 zurück überträgt, die von
den Servern 4 empfangen wurden und für die Benutzerterminals 10a-10c bestimmt
sind. Der Server 3 weist ebenfalls einen Speicher 23 auf,
um vorübergehend
alle diese Antworten zu speichern, um sie ohne Zugriff auf das Internet 1 wiederherzustellen,
wenn die Terminals, für
die sie bestimmt waren, sie erneut verlangen.
-
In 2 weist
der Zugriffskontrollserver 5 auf:
- – einen
Hauptmodul 11, der die eigentlichen Zugriffskontrollfunktionen
gewährleistet,
wobei dieser Modul auf eine Konfigurationsdatei 16 des
Zugriffskontrolldiensts zugreifen kann und die Austauschvorgänge mit
dem Cache-Server 3 verwaltet,
- – einen
Dialogsitzungsverwaltungsmodul 14, der den Zugriffskontrollmodul 11 steuert,
um die Aktualisierung einer Dialogsitzung-Ablaufdatei 15 zu gewährleisten,
und
- – einen
Teilnehmerverzeichnis-Schnittstellenmodul 12, der mit dem
Modul 11 verbunden ist und zum Beispiel das LDAP-Protokoll
(Lightweight Directory Access Protocol) implementiert, um zu einem
LDAP-Teilnehmerverzeichnis 13 von
Benutzern des Zugriffsanbieters Zugriff zu gestatten.
-
Die
Austauschvorgänge
zwischen dem Modul 11 und dem Cache-Server 3 entsprechen
dem ICAP-Protokoll. So überträgt der Cache-Server 3 alle HTTP-Antworten,
die in ICAP-Anforderungen verkapselt empfangen werden, diese Antworten
werden anschließend
vom Modul 11 verarbeitet und in einer ICAP-Antwort verkapselt
an den Server 3 zurückgeschickt.
-
Das
Teilnehmerverzeichnis 13, das von dem Verbindungsdienst
aktualisiert wird, der vom Zugriffsanbieter angeboten wird, enthält insbesondere ID_CL-Kennungen
der Benutzer zum Beispiel gegenüber
dem Zugriffsanbieter, wobei jede ID_CL-Benutzerkennung ggf. einer
IP-Adresse (Internet Protocol) zugeordnet ist, die vom Anbieter
dem Benutzer zugeteilt wird, wenn dieser eine Verbindung mit dem Internet 1 herstellt.
-
Für eine bessere
Effizienz kann der Server 5 ebenfalls einen LDAP-Cache-Speicher 17 aufweisen,
um vorübergehend
die vom LDAP-Teilnehmerverzeichnis 13 gelieferten Antworten
zu speichern, wenn der Zugriffskontrollmodul 11 eine Anforderung des
Teilnehmerverzeichnisses für
den gleichen Benutzer wiederholen muss.
-
Die
Konfigurationsdatei 16 enthält insbesondere die folgenden
Informationen:
- – den vollständigen Zugriffsweg
zur Dialogsitzung-Ablaufdatei 15,
- – die
Identifikation des Kommunikationsports, der von dem Zugriffskontrollmodul 11 zu
verwenden ist, um mit dem Dialogsitzung-Verwaltungsmodul 14 zu
dialogisieren oder ihn abzuhören,
- – die
maximale Länge
der Warteschlange, die dem Kommunikationskanal zwischen dem Zugriffskontrollmodul 11 und
dem Dialogsitzungsverwaltungsmodul 14 zugeordnet ist,
- – die
URL-Adresse einer Internetseite, die die Anzeige eines Bildschirm-Fensterstreifens
aufweist, der einen Steuerknopf zum Trennen einer Internetseite
enthält,
deren Zugriff kontrolliert wird,
- – die
Höhe dieses
Streifens,
- – die
URL-Adresse einer Internetseite, die einen Knopf zum Trennen einer
Internetseite enthält, deren
Zugriff kontrolliert wird,
- – die
URL-Adresse einer Internetseite, die Zugriff zu einem Befehl zur
Wiederverbindung mit einer Internetseite gestattet, deren Zugriff kontrolliert wird,
und
- – eine
Liste von URL-Adressen von Internetseiten, deren Zugriff kontrolliert
wird, wobei jede Adresse einer URL-Kennung ID_URL zugeordnet ist,
die als vertraulicher Zugriffscode dient, und die URL-Adresse einer
Startseite der Internetseite, die ein Formular zur Verbindung mit
der Internetseite enthält.
-
Die
Dialogsitzung-Ablaufdatei 15 enthält die folgenden Informationen
für jede
laufende Dialogsitzung:
- – eine Benutzerkennung ID_CL
des Benutzers, der während
der Dialogsitzung auf die durch ID_URL identifizierte Internetseite
zugreift,
- – eine
ID_URL-Kennung der Internetseite, deren Zugriff kontrolliert wird,
und auf die für
die Dialogsitzung vom Benutzer zugegriffen wird,
- – einen
Dialogsitzung-Zustandsindikator, der angibt, ob die Dialogsitzung
gerade abläuft
oder beendet ist,
- – die
Dauer der Dialogsitzung in Form einer ganzen Zahl, die die Anzahl
von seit dem Start der Dialogsitzung vergangenen Sekunden darstellt,
wobei dieses Feld auf 0 ist, wenn die Dialogsitzung läuft, und
- – die
Uhrzeit des Beginns der Dialogsitzung, wobei dieses Feld auf 0 ist,
wenn die Dialogsitzung beendet ist.
-
3 zeigt
die Verfahrensweise 30 gemäß dem erfindungsgemäßen Verfahren,
die vom Zugriffskontrollmodul 11 ausgeführt wird, wenn er eine HTTP-Antwort
empfängt,
die vom Internet kommt und für ein
Benutzerterminal 10a-10c des Zugriffsanbieters 6 bestimmt
ist.
-
Im
ersten Schritt 31 dieser Verfahrensweise analysiert der
Modul 11 die vom Benutzer ausgegebene HTTP-Anforderung, die
in der empfangenen HTTP-Antwort enthalten ist, um daraus die IP-Adresse
des Benutzerterminals, die vom Benutzer angeforderte URL-Adresse und ggf.
eine ID_URL-Kennung der Internetseite zu entnehmen, deren Zugriff
kontrolliert wird.
-
Im
folgenden Schritt 32 fragt der Modul 11 das LDAP-Teilnehmerverzeichnis 13 über den LDAP-Schnittstellenmodul 12 ab,
um die Kennung des entsprechenden Benutzers an der entnommenen IP-Adresse
zu erhalten. Wenn der Schnittstellenmodul 12 die Antwort
zurücksendet,
führt der
Modul 11 den folgenden Schritt 33 durch, der darin
besteht, zu bestimmen, ob der Benutzer, der die aus der HTTP-Anfrage
entnommene IP-Adresse hat, erkannt wurde. Wenn dies nicht der Fall
ist, kann der Benutzer nicht vom Zugriffskontrolldienst profitieren,
und der Modul 11 überträgt an diesen
die vom Server 4, auf den er zugegriffen hat (Schritt 34),
gesendete Antwort ohne Veränderung.
Im gegenteiligen Fall führt
der Modul 11 den Schritt 35 durch, der darin besteht,
die Dialogsitzung-Ablaufdatei 15 zu lesen, um festzustellen,
ob es eine laufende Dialogsitzung für die Kennung des Benutzers
ID_CL gibt, die vom Schnittstellenmodul LDAP 12 geliefert
wurde.
-
Wenn
dem Benutzer ID_CL keine laufende Dialogsitzung zugeordnet ist,
führt der
Modul 11 den Schritt 36 durch, der darin besteht,
mit Hilfe der Konfigurationsdatei 16 festzustellen, ob
die vom Benutzer in seiner Anforderung angeforderte URL-Adresse einer
URL-Adresse einer Internetseite entspricht, deren Zugriff kontrolliert
ist. Wenn dies nicht der Fall ist, geht der Modul 11 zum
Schritt 34 der Übertragung der
HTTP-Antwort, die vom Server 4 empfangen wurde, zum Terminal
des Benutzers ohne Veränderung über. Im
gegenteiligen Fall führt
der Modul 11 den Schritt 37 durch, der darin besteht,
festzustellen, ob die HTTP-Anforderung
eine gültige
ID_URL-Kennung der Internetseite, deren Zugriff kontrolliert wird, enthält oder
nicht.
-
Wenn
die Anforderung eine ID_URL-Kennung enthält, wird diese Kennung durch
das Lesen der Dialogsitzung-Ablaufdatei 15 überprüft, indem die
ID_URL-Kennung betrachtet wird, die einer auf den Start wartenden
Dialogsitzung entspricht.
-
Im
gegenteiligen Fall führt
der Modul 11 den Schritt 38 aus, der einerseits
darin besteht, den Inhalt der empfangenen HTTP-Antwort durch ein
Verbindungsformular zu ersetzen, das den Benutzer auffordert, eine
ID_URL-Kennung der
Internetseite, auf die er zugreifen möchte, einzugeben, die ihm vorher
mitgeteilt wurde, und andererseits darin besteht, diese Antwort über den
Cache-Server 3 an den Benutzer zu senden.
-
Wenn
der Benutzer von Vorteilen profitieren möchte (zum Beispiel reduzierte
Verbindungskosten oder eine Gratis-Verbindung), füllt er das Formular aus und
schickt es in Form einer Anforderung an die Internetseite zurück, deren
Zugriff kontrolliert wird. Dieses Formular wird in Form einer Antwort
an den Benutzer zurückgeschickt
und vom Cache-Server 3 aufgefangen, der es an den Server 5 sendet.
Der Empfang dieser Antwort durch den Server 5 löst erneut
die Verfahrensweise 30 aus, und in diesem Fall enthält die in
der Antwort enthaltene Anforderung eine Internetseite-Kennung ID_URL.
-
Wenn
im Schritt 37 die in der Antwort enthaltene HTTP-Anforderung eine
gültige
ID_URL-Kennung der Internetseite enthält, deren Zugriff kontrolliert
wird (in dem Fall, in dem die Dialogsitzung-Ablaufdatei 15 keine
laufende Dialogsitzung für
den identifizierten Benutzer enthält), führt der Modul 11 den
Schritt 39 aus, der darin besteht, eine Dialogsitzung zu
starten, indem die Zeile in der Dialogsitzung-Ablaufdatei 15 geändert wird,
die für
die Kennungen des Benutzers ID_CL und der Internetseite ID_URL eine
laufende Dialogsitzung spezifiziert, die am laufenden Datum gestartet
wurde. Zu diesem Zweck schreibt er in diese Zeile die laufende Uhrzeit als
Uhrzeit des Beginns der Dialogsitzung und setzt den Wert der Dialogsitzungsdauer
auf 0.
-
Im
folgenden Schritt 40 verändert der Modul 11 die
als Antwort vom Server 4 gesendete Internetseite, indem
er einen Trennungsstreifen hinzufügt, der einen Trennungsknopf
enthält.
-
Wenn
im Schritt 35 eine Dialogsitzung stattfand, führt der
Modul 11 den Schritt 41 durch, der darin besteht,
festzustellen, ob die Internetseiten-Kennung ID_URL derjenigen entspricht,
die in die Dialogsitzung-Ablaufdatei 15 für die entsprechende
Dialogsitzung eingetragen ist, und ob die in der HTTP-Anforderung
angeforderte URL-Adresse der von der Kennung ID_URL bezeichneten
Internetseite entspricht. Wenn dies nicht der Fall ist, ersetzt
der Modul 11 den Inhalt der HTTP-Antwort durch eine Trennungsseite, die
den Benutzer auffordert, sich von der gerade abgefragten Internetseite
zu trennen, deren Zugriff kontrolliert wird, ehe er auf die in der
Anforderung angeforderte URL-Adresse zugreift, dann sendet er dieser
veränderte
HTTP-Antwort zum Terminal des Benutzers (Schritt 42). Im
gegenteiligen Fall führt der
Modul 11 den Schritt 43 durch, der darin besteht, zu
untersuchen, ob der Inhalt der HTTP-Anforderung eine Trennungs-Anforderung
enthält.
Wenn dies nicht der Fall ist, geht der Modul 11 zum Schritt 40 über, in
dem die HTTP-Antwort der Internetseite zum Terminal des Benutzers
mit dem Trennungsstreifen übertragen
wird. Wenn dagegen die HTTP-Anforderung eine Trennungsanforderung
enthält, führt der Modul
den Schritt 44 aus, der darin besteht, die Dialogsitzung
in der Dialogsitzung-Ablaufdatei 15 zu beenden. Auf diesen
Schritt folgt ein Schritt 45 des Einfügens eines Formulars zum Wiederverbinden
in die HTTP-Antwort und des Sendens dieser Antwort an den Benutzer.
Das Wiederverbindungsformular ermöglicht es, dass der Benutzer
nicht erneut die ID_URL-Kennung eingeben muss, wenn er wieder mit
der Internetseite verbunden werden will, die er soeben verlassen
hat.
-
Um
eine Dialogsitzung zu beenden, aktualisiert der Modul 11 die
Dialogsitzung-Ablaufdatei 15, indem er den Wert des Dialogsitzungszustands ändert, um
anzuzeigen, dass die Dialogsitzung beendet ist, und indem er das
Feld Dauer aktualisiert, indem er die Laufdauer der Dialogsitzung
zwischen der laufenden Uhrzeit und der Uhrzeit des Beginns der Dialogsitzung
berechnet, die in dem Feld angezeigt ist, das die Uhrzeit des Dialogsitzungsbeginns
enthält. Schließlich setzt
er den Wert dieses letzten Felds auf 0.
-
Außerdem verwaltet
der Dialogsitzungsverwaltungsmodul 14 Verzögerungen,
die beim Start jeder Dialogsitzung ausgelöst und bei jeder Anforderung
reaktiviert werden, die für
die Dialogsitzung vom Modul 11 durchgeführt wird, um die laufenden
Dialogsitzungen zu beenden, für
die der Server 5 während der
Dauer der Verzögerung
keine zum entsprechenden Benutzer gesendete Antwort empfangen hat.
-
Wie
in 4 dargestellt, kann der Modul 11 in Form
eines Moduls 25 hergestellt werden, der den eigentlichen
Dienst der Zugriffskontrolle und der Transformation von HTTP-Antworten
unabhängig vom
ICAP-Protokoll gewährleistet,
wobei dieser Modul mit einem ICAP-Flussadapter 26 gekoppelt
ist, der die durchgeführten
Austauschvorgänge
mit dem Cache-Server 3 gemäß dem ICAP-Protokoll verwaltet.
Ein solcher ICAP-Flussadapter
ist in der französischen
Patentanmeldung beschrieben, die von der Anmelderin eingereicht
und unter der Nummer 2 823 044 veröffentlicht wurde.