DE69921455T2

DE69921455T2 - System und verfahren zur zugriffssteuerung auf gespeicherte dokumente

Info

Publication number: DE69921455T2
Application number: DE69921455T
Authority: DE
Inventors: R. Richard VIETS; G. David MOTES; Budig Paula GREVE; W. Wayne HERBERG
Original assignee: Secure Computing LLC
Current assignee: Secure Computing LLC
Priority date: 1998-02-17
Filing date: 1999-02-17
Publication date: 2005-08-18
Anticipated expiration: 2019-02-18
Also published as: US7543329B2; US20040003293A1; US20020091532A1; US6640307B2; DE69921455D1; EP1057310B1; US6357010B1; WO1999041888A1; EP1057310A1

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf Systeme und Verfahren zur Steuerung der Kommunikation zwischen Netzwerken und insbesondere auf ein System und Verfahren zur Kontrolle des Zugangs zu in einem internen Netzwerk gespeicherten Dokumenten.
Hintergrundinformationen
Unternehmen arbeiten heutzutage zusammen, um miteinander vereinbare Unternehmensziele zu erreichen. So nutzen Unternehmen zum Beispiel Just-in-Time-Produktionsverfahren, um die Gemeinkosten zu senken. Damit dies funktioniert, verlassen sich die Unternehmen in hohem Maße auf die Fähigkeit ihrer Lieferanten, Materialien bedarfsgerecht zu liefern.
Gleichzeitig haben sich Führungskräfte von Unternehmen in diesem digitalen Zeitalter daran gewöhnt, nahezu unmittelbar Informationen aus einer Vielzahl von Quellen sowohl innerhalb als auch außerhalb des Unternehmens zu erhalten. Sie stützen sich auf derartige Informationen für ihre Managemententscheidungen im Tagesgeschäft.
Um außen stehende Organisationen zeitnah mit relevanten Informationen zu versorgen, haben viele Firmen ihre Abteilungen zur Auftragsabwicklung erweitert, um mehr Anrufe annehmen zu können. In dieser Umgebung rufen externe Partner bei der Auftragsbearbeitungsabteilung an, um bestimmte Informationen zu erfragen. Dies macht es erforderlich, dass ein Mitarbeiter verfügbar ist, der Anrufe entgegennimmt, Informationen heraussucht und diese mündlich an den Partner weitergibt. Diese Möglichkeit ist sehr aufwändig und langsam und bietet nur eine geringe Servicequalität. Benötigt wird daher ein System und Verfahren zur Optimierung des Informationsflusses zwischen Partnerunternehmen bei gleichzeitiger Beschränkung des Zugangs zu geschützten Unternehmensinformationen.
Das Internet bietet eine mögliche Lösung für dieses Problem. Das Internet ist von seiner Natur her für Unternehmen ein ideales Medium zur Kommunikation und zum Informationsaustausch. Das Internet ermöglicht einen preiswerten, universellen Zugang zu Informationen. Daher wird erwartet, dass Internet-Transaktionen sich in den kommenden zwei Jahren mehr als vervierfachen werden und dass sich die Anzahl der Kommunikationsvorgänge zwischen Partnern über das Internet beinahe verdoppeln wird. Unternehmen haben begonnen, das Internet als ein Medium für die schnelle, einfache und preiswerte Kommunikation mit Geschäftspartnern zu sehen. Bisher jedoch waren ihre Internet-Optionen begrenzt.
Eine Lösung sieht vor, Geschäftspartnern Zugang zum internen Netzwerk des Unternehmens zu geben. Unternehmen zögern jedoch, dies zu tun, weil ein derartiger Zugang im Falle des Missbrauchs zur Offenlegung sensibler Unternehmensinformationen führen kann.
Eine andere Lösung ist das Replizieren der nötigen Informationen auf einem Web-Server, der sich außerhalb der Firewall des Unternehmens befindet. Ein solches Vorgehen erlaubt Organisationen den direkten Zugang zu Informationen, begrenzt aber gleichzeitig ihren Zugang zu sensiblen Unternehmensinformationen. Damit diese Umgebung jedoch funktionieren kann, muss die MIS-Abteilung manuell Informationen aus dem internen Netzwerk auf den externen Server übertragen. Daher können, auch wenn diese Möglichkeit Organisationen den direkten Zugang zu den nötigen Daten erlaubt, die Informationen 24 bis 48 Stunden alt sein. In Zusammenhang mit Just-in-Time-Bestandsmengen und hohen Geldbeträgen sind 24 Stunden aber ein zu langer Zeitraum. Diese Option verursacht auch Engpässe in der MIS-Abteilung, Redundanz von Daten und geringere Datenintegrität.
Was benötigt wird, ist ein System und Verfahren zur Gewährung des kontrollierten Zugangs zu ausgewiesenen Dokumenten, die im internen Netzwerk gespeichert sind, bei gleichzeitiger Beschränkung des Zugangs zu sensiblen Unternehmensinformationen.
J. Kahan beschreibt in „A capability-based authorisation model for the World-Wide Web", Computer Networks and ISDN Systems, Vol. 27 (1995), Seiten 1055 bis 1064, ein Verfahren zum Betrieb eines Systems mit einem Dokumentenüberwachungsserver zum Überwachen des Zugangs zu Dokumenten auf Dokumentenservern in einem internen Netzwerk, wobei der Dokumentenüberwachungsserver eine Klientenliste und eine Dokumentenliste mit für Klienten verfügbaren Dokumenten aufweist und das Verfahren die folgenden von dem Dokumentenüberwachungsserver ausgeführten Schritte umfasst:
Empfangen einer Anfrage für ein im internen Netzwerk gespeichertes Dokument und
Verknüpfen der Anfrage mit einem der Klienten.
EP-A-0 811 939 beschreibt ein Verfahren zum Bereitstellen von Dokumenten für einen Klienten in Verbindung mit einem Server, der als ein Caching-Proxy im Namen des Klienten für den Zugang zum Internet fungiert. Der Proxy-Server kann benutzt werden, um Daten in einem Dokument zu ändern, beispielsweise durch Entfernen eines Links in dem Dokument.
Zusammenfassung der Erfindung
Nach einem Aspekt der vorliegenden Erfindung ist das Verfahren dadurch gekennzeichnet, dass die Dokumentenliste die für einen Klienten verfügbaren Dokumente definiert, so dass diese von einer Funktion abhängen, der der Klient zugeordnet ist,
jede Funktion eine damit verknüpfte Untermenge von Dokumenten aufweist, zu denen der Zugang gewährt werden kann, und
der Dokumentenüberwachungsserver in der Klientenliste nach dem Klienten schaut, um zu bestimmen, welcher Funktion der Klient zugeordnet ist,
der Dokumentenüberwachungsserver in der Untermenge nachschaut, die mit der dem Klienten zugeordneten Funktion verknüpft ist, um zu bestimmen, ob das angefragte Dokument vorhanden ist, und
der Dokumentenüberwachungsserver bei Vorhandensein des angefragten Dokuments dieses von dem Dokumentenserver abruft und es an den Klienten weiterleitet.
Nach einem weiteren Aspekt stellt die Erfindung ein Dokumentenüberwachungssystem bereit, umfassend:
ein internes Netzwerk,
eine externe Schnittstelle,
einen mit dem internen Netzwerk verbundenen Dokumentenserver, wobei der Dokumentenserver mehrere Dokumente enthält, und
einen Dokumentenüberwachungsserver, der eine Klientenliste aufweist und eine Anfrage für ein im Dokumentenserver gespeichertes Dokument empfangen, die Anfrage mit einem der Klienten verknüpfen und dessen Berechtigung überprüfen kann,
dadurch gekennzeichnet, dass die Dokumentenliste die für einen Klienten verfügbaren Dokumente definiert, so dass sie von einer Funktion abhängen, der der Klient zugeordnet ist,
der Dokumentenüberwachungsserver im Betriebszustand in der Klientenliste nach dem Klienten schaut, um zu bestimmen, welcher Funktion der Klient zugeordnet ist,
der Dokumentenüberwachungsserver einen Zugangslistenprozessor aufweist, der eine Untermenge von Dokumenten enthält, zu denen der Zugang auf der Grundlage der Funktion des Klienten gewährt werden kann, und
der Dokumentenüberwachungsserver einen Dokumentenprozessor aufweist, so dass dieser, wenn der Zugangslistenprozessor entscheidet, dass der Klient Zugang zu einem Dokument erhalten kann, im Betriebszustand das Dokument vom Dokumentenserver abruft und an den Klienten weiterleitet.
Bei dem erfindungsgemäßen Verfahren kann jedes Dokument eine eindeutige URL haben, und die Dokumentenliste kann die URL jedes verfügbaren Dokuments enthalten, und der Schritt des Bestimmens, ob das angefragte Dokument vorhanden ist, umfasst den Schritt des Bestimmens, ob die URL des angefragten Dokuments in der Dokumentenliste enthalten ist.
Das Verfahren kann auch den Schritt des Anzeigens der verfügbaren Dokumente in einer Baumstruktur innerhalb einer grafischen Benutzeroberfläche (GUI) umfassen, und dieses Anzeigen umfasst das Abfragen eines Dokumentenüberwachungsservers, um eine aktuelle Version der Dokumentenliste zu erhalten.
Falls erwünscht, kann der Schritt des Verknüpfens der Anfrage mit einem Klienten auch den Schritt zur Überprüfung der Berechtigung des Klienten umfassen.
Nach einem weiteren Aspekt sieht die Erfindung ein Computerprogramm vor, das von einem Prozessor implementierbare Anweisungen zum Steuern eines Dokumentenüberwachungsservers zum Durchführen aller Schritte eines erfindungsgemäßen Verfahrens umfasst.
Kurzbeschreibung der Zeichnungen
In den Zeichnungen bezeichnen gleiche Bezugszeichen gleiche Komponenten in den verschiedenen Ansichten.
1 zeigt ein Dokumentenüberwachungssystem.
2 zeigt ein Ablaufdiagramm der von dem Dokumentenüberwachungssystem in 1 ausgeführten Operationen.
3 zeigt einen Dokumentenüberwachungsserver, der in dem in 1 gezeigten Dokumentenüberwachungssystem benutzt werden kann.
4 zeigt ein Dokumentenüberwachungssystem mit einer Firewall.
5 zeigt ein Dokumentenüberwachungssystem, bei dem der Dokumentenüberwachungsserver in einem dritten Netzwerk angeordnet ist.
6 zeigt ein Dokumentenüberwachungssystem, bei dem der Dokumentenüberwachungsserver in einem externen Netzwerk angeordnet ist.
7 zeigt ein Beispiel für eine Baumstrukturdarstellung, die benutzt werden kann, um dem Dateneigentümer bei der Auswahl zulässiger URLs zu helfen.
Beschreibung der bevorzugten Ausführungsformen
In der nachstehenden ausführlichen Beschreibung der bevorzugten Ausführungsformen wird auf die zugehörigen Zeichnungen verwiesen, in denen zur Illustration bestimmte Ausführungsformen der Erfindung gezeigt sind. Andere Ausführungsformen sind ebenfalls möglich, und es können strukturelle Veränderungen vorgenommen werden, ohne vom Umfang der vorliegenden Erfindung abzuweichen.
Wie vorstehend erwähnt, wird von Unternehmen heute seitens der Kunden erwartet, dass sie Informationen wie Preisänderungen, neue Produktdaten, Herstellungsdaten und Kundensupport auf elektronischem Wege bereitstellen. Der Wettbewerb veranlasst Firmen, über enge Verbindungen zu internen Systemen mit Partnern zusammenzuarbeiten. Die Gewährung des Zugangs zu solchen Daten in einer effizienten, kontrollierbaren und sicheren Weise stellt jedoch eine schwierige Aufgabe und Herausforderung dar. Unternehmen treiben einen enormen Aufwand, um Auftragsbearbeitungsabteilungen einzurichten und große Mengen interner Daten auf einem externen Internet-Server zu replizieren. Diese Anstrengungen sind nicht nur ineffizient, sondern führen in der Regel auch zu Redundanz von Daten, verminderter Netzwerkintegrität und Engpässen in der MIS-Abteilung.
Die vorliegende Erfindung löst dieses Problem, indem bestimmten externen Benutzern ein kontrollierter, individuell abgestimmter und sicherer Zugang zum Intranet des Unternehmens gewährt wird, ohne dass komplizierte Änderungen der Netzwerk-Infrastruktur erforderlich sind. Darüber hinaus ermöglicht die vorliegende Erfindung die Kontrolle der Teile eines Web-Servers, die für einen Geschäftspartner mit nur minimalem Zutun seitens des IT-Personals zugänglich sind. (Der Begriff „Geschäftspartner" wird in der folgenden Diskussion verwendet, um einen externen Benutzer zu beschreiben, der Zugang zu Daten wie zum Beispiel Web-Seiten benötigt, die der Öffentlichkeit nicht allgemein zugänglich sind, jedoch keinen unbegrenzten Zugang zu den Intranet-Web-Diensten eines Unternehmens haben soll.)
Ein Dokumentenüberwachungssystem, das einen kontrollierten Zugang zu ausgewiesenen Dokumenten gewährt, die in einem internen Netzwerk gespeichert sind, und gleichzeitig den Zugang zu sensiblen Unternehmensinformationen beschränkt, ist in 1 gezeigt. Das Dokumentenüberwachungssystem 10 in 1 umfasst einen Dokumentenüberwachungsserver 12, einen Dokumentenserver 14, eine externe Schnittstelle 16 und eine oder mehrere interne Workstations 18. Der Dokumentenüberwachungsserver 12, der Dokumentenserver 14, die externe Schnittstelle 16 und die internen Workstations 18 sind über ein internes Netzwerk 20 miteinander verbunden. Der Dokumentenserver 14 liest und schreibt Dokumente in dem Speicher 20. Anfragen für Dokumente kommen an der externen Schnittstelle 16 an und werden zur Ausführung an den Dokumentenüberwachungsserver 12 weitergeleitet. Bei einer Ausführungsform umfasst die externe Schnittstelle 16 einen Router zum Herstellen einer Internetverbindung. Bei einer anderen Ausführungsform weist die externe Schnittstelle 16 eine Direktverbindungsschnittstelle auf, die zum Beispiel aus einem oder mehreren Modems besteht, die für die direkte Einwahl durch Geschäftspartner benutzt werden, die auf ihre Daten zugreifen wollen.
Bei einer Ausführungsform, wie in 2 gezeigt, empfängt der Dokumentenüberwachungsserver 12 in Schritt 30 von der externen Schnittstelle eine Dokumentenanfrage für ein erstes Dokument. In Schritt 32 bestimmt der Dokumentenüberwachungsserver 12 einen Benutzer, der mit der Dokumentenanfrage verknüpft ist, und überprüft dessen Berechtigung. In Schritt 34 prüft das System 10, ob der Benutzer berichtigt ist, Zugang zu dem angefragten Dokument zu erhalten. Falls ja, ruft das System 10 in Schritt 36 das Dokument vom Dokumentenserver 14 ab, bereinigt oder säubert das Dokument in Schritt 38 und leitet die bereinigte Version des Dokuments in Schritt 40 an den Benutzer weiter. Eine Ausführungsform für ein solches System und Verfahren ist nachstehend für ein HTTP-System (HyperText Transfer Protocol) beschrieben.
Wenn eine HTTP- oder HTTPS-Verbindungsanfrage bei dem Dokumentenüberwachungsserver 12 eingeht, müssen drei kritische Funktionen ausgeführt werden, ehe die angeforderte Web-Seite als Antwort erscheint: Authentifizierung, Autorisierung und Herstellen der internen Verbindung. Wenn eine der beiden ersten Funktionen fehlschlägt, wird die interne Verbindung nicht hergestellt. Sobald die interne Verbindung hergestellt ist, muss der Dokumentenüberwachungsserver 12 die Web-Seite analysieren und bereinigen/säubern, ehe er sie an den anfordernden Benutzer weiterleitet.
Authentifizierung
Die Authentifizierung ist relativ unkompliziert und natürlich transparent für den Endbenutzer. Wenn ein Benutzer eine URL-Adresse (Uniform Resource Locator) in seinem Browser eingibt und die Anforderung in Schritt 30 (siehe 2) beim Server 12 eingeht, wird nach dem HTTP-Protokoll in Schritt 32 eine Kontrolle zur Authentifizierung vorgenommen. Bei der einfachen Authentifizierung wird kontrolliert, ob Authentifizierungsinformationen im HTTP-Header enthalten sind. Wird kein Benutzername und kein Passwort gefunden, antwortet der Server mit einem Fehler 401 („401 error") an den Browser, der dem Browser mitteilt, dass er sich authentifizieren muss. Der Browser öffnet daraufhin eine Dialogbox, in der der Benutzer aufgefordert wird, einen Benutzernamen und das Passwort einzugeben. Kommt die HTTP-Anfrage beim Server an, analysiert der Dokumentenüberwachungsserver 12 den Benutzernamen und das Passwort, vergleicht es mit seiner internen Benutzerdatenbank und lässt das Überwachungsverfahren zum Autorisierungsschritt übergehen, wenn er eine Übereinstimmung findet. Wird keine Übereinstimmung gefunden, gibt der Dokumentenüberwachungsserver 12 einen Fehlercode zurück an den Web-Server, unter dem er läuft (z.B. Internet Information Server oder Netscape Enterprise Server), und der Server sendet erneut einen Fehler 401 zur Anforderung von Benutzername und Passwort. Dieser Vorgang kann bis zu dreimal ablaufen; danach verweigert der Server den Zugriff. Bei einer Ausführungsform erfolgt diese Authentifizierung durch Kontrolle einer Datenbank bekannter Benutzer anstatt durch Überprüfung einer Benutzerdatenbank durch den Web-Server, die dieser möglicherweise hat.
Autorisierung
Sobald der Dokumentenüberwachungsserver 12 die Anfrage authentifiziert hat, muss er in Schritt 34 bestimmen, ob der Benutzer berechtigt ist, zu der angeforderten URL zu gelangen. Diese Autorisierung schlägt fehl, wenn die vom Benutzer angeforderte URL nicht in der Liste der „zulässigen" URLs enthalten ist, die dem Benutzer zugeordnet ist. Bei einer Ausführungsform ist jeder Benutzer einer oder mehreren Funktionen zugeordnet. Jede Funktion hat Zugang zu einer Gruppe von zulässigen URLs, die mit der betreffenden Funktion verknüpft sind.
Bei einer Ausführungsform hat jeder Benutzer eine oder mehrere Funktionen; die mit seiner Benutzerkennung oder User-ID verknüpft sind. So können sie zum Beispiel eine Marketing-Funktion, aber auch eine Engineering-Funktion haben. Bei einer solchen Ausführungsform ist jede Funktion direkt mit einem internen Server verknüpft, so dass für jeden Server nur eine Funktion definiert werden kann. Dies bedeutet, dass die Marketing-Funktion und die Engineering-Funktion hardwaremäßig nicht denselben internen Server benutzen können. Ein solcher Ansatz kann das Systemdesign vereinfachen.
Bei einer anderen Ausführungsform können jedem internen Server mehrere Funktionen zugeordnet sein. Ein Hersteller kann zum Beispiel alle seine Informationen für Wiederverkäufer auf einem Server haben. Eine Funktion umfasst jedoch die internationalen Händler, eine andere die inländischen Händler. Bei einer solchen Ausführungsform wäre es vorteilhaft, verschiedene Gruppen von URLs auf einem einzigen Dokumentenserver 14 definieren zu können, um die verschiedenen Funktionen zu berücksichtigen.
Um die Autorisierung abzuschließen, sucht der Dokumentenüberwachungsserver 12 die Liste der zulässigen URLs für jede Funktion des Benutzers ab, bis er eine Übereinstimmung findet. Wird keine Übereinstimmung gefunden, wird eine Fehlersituation an den Web-Server zurückgegeben, die besagt, dass der Zugriff verweigert wird, und der Web-Server gibt wiederum die entsprechende Fehlermeldung an den Browser.
Bei einer Ausführungsform übersetzt der Dokumentenüberwachungsserver 12 die URL, ehe er nach einer Übereinstimmung mit der URL sucht. Gibt ein externer Geschäftspartner (Benutzer) die URL ein, gibt er eine URL ein, deren erster Teil auf den Dokumentenüberwachungsserver 12 verweist und deren zweiter Teil die Funktion angibt, die mit dieser URL verknüpft ist, z.B.
https://www.<Server-ID>.com/Engineering/Standards/http_protocol.html
wobei
https = eine sichere HTTP-Verbindung mit SSL,
www.<Server-ID>.com = der DNS-Name des Dokumentenüberwachungsservers 12 (dieser Name ist eindeutig für die Installation bei dem betreffenden Kunden),
/Engineering = die Funktion, die dieser bestimmten URL zugeordnet ist, und
/Standards/http_protocol.html = die eigentliche Web-Seite auf dem internen Web-Server ist.
Wenn der eigentliche Intranet-Web-Server, der der Engineering-Funktion zugeordnet ist, z.B. „engineer.abcd.com" heißt, würde die übersetzte URL, nach der der Dokumentenüberwachungsserver 12 sucht, wie folgt lauten:
engineer.abcd.com/Standards/http_protocol.html
Intranet-Verbindung
Wenn sowohl die Authentifizierungs- als auch die Autorisierungsphase erfolgreich abgeschlossen werden, öffnet der Dokumentenüberwachungsserver 12 eine TCP-Verbindung zu dem entsprechenden Intranet-Server („engineer.abcd.com" im vorstehenden Beispiel). Nachdem die TCP-Verbindung hergestellt ist, generiert der Dokumentenüberwachungsserver 12 eine HTTP-Anfrage für die spezielle Web-Seite. Der Intranet-Server lokalisiert die angeforderte Web-Seite und übermittelt sie an den Dokumentenüberwachungsserver 12.
Analysieren der Seite
Die vom Intranet übermittelten Seiten fallen in die Kategorien Textseiten oder Nicht-Textseiten. Beispiele für Letztere sind Grafiken wie z.B. GIF- oder JPEG-Dokumente, Soundobjekte oder ausführbare Objekte wie z.B. Java-Applets. Nicht-Textseiten werden nicht analysiert. Sie werden unverändert an den Browser des Klienten weitergeleitet. Textdokumente, wie etwa Seiten im HTML-Format, enthalten jedoch eingebettete Links, die eventuell in ihre externen Entsprechungen übersetzt werden müssen. Eingebettete Links fallen in drei Kategorien, die zum Teil eine Übersetzung erfordern, zum Teil auch nicht: relative Links, Server-Links und absolute Links.
Relative Links in der Form subdir/page.html erfordern keine Übersetzung, weil der Browser den Pfad auf der Grundlage der Seite des Aufrufers voranstellt. Wenn sich die Seite des Aufrufers zum Beispiel an
http://www.document_control_server.com/Engineering/Standards/http_protocol.html befindet und der relative Link ssl_protocol.html lautet, würde der Browser dem Link http://www.document_control_server.com/Engineering/Standards/ voranstellen.
Server-Links haben die Form /Specification/wheel.html und müssen übersetzt werden. Diese Art von Link verweist auf eine Seite, die sich auf demselben Server wie die Seite des Aufrufers befindet, jedoch mit einem absoluten Pfad, der im Root-Verzeichnis des Servers beginnt. Mit derselben Seite des Aufrufers wie im vorherigen Abschnitt würde der übersetzte Link /Engineering/Specification/wheel, html lauten (wobei der Zugangs-String http:// nicht nötig ist, weil er vom Browser eingetragen wird). Die Übersetzung erfolgt durch Voranstellen des Alias, das der Seite des Aufrufers zugeordnet ist, Engineering in diesem Fall, vor den Pfad des eingebetteten Links.
Absolute Links sind vollständige URL-Adressen, zum Beispiel
http://engineer.abcd.com/Performance/testdrive.html
und müssen nur dann übersetzt werden, wenn sie auf einen Server verweisen, der in der Alias-Tabelle von Dokumentenüberwachungsserver 12 steht. Der Link aus dem Beispiel wird übersetzt, weil er auf den Server engineer.abcd.com verweist, der in der Alias-Tabelle von Dokumentenüberwachungsserver 12 als Engineering eingetragen ist. Die Übersetzung erfolgt durch Ersetzen des Namens des Intranet-Servers durch den Server-Namen des Dokumentenüberwachungsservers 12, gefolgt von dem Alias des Intranet-Servers. In diesem Beispiel würde die übersetzte URL
http://www.<server 12 ID>.com/Engineering/Performance/testdrive.html
lauten.
Links, die auf Seiten auf Servern verweisen, die dem Dokumentenüberwachungsserver 12 nicht bekannt sind, werden nicht übersetzt, weil sie auch auf gültige externe Sites wie z.B. Yahoo verweisen können, die unverändert bleiben sollten. Bei einer Ausführungsform werden diese Links daher nicht übersetzt. (Wenn die Seite des Aufrufers über das SSL-Protokoll (Secure Sockets Layer) empfangen worden ist, das heißt, die URL beginnt mit https://, ist zu beachten, dass die übersetzten Links ebenfalls mit https:// beginnen.)
Auf der anderen Seite könnten solche Links eine Sicherheitsbedrohung darstellen. Das heißt, der Link könnte auf einen Intranet-Server mit sensiblen Informationen verweisen, deren Existenz externen Benutzern nicht offen gelegt werden sollte. Um dem entgegenzuwirken, enthält der Dokumentenüberwachungsserver 12 bei einer Ausführungsform eine Liste mit Links, die der Außenwelt gegenüber verborgen werden sollen. Die Links in einer solchen Liste würden in etwas unschädliches übersetzt.
Umleitung
Wenn eine Seite umgezogen ist, kann ein Intranet-Server einen Umleitungsstatus an den Dokumentenüberwachungsserver 12 zurück übermitteln. Dies bedeutet, dass der Dokumentenüberwachungsserver 12 die umgeleitete Adresse übersetzen muss, ähnlich wie bei eingebetteten Links, ehe sie an den Browser des Klienten weitergeleitet werden.
Architektur
Ein Dokumentenüberwachungssystem wie zum Beispiel das System 10 in 1 ermöglicht es Benutzern, externen Organisationen auf sichere, einfache und kontrollierbare Weise direkten Zugang zu internen Web-Daten zu geben. Im Wesentlichen handelt es sich um ein sicheres Fenster, durch das externe Partner interne Web-Daten einsehen können. Wenn die externe Schnittstelle 16, wie in 4 gezeigt, eine Firewall 40 aufweist, ermöglicht das System 10 Geschäftspartnern über einen normalen Web-Browser auch einen authentifizierten, autorisierten und individuell angepassten Zugang zu wichtigen Intranet-Servern. Mit einem solchen System können Benutzer berechtigten Partnern einfach, aber verlässlich und kontrollierbar Zugang zu internen Web-Daten gewähren, und das mit vollständiger Kontrolle und Autorisierung. Externe Partner brauchen nur eine festgelegte URL aufzurufen, um Zugang zu einer internen Web-Seite zu erhalten.
Bei einer Ausführungsform, wie in 4 gezeigt, ist der Dokumentenüberwachungsserver 12 innerhalb der Firewall 40 installiert. Bei einer anderen Ausführungsform, wie in 5 gezeigt, ist der Dokumentenüberwachungsserver 12 in einem dritten Netzwerk installiert. In beiden Fällen authentifiziert der Dokumentenüberwachungsserver 12 den externen Benutzer und leitet die Anfrage dann an eine verdeckte, interne URL weiter. Der gesamte Prozess ist für den externen Benutzer transparent und kann von dem Benutzer des internen Dokumentenüberwachungsservers 12 ohne weiteres definiert werden. Dies erlaubt Geschäftspartnern direkten Zugang zu den Daten, wodurch die zeitliche Verzögerung, Redundanz, mangelnde Integrität und Engpässe in der MIS-Abteilung entfallen. (Hierbei ist Folgendes zu beachten: Wenn der Dokumentenüberwa chungsserver 12 innerhalb der Firewall installiert ist, wie in 4 gezeigt, muss die Firewall 40 so konfiguriert werden, dass HTTP-Anfragen von externen Quellen nur zum Server 12 gelangen. In gleicher Weise muss, wenn der Dokumentenüberwachungsserver 12 in einem dritten Netzwerk installiert ist (als eine Art entmilitarisierter Zone), wie in 5 gezeigt, die Firewall 40 so konfiguriert werden, dass HTTP-Anfragen auf das interne Netzwerk 20 beschränkt bleiben, so dass sie nur von Server 12 kommen können.)
Bei einer dritten Ausführungsform, wie in 6 gezeigt, ist der Dokumentenüberwachungsserver 12 außerhalb der Firewall 40 installiert, und der Zugang erfolgt über SSL (Secure Sockets Layer). Eine solche Ausführungsform muss so eingerichtet werden, dass die Firewall 40 HTTP-Verkehr nur von dem Dokumentenüberwachungsserver 12 in das interne Netzwerk 20 erlaubt.
Um etwaige Engpässe weiter zu verringern, umfasst der Dokumentenüberwachungsserver 12 bei einer Ausführungsform die Möglichkeit, dass die eigentlichen „Dateneigentümer" selbst festlegen, welche Partner Zugang zu ausgewählten internen Daten haben. Ein Dateneigentümer ist eine vertrauenswürdige Person innerhalb der Organisation, die berechtigt ist, Geschäftspartnern Zugriffsrechte auf Web-Seiten auf Dokumentenservern 16 einzuräumen. Bei einer solchen Ausführungsform ist ein Dateneigentümer einer oder mehreren „Funktionen" zugewiesen, wobei eine „Funktion" dem Mapping-Alias entsprecht, der einem der Server 16 zugeordnet ist. Ein Dateneigentümer kann nur für die Server-Funktion, der er zugeordnet ist, Geschäftspartner hinzufügen oder URLs zuordnen („mappen").
Ein Mitarbeiter, der in der Buchhaltung arbeitet, wird zum Beispiel einer Buchhaltungsfunktion (bzw. einem Buchhaltungs-Server) zugeordnet. Der Buchhaltungs-Dateneigentümer kann nur auf die vom Administrator festgelegten internen Server zugreifen. Dadurch wird verhindert, dass der Buchhaltungs-Dateneigentümer URLs auf anderen Servern wie etwa den Marketing- oder Engineering-Servern zuordnet.
Sobald ein Dateneigentümer einer Funktion zugeordnet worden ist, kann er oder sie die folgenden Aufgaben ausführen:

– Hinzufügen, Ändern oder Löschen eines Geschäftspartners aus der betreffenden Funktion.
– Einrichten einer User-ID (Benutzerkennung) und eines Passwortes für einen Geschäftspartner für die einfache Authentifizierung.
– Einstellen oder Zuordnen einer internen URL für den Zugang durch einen Geschäftspartner.
– Löschen von URLs aus einer eingestellten Zugangsliste.

Das Delegieren derartiger Aufgaben an die Dateneigentümer befreit die MIS-Abteilung von einigen Zuständigkeiten, wobei außerdem die Datenverwaltung an diejenigen übertragen wird, die die Informationen am besten kennen und verstehen. Bei einer solchen Ausführungsform definiert der Systemadministrator auch allgemeine Authentifizierungsregeln und die Liste der qualifizierten Dokumentenserver 16.
Geschäftspartner sind relativ vertrauenswürdige Endbenutzer. Ihnen kann der kontrollierte Zugang zu ausgewählten Web-Seitenstrukturen auf internen Web-Servern wie etwa Dokumentenservern 16 gewährt werden, sobald ihnen die folgenden Informationen vorliegen:

– Eine URL, über die sie eine Verbindung zum Dokumentenüberwachungsserver 12 herstellen können.
– Eine User-ID und ein Passwort, um sich gegenüber dem Dokumentenüberwachungsserver 12 zu authentifizieren.
– Der Name des „Menüpunktes", den sie wählen, wenn sie eine Verbindung zum Dokumentenüberwachungsserver 12 herstellen, der die internen Web-Seiten abruft, wie vom Dateneigentümer vorgegeben.

Die Dateneigentümer sind dafür zuständig, eine Liste von Geschäftspartnern anzulegen und zu pflegen, die Zugang zu den von ihnen kontrollierten Intranet-Servern benötigen, und den Geschäftspartnern die Informationen zu geben, die sie brauchen, um Zugang zu dem (den) ausgewählten Intranet-Server(n) zu erhalten.
Jeder von einem Dateneigentümer definierte Geschäftspartner gehört zu einer „Gruppe". Die „Gruppe", zu der ein Geschäftspartner gehört, steht in direktem Zusammenhang mit der Funktion, der ein Dateneigentümer zugeordnet ist, und mit den internen Servern, die mit dieser Funktion verknüpft sind. Diese Gruppen bestimmen, zu welchen URLs auf den internen Servern sie Zugang erhalten.
Ein Geschäftspartner kann mehreren Gruppen zugeordnet sein. So kann ein Geschäftspartner zum Beispiel zu den Gruppen Marketing und Vertrieb gehören. Die Dateneigentümer verwalten ihre Geschäftspartnerkonten mit Hilfe einer Geschäftspartnerliste. In der Geschäftspartnerliste kann ein Dateneigentümer einen neuen Geschäftspart ner anlegen und einen vorhandenen Geschäftspartner in jeder Gruppe, die er kontrolliert, ändern oder löschen.
Bei einer Ausführungsform wird eine Geschäftspartnerliste durch Klicken auf eine Schaltfläche „GP-Liste" in einem Dateneigentümer-Verwaltungsfenster aufgerufen.
Bei einer Ausführungsform weist der Dokumentenüberwachungsserver 12 einen Zugangslistenprozessor 22 und einen Dokumentenprozessor 24 auf (siehe 3). Der Zugangslistenprozessor 22 bestimmt, ob der Benutzer die Berechtigung für den Zugang zu dem ersten Dokument hat. Der Dokumentenprozessor 24 liest ein Dokument von dem Dokumentenserver 14, bereinigt das Dokument wie vorstehend beschrieben und leitet eine bereinigte Version des Dokuments an den Benutzer weiter. Der Zugangslistenprozessor 22 und der Dokumentenprozessor 24 werden nachstehend beschrieben.
a) Die Zugangsliste
Die Zugangsliste wird von dem Dokumentenüberwachungsserver 12 benutzt, um zu bestimmen, welche URLs ein authentifizierter Geschäftspartner anzeigen darf. Die Zugangsliste ist eindeutig für jede Funktion. Sie wird durch den Parameter „rolename.data" (Funktionsname.Daten) im Verzeichnis „roles/" (Funktionen) identifiziert. Bei einer Ausführungsform wird die Zugangsliste von der MIS-Abteilung verwaltet. Eine solche Ausführungsform nutzt jedoch nicht den Vorteil der Flexibilität, die durch die Architektur nach der vorliegenden Erfindung möglich ist. Stattdessen kann es vorteilhaft sein, den einzelnen Dateneigentümern zu gestatten, die URLs festzulegen, die in jeder Zugangsliste enthalten sein sollen. Eine solche Ausführungsform wird nachstehend beschrieben. In diesem Beispiel werden Dokumente von dem Dateneigentümer verfügbar gemacht, und ein als „Geschäftspartner (GP)" bezeichneter Benutzer kann darauf zugreifen.
Bei einer solchen Ausführungsform enthält die Zugangsliste Daten, die wie folgt formatiert sind:
Real_url; MENU=„menu name"
wobei „Real_url" die eigentliche URL (ohne den Zusatz http://) ist, die von dem Dokumentenüberwachungsserver 12 benutzt wird, um auf das betreffende Verzeichnis oder die Datei zuzugreifen. Der Parameter „MENU" ist immer vorhanden. Zwischen den Anführungszeichen kann ein Wert stehen, oder er kann leer sein. Ist zwischen den Anführungszeichen ein Wert angegeben, analysiert der Dokumentenüberwachungsserver 12 diesen Wert und richtet einen Link zu der betreffenden URL ein, wobei der Menüname der Titel des Links ist – wenn der Geschäftspartner nach dem Anmelden seine Menüseite aufruft.
In der Zugangsliste stehen nur erlaubte URLs. Andere URLs sind hier nicht angegeben.
Außerdem gestattet die Zugangsliste dem Geschäftspartner den Zugang zu allen Dateien in einem bestimmten Verzeichnis. Für den Moment erfolgt dies standardmäßig bei jeder URL, die der Benutzer erlaubt und die mit einem „/" endet, um dem Geschäftspartner den Zugang zu allen Daten in diesem Unterverzeichnis zu gestatten; dies wird in der Zugangsliste mit dem bekannten „*" nach dem nachgestellten Schrägstrich („Slash") eingegeben. Bei einer Ausführungsform bleibt die Verzeichnis-URL intakt, und der Dateneigentümer erhält die Möglichkeit, den Pfad, in dem das gesamte Verzeichnis nach Wunsch des Dateneigentümers enthalten sein soll, mit „cut and paste" auszuschneiden und einzufügen. Bei einer solchen Ausführungsform hängen Dateneigentümer das „*" an den Verzeichnisnamen an, wenn sie wollen, dass die Geschäftspartner in dieser Funktion Zugang zu allen Daten in dem betreffenden Verzeichnis erhalten sollen. Bei einer anderen Ausführungsform könnten explizite „Verbote" für die Handhabung von Dokumenten enthalten sein, die der Dateneigentümer nicht in die Liste der zugänglichen Dokumente aufnehmen möchte.
b) Der Mapping-Code auf dem Dokumentenüberwachungsserver 12
Der nächste Teil des gesamten Mapping-Designs betrifft den Bereich, wo eine Menge echter Arbeit ins Spiel kommt. In dem Dokumentenüberwachungsserver 12 gibt es gewissen Code, der aufgerufen wird, wenn der Benutzer (Dateneigentümer) einen bestimmten Server auf die Zugangsliste „mappen" bzw. ihr zuordnen will. Bei einer Ausführungsform wird eine grafische Benutzeroberfläche zum Auswählen von URLs und Geschäftspartnern benutzt. Bei einer solchen Ausführungsform wird dieser Code durch den Dateneigentümer aktiviert, indem er eine der folgenden Aufgaben ausführt:

• (A) Erstmaliges Aufrufen der Server-Zugangsliste.
• (B) Klicken auf einen Knoten im Zugangslisten-Zuordnungsbaum, der noch nicht erweitert worden ist und einige Unterknoten aufweisen kann.
• (C) Klicken auf die Schaltfläche „Remap" (Neu zuordnen).

An diesem Punkt kommuniziert die grafische Benutzeroberfläche über eine „Get URL"-Anforderung (URL holen) mit dem Server 12. Die „Get URL"-Anforderung:
(A) weist den Server an, die Zugangsliste für eine bestimmte Funktion zu laden,
(B) prüft, ob der Knoten nicht bereits erweitert worden ist, dass der Knoten auf diesem Server existiert (der Anfang der URL, der den Server-Namen angibt, ist identisch) und dass der Knoten vom HTML-Typ (oder Verzeichnistyp) ist; wenn der Knoten alle diese Kriterien erfüllt, weist die grafische Benutzeroberfläche den Server an, die betreffende URL für die betreffende Funktion zu erweitern, und
(C) wenn der Dateneigentümer auf die Schaltfläche „Remap" klickt, wird er aufgefordert, nachzusehen, ob er diesen Teil des Servers neu zuordnen möchte. Antwortet der Dateneigentümer mit „Yes" (Ja), wird eine Anforderung zum Neuzuordnen mit der aktuell ausgewählten URL und der Funktion an den Server geschickt.
Der Server 12 reagiert dann auf die Anorderung, die er von der grafischen Benutzeroberfläche erhält:
(A) Wenn die Anforderung lautete, die Zugangsliste zu laden, prüft der Server-Teil, ob eine Datei „role_map.data" im Verzeichnis der Funktionen vorhanden ist. Existiert diese Datei, wird sie Zeile für Zeile in unveränderter Form an die grafische Benutzeroberfläche gesendet. Existiert die Datei nicht, wird sie erzeugt und die Mapping-Funktion wird aufgerufen. Die Mapping-Funktion wird mit dem Dateizeiger, dem Namen der zuzuordnenden URL (dem Servernamen) und einem Tiefenanzeiger von 1 aufgerufen. (HINWEIS: Diese Ausführungsform umfasst eine Möglichkeit, mehrere Ebenen Tiefer zu gehen, aber aus Gründen der Zeitabschaltung kann es besser sein, jeweils nur eine Ebene nach unten zu gehen und den Benutzer die Zuordnung nach Bedarf festlegen zu lassen. Wird mehrere Ebenen nach unten gegangen, muss die Mapping-Funktion Fähigkeiten und Möglichkeiten aufweisen, um zu verhindern, dass dieselbe URL mehrfach zugeordnet wird (der rekursive Charakter von Links und Web-Spidern). Der Mapping-Code und sein Verhalten werden weiter unten beschrieben.)
Nachdem der Mapping-Code fertig ist, sind die URLs mit ihrer entsprechenden Zeilensyntax eingegeben und in der Mapping- oder Zuordnungsdatei gespeichert, die dann Zeile für Zeile an die grafische Benutzeroberfläche gesendet wird.
(B) Wenn die Anforderung lautete, einen Knoten zu erweitern, ruft der Server-Code daraufhin die Mapping-Funktion für die betreffende zu erweiternde URL auf. Er öffnet eine temporäre Datei, in die Informationen eingeschrieben werden können. Da nach ruft er den Mapping-Code mit einem Dateizeiger auf diese temporäre Datei, der zuzuordnenden URL und einer Tiefe von 1 auf. (HINWEIS: Derselbe Code wie im Fall A wird aufgerufen, jedoch mit anderen Parametern:) Sobald der Mapping-Code wieder erscheint, wird die Datei Zeile für Zeile an die grafische Benutzeroberfläche übermittelt; danach wird die Datei aus dem System gelöscht.
(C) Wenn die Anforderung lautete, einen bestimmten Server oder eine URL neu zuzuordnen, wird es etwas komplizierter. Wenn der Dateneigentümer sich dafür entschieden hat, dem gesamten Server neu zuzuordnen, ist die gesendete URL die Basis-URL – anderenfalls wird die URL gesendet, ab der der Dateneigentümer eine Neuzuordnung gewünscht hat. Unabhängig von der Situation wird derselbe Code benutzt – nur mit einem anderen URL-Wert. Dabei geschieht Folgendes:
Die aktuelle Zuordnungsdatei wird in die neue Zuordnungsdatei kopiert, bis die Zeile mit der neu zuzuordnenden URL eingelesen ist.
An diesem Punkt wird die betreffende Zeile analysiert, um die Tiefe in dem Verzeichnisbaum zu bestimmen (die Root-Ebene ist 0).
Eine Neuzuordnungsfunktion wird aufgerufen, die jetzt die folgenden Schritte ausführt (dies wird durch die Tatsache erschwert, dass in dem Baum in verschiedenen Tiefen Dateien hinzugefügt oder gelöscht worden sein können und wir die vorherige Form und die Werte des Baums beibehalten wollen, soweit möglich):
Anlegen einer temporären Datei zur Aufnahme der Zwischenergebnisse der Zuordnung.
Aufrufen der Mapping-Funktion mit einem Zeiger auf die temporäre Datei, der URL und einer Tiefe von 1.
Vergleichen der aktuellen Zuordnungsdatei Zeile für Zeile mit der temporären Datei.
Wenn die URL an der aktuellen Tiefe in der entsprechenden Tiefe der neuen temporären Datei nicht gefunden wird, werden diese URL und alle unmittelbar folgenden URLs mit einer größeren Tiefe als der aktuellen Tiefe entfernt (die anfängliche Datei fehlt).
Wird die URL an der aktuellen Tiefe in der temporären Datei gefunden, sind alle URL-Zeilen zwischen der gesuchten URL und der vorherigen URL neue Dateien und werden vor der aktuellen URL in die Zuordnungsdatei eingefügt. Ihre Syntaxzeilen geben die aktuelle Tiefe an und werden automatisch so eingestellt, dass die betreffende URL nicht erlaubt ist. Danach bleibt die vorhandene aktuelle URL-Zeile in der Zuordnungsdatei unverändert.
Jetzt muss die nächste URL in der Zuordnungsdatei untersucht werden, wobei die URL-Zeilensyntax untersucht wird. Die Tiefe ist der Aspekt, der primär Sorgen macht. Ist die Tiefe gleich der aktuellen Tiefe, kann diese Schleife fortgesetzt werden. Ist die Tiefe tiefer als die aktuelle Tiefe, ist diese URL ein Ableger der vorherigen URL, und die vorherige URL muss ebenfalls neu zugeordnet werden – die Neuzuordnungsfunktion wird dann rekursiv mit der vorherigen URL aufgerufen. Ist die Tiefe geringer als die aktuelle Tiefe, untersuchen wir keine weiteren URLs mehr, die neu zugeordnet werden müssten, und diese Funktion kehrt an den Anfang zurück.
Wenn die abschließende Neuzuordnungsfunktion wieder erscheint, werden die übrigen Werte nicht angerührt und unverändert in die neue Zuordnungsdatei kopiert.
Nachdem der Server mit der Neuzuordnung fertig ist, sendet er den gesamten neu zugeordneten Baum Zeile für Zeile zurück an die grafische Benutzeroberfläche. (HIN-WEIS: Danach legt der Server auch die Zugangsliste neu an, um die neuen Werte zu berücksichtigen. Angaben zum Erstellen der Zugangsliste aus den Zuordnungsdaten folgen weiter unten.)
Als Letztes liest die grafische Benutzeroberfläche die Datenzeilen ein, die sie vom Server erhält.
Für den Fall (A), einen anfangs geladenen Server, erzeugt die grafische Benutzeroberfläche einen Baum durch Prüfung jeder Eingabezeile. Dies ist in Abschnitt 3 dieser Zusammenfassung beschrieben.
Für den Fall (B), einen erweiterten Knoten, erzeugt die grafische Benutzeroberfläche direkt unter den erweiterten Knoten Unterknoten, indem die Tiefe entsprechend dem neuen Baum eingestellt und jede Eingabezeile analysiert wird. Das Analysieren der Eingabezeilen ist in Abschnitt 3 dieser Zusammenfassung beschrieben.
Für den Fall (C), einen neu zugeordneten Server, löscht die grafische Benutzeroberfläche den vorherigen Baum und erzeugt den neuen Baum (ähnlich wie bei A).
Der Code für das Mapping besteht aus einer Reihe von Codestücken, die die URL laden, die als Ergebnis erhaltenen HTML-Daten analysieren und eine Kette mit Daten über die Links erzeugen. Danach suchen sie jeden der Links mit der jeweils gewünschten Tiefe ab.

– Er benutzt bestimmte Standardbibliotheken zur Hilfe bei der Analyse und dem Holen der URL und der HTML-Daten.
– Wenn er auf einen Link trifft, speichert er diese Informationen im Speicher. Gleichzeitig versucht er auch festzustellen, um welche An von Datei es sich handelt. Im Moment unterscheiden wir nur zwischen folgenden Dateien: HTML, Musik, Grafik, extern und Video. Der Versuch, dies festzustellen, basiert auf entsprechenden Hinweisen aufgrund des Dateinamens und der umgebenden HTML-Daten.
– Handelt es sich um eine HTML-Datei und hat der Mapping-Code noch nicht die angeforderte Zuordnungstiefe erreicht, versucht der Mapping-Code daraufhin rekursiv, die HTML-Datei aufzurufen und ihren Inhalt zu analysieren, usw.
– Trifft er auf eine Datei und beendet er deren Analyse, erzeugt er eine Syntaxzeile, die die grafische Benutzeroberfläche erwartet, und schreibt diese Zeile in die Datei, die weitergegeben wird. Diese Zeile setzt sich wie folgt zusammen:
– URL (nur ein „Tag" oder Kennzeichen).
– http://real_file_url (dies ist die URL zu der Datei, die der Mapping-Code geladen und analysiert hat – dies ist die Datei, zu der der Dateneigentümer den Zugang erlaubt oder verweigert).
– Tiefe (eine ganze Zahl, die die aktuelle Tiefe angibt, an der sich diese Datei in dem Baum befindet – die Zeilen sind so aufgelistet, dass der Baum mit einer Art Tiefezuerst-Algorithmus geladen werden kann – er geht weiter nach links, wenn die Tiefe größer wird, fügt Kinder von links nach rechts hinzu, wenn die Tiefe gleich ist, und geht im Baum zurück nach oben, wenn die Tiefe geringer wird).
– Dateiname (dies ist der Name der Datei für die betreffende URL – ein „*" wird benutzt, wenn der Dateiname nicht bestimmt werden kann (wie im Falle eines Verzeichnisses oder des Servers)).
– Dateityp (dies ist ein Zeichen, das den zuvor erwähnten Dateitypen entspricht).
– Status des Knotens (dies ist ein Zeichen, das angibt, ob der betreffende Knoten reduziert oder erweitert war, als der Baum gespeichert wurde – dies wird nur von der grafischen Benutzeroberfläche benutzt, der Mapping-Code setzt dies automatisch immer auf C).
– Erlaubt (dies ist ein Zeichen, das angibt, ob diese URL erlaubt ist oder nicht, der Mapping-Code setzt dies automatisch auf „nicht erlaubt").
– Status der Herstellung der Verbindung (dies ist der HTTP-Statuscode für den Versuch, diesen Link aufzurufen – er könnte einen Wert 200 haben, was bedeutet, dass der Zugriff einwandfrei erfolgt ist, einen Wert 404, was bedeutet, dass diese URL nicht gefunden wurde, oder einen Wert 0, was besagt, dass der Link nicht aufgerufen wurde).
– Bereits zugeordnet (dies ist ein aus einem Zeichen bestehendes Flag, das angibt, ob diese URL bereits zugeordnet wurde und zuvor in dem Baum enthalten ist oder nicht; dies ist besonders nützlich bei einer Mapping-Suche über mehrere Tiefen).

Abschließend hat der Server noch eine weitere Aufgabe in Zusammenhang mit dem Mapping-Code. Der Server muss das Ausschreiben der gespeicherten Daten von der grafischen Benutzeroberfläche steuern, wenn der Dateneigentümer ein Speichern der Daten anfordert. Zu diesem Zeitpunkt werden die Daten, die von der grafischen Benutzeroberfläche in den Server eingestellt werden, Zeile für Zeile wieder in die Zuordnungsdatei geschrieben. Wenn dies geschehen ist, löscht der Server die vorherige Zugangsliste und analysiert die Zuordnungsdatei zeilenweise, um zu bestimmen, ob die betreffende Zeile erlaubt ist. Ist die Zeile erlaubt, wird der „real url"-Teil der Zuordnungszeile (ohne das http://) zu der Zugangsliste hinzugefügt. Als Nächstes prüft der Server die Zeile, um festzustellen, ob ein „Menüpunkt" angehängt ist; wenn ja, fügt der Server den entsprechenden Menüpunkt zu der Zugangsliste hinzu. Anderenfalls fügt er nur einen leeren Menüpunkt in die Zugangsliste ein. Wie bereits erwähnt, wird derzeit, wenn die „real url" mit einem „/" endet, am Ende der „real-url"-Zeile eine „*" angehängt, um anzuzeigen, dass der Benutzer auf das gesamte Verzeichnis zugreifen darf – siehe Abschnitt 1 für weitere Informationen.
Nachdem die Zugangsliste gespeichert worden ist, wird der Server mit den neuen Werten neu initialisiert und ermöglicht so die direkte Erteilung oder Ablehnung des Zugangs für die Geschäftspartner in der betreffenden Funktion.
Die Verzeichnis-Map für die grafische Benutzeroberfläche
Wie bereits erwähnt, liest die grafische Benutzeroberfläche bei einer Ausführungsform die gegebene Zeile ein und wertet diese aus, um Knoten anzulegen, um so den zugeordneten Server als eine Baumstruktur für die Dateneigentümer darzustellen. Eine solche Baumstruktur ist in 7 gezeigt.
Die grafische Benutzeroberfläche kommuniziert mit dem Server 12 wie vorstehend beschrieben und erhält genau definierte Datenzeilen zurück. Sie analysiert die Da ten und erzeugt einen Knoten für jede von der Zugangsliste gelieferte Zeile. Danach prüft sie das Attribut für erweitert oder reduziert, um festzustellen, ob der betreffende Knoten erweitert oder reduziert werden muss. Sie sieht sich auch den Dateityp an, um den betreffenden Knoten mit einem Symbol zu assoziieren. Dieses Symbol soll es dem Benutzer ermöglichen, besser festzustellen, auf welche Art von Knoten er Geschäftspartnern Zugang gibt. Das Symbol richtet sich auch nach dem Rückmeldestatus von dem Zuordnungsprozess – wird ein Status 404 angezeigt, gilt die betreffende Verbindung als unterbrochen (zumindest aus der Sicht des Dokumentenüberwachungsservers 12) und das Symbol für eine unterbrochene Verbindung erscheint daneben. Ist der betreffende Knoten derzeit erlaubt, wird schließlich ein grüner Punkt neben ihm angezeigt, um dem Dateneigentümer den Eindruck von „grünes Licht = in Ordnung" zu vermitteln.
Der Verzeichnisbaum wird in einer „Tiefe-zuerst-Form" angelegt. Jede Zeile wird eingelesen, wobei die aktuelle Tiefe geprüft wird. Ist die Tiefe des neu einzufügenden Knotens größer als die aktuelle Tiefe, wird der Knoten als Kind oder Ableger des zuvor eingefügten Knotens eingefügt. Ist die Tiefe gleich, wird er als Geschwisterknoten eingefügt. Ist die Tiefe geringer, wird der Baum so weit zurück analysiert, bis die Tiefe des Baums denselben Tiefenwert hat, und der Knoten wird als Geschwisterknoten auf dieser Ebene eingefügt. Der Server wird als auf Root-Ebene liegend angesehen und hat daher eine Tiefe von 0.
Der Textwert, der mit dem Knoten in dem Baum erscheint, ist der „real url"-Wert ohne das http:// und erweitert mit dem Menüpunkt und dem Wert, wenn ein solcher für den betreffenden Knoten existiert. Ein Knoten kann einen Menüpunkt haben, auch wenn er nicht erlaubt ist.
Der Dateneigentümer kann den Baum durchgehen und die verschiedenen Links prüfen und festlegen, welche er erlauben will und welche nicht. Wenn er ein Verzeichnis erlaubt, wird alles unterhalb dieses Verzeichnisses erlaubt. Derzeit gibt es noch keinen Mechanismus zur Berücksichtigung von Ausnahmen. Wenn Dateien erlaubt werden, ist die betreffende Datei erlaubt. Wenn andere Optionen für „Einbeziehen, wenn erlaubt" markiert sind (derzeit bieten wir das Einbeziehen aller GIF-, Audio-, Video- und HTML-Dateien und aller Links an), werden die Dateien unmittelbar darunter (wiederum nur eine Ebene tiefer) automatisch auf „erlaubt" gesetzt, wenn sie den entsprechenden Typ aufweisen. Hierbei ist zu beachten, dass externe Dateien nie „erlaubt" werden, weil sie sich nicht auf dem Server befinden und es daher keinen Sinn macht, dass der Dateneigentümer den Zugang zu diesen Dateien erlaubt oder nicht erlaubt.
Wenn ein Dateneigentümer einen Link auswählt, hat er die Möglichkeit, den Menüpunkt anzugeben, der angezeigt werden soll. Gibt er keinen Menüpunkt an, bleibt er leer. Wenn er einen Menüpunkt angibt, wird er nur für den betreffenden Knoten zugewiesen. Um ihn dem betreffenden Knoten zuzuordnen, muss der Dateneigentümer die Option „Allow" (Erlauben) oder „Disallow" (Nicht erlauben) wählen.
Wenn die Dateneigentümer mit ihren Änderungen fertig sind, können sie die Zuordnungswerte speichern oder verwerfen. Wenn sie das Verfahren abbrechen, werden die seit dem letzten Speichern oder Neuzuordnen vorgenommenen Änderungen nicht gespeichert. Wenn sie auf die Schaltfläche „Save" (Speichern) klicken, werden die Werte an den Server zurückübermittelt, und die Zuordnungsdatei und die Zugangslistendatei werden wie vorstehend beschrieben aktualisiert.
Installation
Vor dem Installieren: Vor dem vollständigen Installieren und Konfigurieren des Dokumentenüberwachungsservers 12 muss der Kunde ein digitales Zertifikat (für die SSL-Verschlüsselung oder -Übertragung) haben und einen Server wie z.B. den Internet Information Server (unter NT) oder den Netscape Enterprise Server (unter UNIX Solaris) einrichten und konfigurieren.
Installationen: Die MIS-Abteilung installiert den Dokumentenüberwachungsserver 12 auf dem Internet Information Server oder dem Netscape Enterprise Server und konfiguriert die Firewall, um den HTTP-Zugang zu dem Dokumentenüberwachungsserver 12 zu ermöglichen.
Definieren der Endbenutzer: Der Dokumentenüberwachungsserver 12 bietet Organisationen die Möglichkeit, die Verwaltung an Endbenutzer zu delegieren, die die eigentlichen Daten kontrollieren (Dateneigentümer), anstatt die MIS-Abteilung mit mehr Arbeit zu belasten. Der Zugang der Dateneigentümer wird durch den Netzwerkadministrator festgelegt. Der Dateneigentümer bestimmt dann, auf welche Server zugegriffen werden kann. Diese Daten werden in der „Zugangsliste" des Dokumentenüberwachungsservers 12 gespeichert. Der Programmcode zur Implementierung des Dokumentenüberwachungsservers 12 ist jetzt vollständig installiert und betriebsbereit.
Definieren des Zugangs für Geschäftspartner Damit ein externer Partner auf Daten zugreifen kann, muss ihm/ihr an diesem Punkt der Zugang durch den Dateneigentümer eingeräumt werden. Hierzu ruft der Dateneigentümer einfach über einen normalen javafähigen Internet-Browser die grafische „Dateneigentümer"-Benutzeroberfläche des Dokumentenüberwachungsservers 12 auf. Danach kann er den neuen Partner über eine funktionsbasierte Verwaltung festlegen oder explizit auswählen, auf welche URLs zugegriffen werden darf.
Externe Benutzer haben keinen Zugang zu internen URLs, die nicht ausdrücklich in der Liste aufgeführt sind, auch wenn es eingebettete Links in einer URL gibt, auf die der Zugang gewährt wurde. Die Benutzer können jedoch auch den Zugang zu einer bestimmten URL und allen Unterseiten definieren.
Zugang für künftige Partner: Nachdem eine Funktion definiert worden ist, brauchen künftige Partner nur zu der betreffenden Funktion hinzugefügt werden, anstatt einen komplett neuen Zugang definieren zu müssen.
Zugang für Geschäftspartner: Der externe Partner muss nur in einem normalen Internet-Browser die festgelegte URL eingeben. Daraufhin wird der Partner aufgefordert, eine User-ID und ein Passwort einzugeben. Sobald diese eingegeben sind, wird dem Partner eine Liste aller zugänglichen URLs angezeigt.
Back-End-Datenbanken
Es ist wichtig, zu verstehen, dass der Dokumentenüberwachungsserver 12 lediglich HTLM-Daten weitergibt. Dies bedeutet, dass der Dokumentenüberwachungsserver 12 kein Problem damit hat, CGI-Scripts und andere dynamische Inhalte weiterzugeben. Besonders verwirrend wird dies beim Zugriff und bei der Authentifizierung auf Back-End-Datenbanken über ein Applikations-Gateway.
Einer der größten Werte des Dokumentenüberwachungsservers 12 ist der, dass er externen Partnern den Zugang zu sich ständig ändernden Informationen wie etwa bei der Auftragsbearbeitung, dem Versand usw. gibt. Ein großer Teil dieser Daten ist in großen Back-End-Datenbanken mit einem Applikations-Gateway am Front-End gespeichert. Das Applikations-Gateway setzt ein HTML-Front-End auf die Datenbank auf und erlaubt Benutzern im Intranet die Abfrage benötigter Informationen. Meist braucht ein Benutzer nur eine Kundennummer einzugeben, um diese Informationen aufzurufen. Um jedoch externen Benutzern direkten Zugang zu gewähren, verlangen viele Organisationen eine gewisse Form der Authentifizierung für diesen Prozess.
Wenn der Dokumentenüberwachungsserver 12 eine Intranet-URL an einen externen Partner weitergibt, ist der Benutzer als eindeutiger Benutzer des Dokumentenüberwachungsservers 12 authentifiziert, wobei jedoch die betreffende User-ID nicht an den Intranet-Server weitergegeben wird. Daher kann der direkte Zugang zu Back-End-Datenbanken nicht für jeden Geschäftspartner auf dem Dokumentenüberwachungsserver 12 definiert werden. Eine auf HTML basierende Anmeldemaske muss erstellt werden. Dies ist ein einfaches Verfahren und bietet Wiederverkäufern und Dienstleistern eine Möglichkeit, den Produktverkauf mit einem Mehrwert zu verbinden.
Viele Internet-Web-Server handhaben Zugriffsbeschränkungen auf etwas unterschiedliche Weise. Wenn der Benutzer nicht bekannt ist, antwortet der Web-Server mit einem Fehler 401. Der Browser des Benutzers zeigt dann einen Standardbildschirm an, auf dem zur Eingabe von User-ID und Passwort aufgefordert wird. Der Benutzer gibt diese ein und erhält Zugang.
Hierbei ist zu beachten, dass der Dokumentenüberwachungsserver 12 diese Transaktion nicht verarbeiten kann. Aus Sicherheitsgründen kann nur HTTP-Verkehr über den Dokumentenüberwachungsserver 12 geleitet werden. Jede Authentifizierung muss auf HTTP-Basis erfolgen, wie vorstehend erwähnt.
Bei einer Ausführungsform ist der Dokumentenüberwachungsserver 12 auf einem normalen Web-Server mit dem Internet Information Server (NT) oder dem Netscape Enterprise Server (Solaris) installiert. Dies erfordert keine Änderungen an der derzeitigen Infrastruktur, und es müssen keine „Agenten" oder „Clients" für Web-Server oder Browser installiert werden.
Der Zugang für die Verwaltung und Nutzung durch Dateneigentümer erfolgt über die Java-Benutzeroberfläche des Dokumentenüberwachungsservers 12. Dies ermöglicht den Zugang über jeden Internet-Browser, der Java unterstützt (z.B. Internet Explorer 4.0 oder Netscape 4.0). Der Zugang für externe Partner erfolgt ebenfalls über einen normalen Internet-Browser.
Betrieb mit Firewalls Dritter
Der Dokumentenüberwachungsserver 12 kann in Verbindung mit einer Firewall benutzt werden, um die Kommunikation mit Geschäftspartnern über das Internet mit einer zusätzliche Sicherheitsstufe zu versehen. Zwei Elemente müssen bei der Bestimmung des Standortes für den Dokumentenüberwachungsserver 12 beachtet werden: der Domain Name Service (DNS) (das Domänen-Namensystem) und das Routing.
Je nach der bevorzugten Einsatzoption und den Möglichkeiten der Firewall 40. gibt es bis zu vier verschiedene Methoden zur Weiterleitung von Verkehr zu dem und durch den Server 12:

1) Umgeleiteter Proxy – Für mehr Sicherheit auf Verbindungen von extern zu intern kann in der Firewall ein umgeleiteter Proxy konfiguriert werden, um die ankommenden Verbindungsanfragen umzuleiten. Wenn ein Geschäftspartner im externen Netzwerk versucht, eine Verbindung zu dem Dokumentenüberwachungsserver 12 herzustellen, fängt die Firewall 40 die Anfrage ab und stellt eine Verbindung zu dem Server 12 her. Diese umgeleitete Verbindung verbirgt das eigentliche Ziel vor dem Geschäftspartner, der die Verbindung wünscht.
2) Transparenter Proxy – Ein transparenter Proxy kann über die Firewall 40 zu dem Dokumentenüberwachungsserver 12 eingerichtet werden. Aus der Sicht der Geschäftspartners erscheint dies so, als stelle er eine Verbindung direkt zu dem Server 12 her und nicht erst über die Firewall.
3) Direkt zum Dokumentenüberwachungsserver 12 – Wenn der Dokumentenüberwachungsserver 12 auf der externen Seite der Firewall 40 installiert ist (wie in 6), werden Verbindungsanfragen direkt an den Server 12 geleitet. Bei einer solchen Ausführungsform authentifiziert der Server 12 den Geschäftspartner und gibt die Anfrage durch die Firewall 40 weiter. Die Firewall 40 ruft dann die angeforderte(n) Web-Seite(n) von dem angegebenen Dokumentenserver 16 auf.
4) Über ein drittes Netzwerk – (Einige Firewalls erlauben eine Möglichkeit mit einem „dritten Netzwerk" (gelegentlich als entmilitarisierte Zone [DMZ] oder Secure Server Network bezeichnet). Die drei vorstehend beschriebenen Einsatzszenarios gelten auch in einer Umgebung mit drei Netzwerken; eine zusätzliche Firewall-Konfiguration ist jedoch nötig, um sicherstellen, dass die erforderliche Namenauflösung (DNS) und das Routing weiter möglich sind.

Sicherheitsmerkmale
SSL-Verschlüsselung. Bei einer Ausführungsform werden die zwischen dem Partner und dem Web-Server übertragenen Daten mit SSL verschlüsselt, um zu verhindern, dass Schnüffler Informationen aus der Verbindung gewinnen können.
Verschlüsselung des Dokumentenüberwachungsservers 12. Die auf dem Dokumentenüberwachungsserver 12 gespeicherten Daten wie die User-IDs, die Zugangsliste und die Partnerprofile sind alle verschlüsselt, um den Zugriff durch Unbefugte zu verhindern.
Authentifizierung mittels Passwort und User-ID Bei einer Ausführungsform unterstützt der Dokumentenüberwachungsserver 12 Passwörter und User-IDs zur Autorisierung. Eine stärkere Verschlüsselung könnte ebenfalls verwendet werden.
Granulare Zugriffssteuerung
Geschäftspartner können nur auf interne URLs zugreifen, zu denen ihnen explizit Zugang gewährt wird. Wenn eine zugängliche URL eingebettete Links auf Seiten aufweist, zu denen nicht explizit Zugang gewährt worden ist, kann der Partner keine Verbindung hierzu herstellen. Geht ein eingebetteter Link jedoch zu einem externen Server wie zum Beispiel www.yahoo.com, wird bei einer Ausführungsform der Zugang nicht beschränkt.
Interne URLs und IP-Adressen werden verborgen
Um die Sicherheit des internen Netzwerkes und der Web-Seiten zu gewährleisten, werden interne URLs und IP-Adressen vor einem Zugang von außen verborgen. Die Partner geben eine festgelegte URL ein, woraufhin ihnen eine Liste mit zugänglichen internen URLs angezeigt wird. Wird ein Link aus der Liste ausgewählt, ordnet der Dokumentenüberwachungsserver 12 die interne URL zu. Die interne URL und IP-Adresse werden dem Partner nie angezeigt.
Systemanforderungen, Kompatibilität und Leistung
Zu den Überlegungen im Hinblick auf Leistung und Zuverlässigkeit gehören die Größe des Cachespeichers, die Prozessorleistung, die Busgeschwindigkeit, die Größe des RAM-Speichers, die Geschwindigkeit der Speicherchips, die Busarchitektur (IDE, EIDE, PCI usw.), die Kapazität und die Qualität der Festplatte (Such- und Zugriffsge schwindigkeiten). In der nachstehenden Tabelle sind die grundlegenden Merkmale von minimalen, empfohlenen und idealen Serverkonfigurationen für den Betrieb des Dokumentenüberwachungsservers 12 angegeben.
Der Dokumentenüberwachungsserver 12 ermöglicht es dem Anwender, berechtigten Partnern auf einfache, aber verlässliche Weise Zugang zu internen Web-Daten zu gewähren, und das mit voller Kontrolle und Autorisierung. Externe Partner müssen nur eine festgelegte URL aufrufen, um Zugang zu einer internen Web-Seite zu erhalten.
Die nachstehenden Beispiele vermitteln eine bessere Vorstellung davon, wie der Dokumentenüberwachungsserver 12 für unterschiedliche Anforderungen eingesetzt werden kann.
Beispiel – Produktion (Auftragsverarbeitung)
Produktionsunternehmen verarbeiten jeden Tag Tausende von Aufträgen. Um mit dem Wettbewerb Schritt zu halten und ein Höchstmaß an Qualität zu bieten, müssen Kunden/Partner den aktuellen Status eines Auftrags auf die Minute kennen. Viele Unternehmen haben heute auf Just-in-Time-Lagerhaltungssysteme umgestellt, um Aufwand und Kosten zu senken. Der Dokumentenüberwachungsserver 12 kann den direkten Zugang zu einer Auftragsverarbeitungsseite gewähren, die direkt mit einer Auftragsverarbeitungs-Datenbank verbunden ist. Die Auftragssachbearbeiter (Dateneigentümer) können festlegen, auf welche Daten die Kunden/Partner direkten Zugang haben. Als Ergebnis erfährt der Kunde direkt den Status eines Auftrags. Der Lieferant spart außerdem Geld, weil die Daten nicht repliziert und keine Telefonate angenommen werden müssen, in denen nach dem aktuellen Status gefragt wird.
Beispiel – Vertrieb
Ein Vertriebsunternehmen betreibt eine Auftragsverarbeitungs- und Versandabteilung ähnlich wie das Produktionsunternehmen. Der Vertrieb muss jedoch auch noch verschiedene Arten von Informationen an verschiedene Partner weitergeben, etwa Preise und Mengenstaffeln. Mit dem Dokumentenüberwachungsserver 12 kann ein Unternehmen im Einzelnen festlegen, welche Ansicht der jeweilige Distributor oder Wiederverkäufer sieht. z.B. Preise oder Mengenstaffeln.
Beispiel – Finanzdienste
Geldinstitute verarbeiten täglich Millionen von Transaktionen mit einer großen Zahl von externen Partnern. Hierzu gehören unter anderem der Kauf und Verkauf von Wertpapieren sowie die Bestätigung von Aufträgen usw. Heute ist es für viele dieser Transaktionen nötig, dass ein Dritter ein sicheres Zertifikat einrichtet. Der Dokumentenüberwachungsserver 12 kann den gesamten Vorgang beschleunigen, indem er einem Sachbearbeiter die Möglichkeit gibt, einem externen Kunden oder Partner in wenigen Minuten direkt Zugang zu Handelsdaten zu erlauben, ohne dass Dritte eingeschaltet werden müssen.
Beispiele – Gesundheitsdienste
Krankenkassen und Versicherungsgesellschaften verarbeiten jeden Tag Tausende von Schadenanträgen. Die Partner brauchen eine sichere Methode zur Weitergabe von medizinischen Daten und deren Verarbeitung in den Systemen eines Unternehmens. Ein Arzt behandelt zum Beispiel einen Patienten, der eine Blue Cross/Blue Shield-Karte hat. Der Arzt muss wissen, ob die Versicherung des Patienten für die Behandlung aufkommt; nach der Behandlung muss er zunächst seine Forderung einreichen und dann später den Status der Bezahlung kontrollieren. Mit dem Dokumentenüberwachungsserver 12 kann Blue Cross/Blue Shield der Arztpraxis Zugang zu der internen Liste ihrer Versicherungsnehmer geben, aber auch zum Status der eingereichten Abrechnungen. Das Unternehmen muss diese Daten nicht mehr auf einem DMZ oder SSN Internet-Server replizieren oder Telefonate beantworten. Die Arztpraxis kann außerdem gefahrlos ein Online-Abrechnungsformular per Internet ausfüllen, um die Abrechnung für die Behandlung zu verarbeiten.
Beispiel – Behörden
Verschiedene Behörden und amtliche Stellen müssen häufig sensible Daten austauschen. Ein Beispiel ist etwa der CIA und die verschiedenen Vollstreckungsbehörden. FBI, DBA, ATF und andere Behörden müssen routinemäßig Einblick in den Akten verschiedener Personen und Bürger nehmen. Im Allgemeinen müssen diese Behörden hierzu eine schriftliche Informationsanfrage an den CIA schicken. Der CIA muss dann die entsprechenden Informationen heraussuchen und der anfordernden Stelle eine Kopie schicken.
Mit dem Dokumentenüberwachungsserver 12 können das FBI und andere Behörden direkten Zugang zu den CIA-Akten erhalten, die relevant sein könnten, etwa die Falldaten- und Fingerabdruckkarteien. Dies kann Zeit und Geld sparen.
Der Dokumentenüberwachungsserver 12 bietet mehrere Vorteile gegenüber derzeitigen Methoden, zum Beispiel Kosteneinsparungen, besserer Kundendienst und Nutzung der vorhandenen Infrastruktur. Die heutigen Verfahren zur Weitergabe von Daten an externe Partner sind teuer, langsam und unzuverlässig. Mit dem Dokumentenüberwachungsserver 12 stehen die Informationen den Partnern schneller, einfacher und preiswerter zur Verfügung. Außerdem werden die Partner enger eingebunden, was die Geschäftsbeziehungen verbessert. Der Dokumentenüberwachungsserver 12 nutzt auch die Vorteile aktueller Technologie wie Internet und Intranet.
Daneben bietet der Dokumentenüberwachungsserver 12 noch weitere Vorteile für Unternehmen: Er senkt den Aufwand und die Kosten, er macht es nicht mehr erforderlich, Inhalte auf einen Web-Server innerhalb der DMZ oder eines externen Netzwerkes zu kopieren, er bietet spontane, dynamische und vom Benutzer verwaltete Inhalte, er beseitigt das Warten darauf, dass ein IT-Manager Daten aktualisiert oder auf einem Web-Server einstellt, er beseitigt Probleme im Hinblick auf die Integrität und das Replizieren von Daten, er erlaubt eine stärkere Integration von Partnern und seine offene Architektur ermöglicht den Zugang ohne Änderung der derzeitigen Technik.
Auch wenn hier bestimmte Ausführungsformen gezeigt und beschrieben sind, ist für den Fachmann ersichtlich, dass jede Anordnung, die den Berechnungen zufolge denselben Zweck erfüllt, an die Stelle einer gezeigten bestimmten Ausführungsform treten kann.

Claims

Verfahren zum Betreiben eines Dokumentenüberwachungssystems umfassend einen Dokumentenüberwachungsserver (12) zum Überwachen des Zugangs zu Dokumenten auf Dokumentenservern (14) in einem internen Netzwerk (20), wobei der Dokumentenüberwachungsserver eine Liste von Klienten und eine Liste von Dokumenten enthält, in der für Klienten verfügbare Dokumente aufgeführt sind, wobei das Verfahren die folgenden, vom Dokumentenüberwachungsserver durchgeführten Schritte umfaßt: Empfangen einer Anfrage nach einem im internen Netzwerk gespeicherten Dokument; und Verknüpfen der Anfrage mit einem der Klienten; gekennzeichnet dadurch, daß die Dokumentenliste die für einen Klienten verfügbaren Dokumente definiert, so daß diese von einer Funktion, der der Klient zugeordnet ist, abhängen; jede Funktion eine damit verknüpfte Untermenge von Dokumenten hat, zu denen der Zugriff gewährt wird; und der Dokumentenüberwachungsserver in der Klientenliste nach dem Klienten schaut, um zu bestimmen, welcher Funktion der Klient zugeordnet ist; der Dokumentenüberwachungsserver in der Untermenge schaut, die mit der dem Klienten zugeordneten Funktion verknüpft ist, um zu bestimmen, ob das angefragte Dokument vorhanden ist; und der Dokumentenüberwachungsserver bei Vorhandensein des angefragten Dokuments dieses von einem Dokumentenserver abruft und es an den Klienten weiterleitet.
Verfahren nach Anspruch 1, wobei jedes Dokument eine eindeutige URL hat, und die Dokumentenliste die URL jedes verfügbaren Dokuments enthält, und wobei beim Bestimmen, ob das angefragte Dokument vorhanden ist, bestimmt wird, ob die URL des angefragten Dokuments in der Dokumentenliste enthalten ist.
Verfahren nach Anspruch 1 oder 2, das das Anzeigen der verfügbaren Dokumente in einer Baumstruktur innerhalb einer graphischen Bedienungsoberfläche enthält, wobei das Anzeigen das Kontaktieren eines Dokumentenüberwachungsservers beinhaltet, um eine aktuelle Version der Dokumentenliste zu erhalten.
Verfahren nach einem der Ansprüche 1 bis 3, wobei beim Verknüpfen der Anfrage mit einem Klienten dessen Berechtigung überprüft wird.
Verfahren nach einem der Ansprüche 1 bis 4, wobei der Dokumentenüberwachungsserver ein angefragtes Dokument säubert, bevor er es an den Klienten schickt.
Verfahren nach einem der Ansprüche 1 bis 5, wobei das System mehrere Dokumentenserver (14) enthält und Dokumente, die mit verschiedenen Funktionen verknüpft sind, in verschiedenen Dokumentenservern liegen.
Dokumentenüberwachungssystem (10) umfassend: ein internes Netzwerk (20); eine externe Schnittstelle (16); einen mit dem internen Netzwerk verbundenen Dokumentenserver (14), wobei der Dokumentenserver mehrere Dokumente enthält; und einen Dokumentenüberwachungsserver (12), der eine Klientenliste enthält und eine Anfrage für ein im Dokumentenserver gespeichertes Dokument empfangen, die Anfrage mit einem der Klienten verknüpfen und dessen Berechtigung überprüfen kann; gekennzeichnet dadurch, daß der Dokumentenüberwachungsserver (12) so ausgelegt ist, daß die Dokumentenliste die für einen Klienten verfügbaren Dokumente definiert, so daß sie von einer Funktion abhängen, der der Klient zugeordnet ist; der Dokumentenüberwachungsserver im Betriebszustand in der Klientenliste nach dem Klienten schaut, um zu bestimmen, welcher Funktion der Klient zugeordnet ist; der Dokumentenüberwachungsserver (12) einen Zugangslistenprozessor (22) enthält, der eine Untermenge von Dokumenten enthält, zu denen Zugang auf der Grundlage der Funktion des Klienten gewährt werden kann; und der Dokumentenüberwachungsserver (12) einen Dokumentenprozessor (24) enthält, so daß dieser, wenn der Zugangslistenprozessor entscheidet, daß der Klient Zugang zu einem Dokument haben kann, im Betriebszustand das Dokument vom Dokumentenserver entnimmt und an den Klienten weiterleitet.
Dokumentenüberwachungssystem nach Anspruch 7, wobei die externe Schnittstelle (16) eine mit einem externen Netzwerk verbindbare Firewall (40) enthält, wobei der Dokumentenüberwachungsserver (12) dazu ausgelegt ist, mit dem Dokumentenserver (14) durch die Firewall hindurch zu kommunizieren.
Dokumentenüberwachungssystem nach Anspruch 8, wobei der Dokumentenüberwachungsserver (12) mit einem externen Netzwerk verbunden werden kann und dazu ausgelegt ist, mit der Firewall (40) über das externe Netzwerk zu kommunizieren.
Dokumentenüberwachungssystem nach Anspruch 8, wobei der Dokumentenüberwachungsserver (12) mit einem weiteren Netzwerk verbunden werden kann und dazu ausgelegt ist, mit der Firewall (40) über das dritte Netzwerk zu kommunizieren.
Dokumentenüberwachungssystem nach Anspruch 7, wobei der Dokumentenüberwachungsserver (12) mit dem internen Netzwerk verbunden ist und die externe Schnittstelle (16) eine mit einem externen Netzwerk verbindbare Firewall (40) enthält, wobei die Firewall für den Empfang der Anfrage nach einem Dokument und das Weiterleiten der Anfrage an den Dokumentenüberwachungsserver (12) eingerichtet ist.
Dokumentenüberwachungssystem nach einem der Ansprüche 7 bis 11, wobei der Dokumentenüberwachungsserver im Betriebszustand ein entnommenes Dokument säubert, bevor er es an den Klienten weiterleitet.
Dokumentenüberwachungssystem nach Anspruch 7, wobei der Dokumentenüberwachungsserver im Betriebszustand als ein Proxy fungiert, um den Zugang zum Dokument zu verdecken.
Dokumentenüberwachungssystem nach einem der Ansprüche 7 bis 13, wobei die externe Schnittstelle (16) eine Telefonschnittstelle enthält, in die sich ein Klient einwählen kann, um Zugang zum Dokumentenüberwachungsserver (12) zu erlangen.
Dokumentenüberwachungssystem nach einem der Ansprüche 7 bis 14, wobei der Dokumentenüberwachungsserver (12) eine Einrichtung zum Übersetzen von Links enthält, die in ein angefragtes Dokument eingebettet sind.
Dokumentenüberwachungssystem nach einem der Ansprüche 7 bis 15, wobei der Dokumentenprozessor im Betriebszustand ein Dokument säubert, bevor er es weiterleitet.
Dokumentenüberwachungssystem nach einem der Ansprüche 7 bis 16, das mehrere Dokumentenserver (14) enthält und wobei mit verschiedenen Funktionen verknüpfte Dokumente in verschiedenen Dokumentenservern liegen.
Computerprogramm, das auf einen Prozessor implementierbare zum Steuern eines Dokumentenüberwachungsservers (12) enthält, die diesen alle Schritte eines Verfahrens nach einem der Ansprüche 1 bis 6 ausführen lassen.