DE60315914T2

DE60315914T2 - Ad hoc Sicherheitszugriff auf Dokumente und Dienste

Info

Publication number: DE60315914T2
Application number: DE60315914T
Authority: DE
Inventors: Mark Staffordshire St. Stringer; Elisabeth Church Langley Soutloglou; Diana K. Burlingame Smetters
Original assignee: Xerox Corp
Current assignee: Xerox Corp
Priority date: 2002-04-16
Filing date: 2003-04-11
Publication date: 2008-05-21
Anticipated expiration: 2023-04-12
Also published as: EP1357458A3; US6971017B2; DE60315914D1; JP4372446B2; EP1357458A2; EP1357458B1; JP2004007589A; US20030196087A1

Description

Die vorliegende Erfindung bezieht sich im Allgemeinen auf ein Verfahren und eine Vorrichtung zum Bereitstellen eines sicheren Zugriffs auf Dokumente und Dienste, die in einem Netzwerk gespeichert sind, das durch eine Firewall gegenüber außerhalb des Netzwerkes positionierten Benutzern geschützt ist, die keine registrierten Benutzer des Netzwerkes sind.
Gegenwärtig sollen zahlreiche hinter Firewalls privater Netzwerke gespeicherte Dokumente und Dienste von Benutzern gemeinsam benutzt werden, die keinen Zugriff auf das private Netzwerk haben (d.h. die keine registrierten Benutzer des privaten Netzwerks sind). Ein privates Netzwerk ist ein beliebiges Netzwerk, das den Zugriff auf sich an seinen Gateways (Netzübergängen) oder einzeln an jedem Gerät beschränkt.
Im Allgemeinen ist ein Netzwerk mit anderen Netzwerken durch Gateways verbunden. Es wird eine Firewall an einem Gateway installiert, um unberechtigten Zugriff durch den Gateway zu verhindern. Ein privates Netzwerk kann zum Beispiel die Form eines Firmennetzwerkes haben, das mit einem öffentlichen Netzwerk, wie zum Beispiel dem Internet, durch einen Gateway verbunden ist. Der Gateway des privaten Netzwerks kann über eine Firewall verfügen, die Nachrichten überprüft, die in dem privaten Netzwerk eingehen oder die es verlassen. Nachrichten können die Firewall nur dann passieren, wenn sie vordefinierte Sicherheitskriterien erfüllen (wenn sie z.B. von einer bestimmten Adresse stammen, an bestimmte Ports gerichtet sind etc.).
US-A-6.360.254 beschreibt ein System zum Bereitstellen eines Zugriffs auf eine private Ressource für mehr als einen Benutzer. In diesem System wird jeder Ressource ein privater einheitlicher Ortsangeber für Ressourcen (URL) zugewiesen, der eine feststehende Zeichenkette und einen eindeutigen Token umfasst, und die URLs werden durch E-Mail (bevorzugt unter Verwendung von Hyperlinks) an Benutzer übertragen, die zum Zugriff auf solche Ressourcen berechtigt sind. Die Token werden unter Verwendung eines Verfahrens erzeugt, das die Token im Wesentlichen willkürlich über den Bereich der zulässigen Tokenwerte („Tokenbereich") verteilt. Um die Sicherheit aufrechtzuerhalten, werden die Token durch E-Mail verteilt, und der Tokenbereich wird so gewählt, dass er im Verhältnis zu der erwarteten Anzahl gültiger Token ausreichend groß ist, um die Identifizierung von gültigen Token durch Versuch und Irrtum zu verhindern.
Das Vertrauen darauf, dass ein großer Tokenbereich und E-Mail-Kommunikation einen unberechtigten Zugriff auf Token verhindern, ist unzuverlässig.
EP-A-1.176.490 beschreibt eine alternative Konfiguration, bei der ein Berechtigung gewährendes Gerät auf eine Anforderung von einem Empfängergerät zum Erzeugen von verschlüsselten Daten über digitale Rechte antwortet, die unter Verwendung des öffentlichen Schlüssels (public key) des Empfängers verschlüsselt werden, die dann an das Empfängergerät gesendet werden. Das Empfängergerät entschlüsselt die verschlüsselten Daten über digitale Rechte und sendet dann eine Nachricht an ein Inhalteverteilungsgerät, um die entsprechenden Dokumente zu erhalten.
GB-2.342.195 beschreibt ein System, in dem E-Mails beigefügte Dokumente durch Token ersetzt werden. Der Empfänger-Mail-Client löst den Token gegen das durch die URL in dem Token identifizierte Dokument bei dem Dokumentenserver ein.
Dementsprechend wäre es wünschenswert, einem in einem privaten Netzwerk registrierten Benutzer die Möglichkeit zu geben, Benutzern, die nicht von vornherein in dem privaten Netzwerk registriert sind, sicheren, kontrollierten Zugriff auf Dokumente und Dienste zu gewähren, die hinter der Firewall des privaten Netzwerks gespeichert sind. Ein solcher Zugriff würde dem Benutzer, der nicht in dem privaten Netzwerk registriert ist, in vorteilhafter Weise den Zugriff auf dynamische Informationen und Dienste ermöglichen.
Es wird nach der Erfindung ein Verfahren, ein System und ein Herstellungsartikel dafür bereitgestellt, damit ein erster Benutzer einem zweiten Benutzer einen sicheren Zugriff auf elektronische Dokumente oder Dienste gewähren kann, die auf einem Dokumentenserver gespeichert sind, der in einem Netzwerk positioniert ist, wobei der erste Benutzer ein registrierter Benutzer des Dokumentenservers ist und der zweite Benutzer kein registrierter Benutzer des Dokumentenservers ist und wobei der erste Benutzer, der zweite Benutzer und der Dokumentenserver jeder einen öffentlichen Schlüssel damit verknüpft haben, der mit einem entsprechenden privaten Schlüssel verknüpft ist. Das auf dem Dokumentenserver ausgeführte Verfahren umfasst die folgenden Schritte: das Austauschen von öffentlichen Schlüsseln mit dem ersten Benutzer zum Aufbauen einer ersten sicheren Session; das Empfangen einer Anforderung von dem ersten Benutzer zum Auflisten eines Dateiverzeichnisses; das Authentifizieren des Zugriffs des ersten Benutzers auf das Dateiverzeichnis unter Verwendung der Legitimation, die durch den ersten Benutzer bereitgestellt wird, wenn die erste sichere Session aufgebaut wird; das Senden einer Auflistung des Dateiverzeichnisses über die erste sichere Session an den ersten Benutzer; das Auflisten zum Identifizieren eines Satzes von Pfaden zu auf dem Dokumentenserver verfügbarem Inhalt; das Austauschen von öffentlichen Schlüsseln mit dem zweiten Benutzer zum Aufbauen einer zweiten sicheren Session; das Empfangen einer Anforderung von dem zweiten Benutzer zum Zugriff auf ausgewählten Inhalt auf dem Dokumentenserver; die Anforderung zum Zugriff, die eine Token-Kennung enthält, die auf dem Dokumentenserver gespeichert ist und die mit einem Pfad aus dem Satz von Pfaden zu dem ausgewählten, auf dem Dokumentenserver verfügbaren Inhalt verknüpft ist; das Authentifizieren der Anforderung zum Zugriff unter Verwendung: (a) des von dem zweiten Benutzer während des Aufbauens der zweiten sicheren Session empfangenen öffentlichen Schlüssels des zweiten Benutzers, und (b) einer digitalen Signatur, die unter Verwendung des privaten Schlüssels des ersten Benutzers signiert wird, die eine signierte verschlüsselte Kurzfassung des öffentlichen Schlüssels des zweiten Benutzers und anderer Informationen ist, die sich auf die Anforderung des Zugriffs auf den ausgewählten Dokumenteninhalt auf dem Dokumentenserver beziehen (z.B. der Token-Kennung, des Pfades zu dem ausgewählten Inhalt, eines Erstellungsdatums, von Zugriffsrechten etc.); das Bereitstellen des Zugriffs auf den ausgewählten Inhalt für den zweiten Benutzer über die zweite sichere Session, wenn die Anforderung zum Zugriff authentifiziert wird.
In einer Ausführungsform ist jeder öffentliche Schlüssel als Teil eines digitalen Zertifikates enthalten, das jeder Teilnehmer (z.B. der erste Benutzer, der zweite Benutzer oder der Dokumentenserver) besitzt, der den privaten Schlüssel besitzt, der mit diesem Zertifikat verknüpft ist.
Diese und andere Aspekte der Erfindung werden aus der folgenden Beschreibung ersichtlich, die zusammen mit den beigefügten Zeichnungen gelesen wird, in denen die gleichen Bezugszeichen für die gleichen Teileverwendet werden und für die gilt:
1 erläutert eine Betriebsumgebung zum Ausführen der vorliegenden Erfindung;
2 stellt eine Ausführung dar, bei der URL-Token von dem Benutzer A, der ein bevollmächtigter Benutzer in dem in 1 gezeigten privaten Netzwerk ist, an den Benutzer B ausgegeben werden können, der kein bevollmächtigter Benutzer in dem privaten Netzwerk ist.
3 erläutert eine Art und Weise für den Benutzer A, eine digitale Signatur des URL-Tokens zu erzeugen;
4 zeigt eine Ausführungsform zum Einlösen eines ausgegebenen URL-Tokens; und
5 zeigt eine Ausführungsform, bei der die Anforderung zum Zugriff auf ein Dokument oder einen Dienst authentifiziert werden kann.
1 erläutert eine Betriebsumgebung 100 zum Ausführen der vorliegenden Erfindung. Die Betriebsumgebung umfasst einen Dokumentenserver 102, der direkt oder indirekt (drahtgebunden oder drahtlos) über öffentliche Netzwerke und/oder nicht vertrauenswürdige Netzwerke, wie zum Beispiel das Internet 104, mit der Benutzervorrichtung A 106 und der Benutzervorrichtung B 108 (hier auch jeweils als Benutzer A und Benutzer B bezeichnet) kommuniziert. Die Benutzervorrichtungen 106 und 108 können mobile oder ortsfeste Recheneinrichtungen sein, wie zum Beispiel Handgeräte, Laptops, Bürocomputer und Server.
Bei einer Ausführungsform kommuniziert der Dokumentenserver 102 indirekt mit den Benutzervorrichtungen 106 und/oder 108 durch einen Gateway 110 eines durch eine Firewall 112 geschützten privaten Netzwerks 114 (z.B. eines Intranets). Bei dieser oder anderen Ausführungsformen kann ein Proxy-Server 116 (oder Proxy 116) eingesetzt werden, um Übertragungen von und zu dem Dokumentenserver 102 zu filtern. In noch einer weiteren Ausführungsform kommuniziert der Dokumentenserver 102 direkt mit den Vorrichtungen 106 und/oder 108 über vertrauenswürdige oder nicht vertrauenswürdige Netzwerke.
Die Betriebsumgebung 100 umfasst darüber hinaus eine Public-Key-Infrastruktur (Infrastruktur zur Generierung öffentlicher Schlüssel – PKI). Bei der PKI wird üblicherweise eine Zertifizierungsstelle 118 oder ein vertrauenswürdiger Dritter eingesetzt, um digitale Zertifikate 120, 132 und 134 zu signieren, die jeweils an den Dokumentenserver 102, an den Benutzer A der Vorrichtung 106 bzw. an den Benutzer B der Vorrichtung 108 ausgegeben werden. Die Public-Key-Infrastruktur ermöglicht es zwei Teilnehmern, durch die Verwendung eines digitalen Zertifikates eine sichere Kommunikation miteinander aufzubauen, ohne je eine vorhergehende Beziehung gehabt zu haben.
Digitale Zertifikate können zum Beispiel in der durch den ITU-Standard X.509 für digitale Zertifikate beschriebenen Form vorliegen; alternativ können digitale Zertifikate in der durch die WTLS-Sicherheitsschicht (WTLS – Wireless Transport Layer Security – drahtlose Transportschichtsicherheit) des WAP (Wireless Application Protocol – Protokoll für drahtlose Anwendungen) beschriebenen Form oder in Form von SPKI-Zertifikaten (SPKI – Simple Public Key Infrastructure – einfache Public-Key-Infrastruktur) vorliegen.
Es können alternative Verschlüsselungsschemata neben der RSA-Public-Key-Verschlüsselungstechnologie (RSA – Rivest-Shamir-Adleman) eingesetzt werden, um die Erfindung auszuführen, wie zum Beispiel Elliptische-Kurven-Kryptografie oder der Digital Signature Algorithm (DSA – Algorithmus für digitale Signaturen), der einen Teil des U.S. Digital Signature Standard (DSS – Standard für digitale Signaturen) bildet.
Es können eine oder mehrere Zertifizierungsstellen in der Betriebsumgebung 100 eingesetzt werden. Das private Netzwerk 114 kann zum Beispiel über seine eigene Zertifizierungsstelle verfügen, die an bevollmächtigte Benutzer des Netzwerkes ausgegebene Zertifikate pflegt, oder einige oder alle Teilnehmer (z.B. der Benutzer A, der Benutzer B, der Dokumentenserver) können Zertifikate von einer anerkannten Zertifizierungsstelle für öffentliche Zertifikate (z.B. Verisign^®) erhalten. Schließlich wird für einen Kenner der Technik deutlich werden, dass der Dokumentenserver vertrauenswürdige Einheiten eher auf Basis ihrer Schlüssel als daran erkennt, wer ihre digitalen Zertifikate signiert hat, und dass alternativ beliebige Zertifikate, wie zum Beispiel selbst-signierte Zertifikate (d.h. bei denen der Teilnehmer, dem das Schlüsselpaar gehört, als seine eigene Zertifizierungsstelle fungiert) oder sogar isoliert nicht signierte öffentliche Schlüssel eingesetzt werden können.
Wenn zwei Teilnehmer (z.B. der Benutzer A und der Dokumentenserver) ihre öffentlichen Schlüssel austauschen und sie mit ihren jeweiligen privaten Schlüsseln verknüpfen, können sich beide Teilnehmer auf einen symmetrischen geheimen Schlüssel für eine bestimmte Komm unikations-Session (d.h. auf einen Session-Schlüssel) verständigen. Der Session-Schlüssel wird verwendet, um Informationen, die zwischen den Teilnehmern über einen ungesicherten (d.h. nicht vertrauenswürdigen) Kommunikationskanal gesendet werden, zu verschlüsseln und zu entschlüsseln. Diese Methode, einen Session-Schlüssel zu definieren, ermöglicht es einem Lauscher nicht, den Session-Schlüssel durch Überwachen des Kommunikationskanals abzuleiten, über den die Teilnehmer kommunizieren.
Ein Protokoll, um Daten auf diese Weise sicher über einen ungesicherten Kommunikationskanal zu senden, wird in dem Secure-Socket-Layer-Protokoll (SSL-Protokoll) definiert, wie in „The SSL Protocol Version 3.0", datiert vom 4. März 1996, veröffentlicht. Bei einer alternativen Ausführungsform kann darüber hinaus auch der Standard der Internet Engineering Task Force (IETF) mit dem Titel Transport Layer Security (TLS – Transportschichtsicherheit), der auf dem SSL basiert, zum Aufbauen einer sicheren Session über das Internet eingesetzt werden. Der Standard TLS wird in IETF RFC 2246 beschrieben. Das Protokoll SSL 3.0 und das TLS-Protokoll, die von Standard-Web-Browsern unterstützt werden, werden als Teil des HyperText Transfer Protocol (HTTP – Hypertext-Übertragungsprotokoll) unter Verwendung der Erweiterung „https" aufgerufen.
Nach einem Aspekt von Public-Key-Infrastrukturen werden der Dokumentenserver 102, die Benutzervorrichtung A 106 und die Benutzervorrichtung B 108 so eingerichtet, dass sie digitale Signaturen für ausgewählten Inhalt erzeugen. Eine digitale Signatur stellt eine signierte verschlüsselte Kurzfassung des ausgewählten Inhalts unter Verwendung eines vorgegebenen privaten Schlüssels dar. Jedermann, der über den öffentlichen Schlüssel verfügt, der dem vorgegebenen privaten Schlüssel entspricht, kann die Authentizität der signierten verschlüsselten Kurzfassung verifizieren. Nach einem weiteren Aspekt von Public-Key-Infrastrukturen werden der Dokumentenserver 102, die Benutzervorrichtung A 106 und die Benutzervorrichtung B 108 so eingerichtet, dass sie einen Session-Schlüssel für jede Kommunikations-Session (d.h. eine sichere Session) definieren, die zwischen ihnen aufgebaut wird.
Im Allgemeinen wird der Dokumentenserver so eingerichtet, dass er für Client-Vorrichtungen, die von Benutzern betrieben werden, die nicht bei dem Dokumentenserver registriert sind (wie zum Beispiel Benutzer B), sicheren Ad-hoc-Zugriff zu Dokumenten oder Diensten hinter einer Firewall bereitstellt. Die Client-Vorrichtungen können mobile Geräte, wie zum Beispiel PDAs (Personal Digital Assistants – persönliche digitale Assistenten), Smartphones und Laptops sein. Der Dokumentenserver kommuniziert nahtlos mit vorhandenen Browsern, die auf Client-Geräten laufen, und sie erfordern vorteilhafterweise nicht das Installieren irgendwelcher kundenspezifischer Software auf den Client-Geräten, keine Firewalls oder Proxy-Server, da jegliche besonderen Operationen von dem Browser nach Bedarf in Echtzeit auf die Client-Geräte heruntergeladen werden.
Der Dokumentenserver 102 umfasst verschiedene Elemente, die darauf oder auf einem oder mehreren Servern gespeichert sein können, auf die der Dokumentenserver 102 Kommunikationszugriff hat. Bei einer bestimmten Ausführungsform ist der Dokumentenserver 102 ein Web-Server, bei dem Verzeichnisse und Dateien physisch auf einem oder mehreren Computern positioniert sind, mit denen der Dokumentenserver kommuniziert und auf die er Zugriff hat. Bei dieser Ausführungsform können die Verzeichnisse von Benutzer A zum Beispiel auf einem oder mehreren Geräten bestehen, die als Verzeichnisse auf dem Dokumentenserver 102 abgebildet sind.
Die Elemente des Dokumentenservers 102 umfassen Serverskripte (z.B. active server pages (ASPs)) 122, eine Token-Datenbank 124, eine Dokumenten-Datenbank 126 und eine Datenbank 128 der bevollmächtigen Benutzer. Die Serverskripte 122 sind Skripte, die in Reaktion auf Https-Anforderungen von Clients, wie zum Beispiel von den Benutzervorrichtungen 106 oder 108, ausgeführt werden. Die Skripte können auf den Client- oder den Servergeräten ausgeführt werden, um die gewünschten Vorgänge durchzuführen. Die Dokumenten-Datenbank 126 speichert Dokumente oder Dokumentendienste (hier zusammen als Inhalt bezeichnet), auf den nur durch registrierte Benutzer des privaten Netzwerks 114 zugegriffen werden kann.
Die Token-Datenbank 124 zeichnet Informationen auf, die sich auf Token beziehen, die an registrierte Benutzer des privaten Netzwerks 114 ausgegeben worden sind. Wie unten ausführlich beschrieben, können diese Token in verschiedenen Formen vorliegen. Abhängig von der bestimmten Form können ausgegebene Token, die in der Token-Datenbank 124 aufgezeichnet sind, wie zum Beispiel Token 125, mit einer Token-ID (Kennung), einem Benutzernamen, einem Dokumenten- oder Dienstpfad, Zugriffsrechten und Prüfungsinformationen verknüpft werden. Der Dokumenten- oder Dienstpfad stellt die Position dar, an der ein bevollmächtigter Benutzer auf Dokumente oder Dienste in der Dokumenten-Datenbank 126 zugreifen kann. Die Prüfungsinformationen spezifizieren Informationen, wie zum Beispiel: wann der Token ausgegeben wurde, die Gültigkeitsdauer des Tokens und ob der Token gültig ist (z.B. ob er widerrufen wurde) und wie der Token verwendet wurde (z.B. ob darauf zugegriffen wurde, wie häufig darauf zugegriffen wurde etc.). Zugriffsrechte spezifizieren Informationen, wie zum Beispiel: wie der Token verwendet werden kann, die Version des Dokuments oder des Dienstes, auf das bzw. auf den Zugriff gewährt werden kann, und ob der Token delegierbar (d.h. übertragbar) ist.
Um einen Überblick zu geben, wird ein Beispielszenario mit Bezug auf 1 beschrieben. Der Benutzer A, der die Vorrichtung 106 bedient, möchte dem Benutzer B, der die Vorrichtung 108 bedient, Zugriff auf ein Dokument oder einen Dienst gewähren, der hinter der Firewall 112 des privaten Netzwerks 114 verfügbar ist, in dem der Benutzer A ein registrierter Benutzer ist (d.h. in dem er über ein Konto verfügt) und in dem der Benutzer B kein registrierter Benutzer ist. Folglich wird jeder versuchte Zugriff auf den Dokumentenserver 102 durch den Benutzer A durch den Gateway 110 authentifiziert und kann automatisch den Einstellungen von Benutzer A in dem privaten Netzwerk 114 (z.B. Benutzerkonto, Benutzerrechte, Benutzer-Standardverzeichnis etc.) zugeordnet werden.
Anfänglich baut der Benutzer A durch die Vorrichtung 106 eine erste sichere Session mit dem Dokumentenserver 102 durch die Firewall 112 des Gateways 110 und den Proxy 116 auf, um auf Dokumente zuzugreifen, die in der Dokumenten-Datenbank 126 gespeichert sind, auf die der Benutzer A Zugriff hat. Der Benutzer A erzeugt anschließend einen URL-Token (URL – Uniform Resource Locator – einheitlicher Ortsangeber für Ressourcen), der eine eindeutige Token-ID enthält. Im Allgemeinen besteht eine URL aus drei Feldern:

(a) einem Protokollfeld (z.B. https);
(b) einem Adressfeld eines Hostrechners (z.B. innerhalb des DNS (Domain Name System – Domain-Namensystem) und
(c) einem Pfadfeld (d.h. es identifiziert einen Pfad zu einem Dateinamen oder -dienst). Eine digital signierte verschlüsselte Kurzfassung (unten in 3 als URL-Token-Signatur 310 bezeichnet) zumindest des öffentlichen Schlüssels, an den der Token gerichtet ist, und anderer auf den Token bezogener Informationen (z.B. der Token-Kennung, des Pfades, von Zugriffsrechten, des Erstellungsdatums) (unten in 3 als Signaturinhalt 302 bezeichnet) wird an den Dokumentenserver 102 gesendet und in der Token-Datenbank 124 mit der eindeutigen Token-ID verknüpft.

Der URL-Token wird dann durch den Benutzer A an den Benutzer B gesendet, der dann den Zugriff auf das Dokument oder den Dienst (d.h. das Einlösen) anfordern darf, der durch den Token bezeichnet wird, selbst wenn der Dokumentenserver den Benutzer B, der die Zugriffsanforderung stellt, nicht bemerkt. Vorteilhafterweise ermöglicht der URL-Token ein spätes Binden, so dass der Inhalt des Dokumentes oder des Dienstes zu dem Zeitpunkt an Empfänger übertragen wird, zu dem sie den Inhalt wünschen (z.B. wenn ein URL-Link zu dem Inhalt ausgewählt wird), statt dass eine Kopie des Dokumentes oder unverzüglicher Zugriff auf den Dienst zu dem Zeitpunkt bereitgestellt werden muss, zu dem die Informationen bezüglich des Dokumentes oder des Dienstes durch einen Con tentprovider (Anbieter von Online-Inhalten; z.B. Benutzer A) an einen vorgegebenen Empfänger (z.B. Benutzer B) gesendet werden.
Der Zugriff durch den Benutzer A und den Benutzer B auf den Dokumentenserver 102 wird unter Verwendung des Https-Protokolls (oder eines weiteren Protokolls, das Authentifizierung von beiden Teilnehmern erfordert) ausgeführt. Als Teil des Https-Protokolls werden SSL-Verbindungen zwischen dem Benutzer und dem Server aufgebaut. Wie unten ausführlich beschrieben wird, haben Anforderungen zum Durchsuchen von Dokumenten oder Diensten auf dem Server sowie Anforderungen auf Zugriff zu den Dokumenten oder Diensten unter Verwendung des Tokens die Form einer URL, die unter Verwendung des Https-Protokolls angefordert wird.
Wenn eine Anforderung für ein Dokument oder einen Dienst durch den Benutzer B gestellt wird, authentifiziert der Dokumentenserver 102 den Benutzer B 108 als Teil des Aufbauens einer SSL-Verbindung, wodurch der öffentliche Schlüssel von Benutzer B dem Dokumentenserver bekannt gegeben wird. Der Dokumentenserver authentifiziert dann die Token-ID, die ein Teil des URL-Tokens ist, unter Verwendung des öffentlichen Schlüssels von Benutzer A (solange der Benutzer A noch ein bevollmächtigter Benutzer in dem privaten Netzwerk 114 ist – z.B. in der Datenbank 128 der bevollmächtigten Benutzer vorhanden ist).
2 stellt eine Ausführungsform dar, bei der URL-Token von dem Benutzer A, der ein bevollmächtigter Benutzer in dem privaten Netzwerk 114 ist, an den Benutzer B ausgegeben werden können, der kein bevollmächtigter Benutzer in dem privaten Netzwerk 114 ist. Der Benutzer A kann beginnen, indem er entweder mit dem Dokumentenserver 102 oder mit der Vorrichtung 108 von Benutzer B unter Verwendung von URLs kommuniziert, die einen herkömmlichen Browser, wie zum Beispiel Microsoft^® Internet Explorer oder Netscape^® Communicator, aufrufen. Eine in einer Benutzervorrichtung ausgewählte URL kann Skripte in Server-Skripten 122 auf dem Dokumentenserver 102 aufrufen, die bewirken, dass Operationen auf der Benutzervorrichtung oder auf dem Dokumentenserver ausgeführt werden.
Bei einer Ausführungsform beginnt die Kommunikation dadurch, dass der Benutzer A 106 in Schritt 202 eine sichere Session mit dem Dokumentenserver 102 aufbaut (zum Beispiel unter Verwendung von SSL), nachdem zum Beispiel eine URL, die eine Auflistung von Dateien oder Diensten auf dem Dokumentenserver anfordert, bei dem Benutzer A ausgewählt wird. Bei dieser Ausführungsform beginnt der Browser von Benutzer A durch Aufbauen einer sicheren Session zwischen dem Gateway 110, dem Proxy-Server 116 und schließlich dem Dokumentenserver 102 durch Tunneln durch die Firewall 112. Ein Verfahren zum Tunneln durch eine Firewall über eine SSL-Verbindung wird von Ari Luotonen, in „Tunneling SSL Through a WWW Proxy", IETF, Internet-Entwurf, 26. März 1997, im Internet veröffentlicht unter http://www.watersprings.org/pub/id/draft-luotonenssl-tunneling-03.tx, beschrieben. Das Öffnen der sicheren Session zwischen dem Benutzer A 106 und dem Dokumentenserver 102 führt zu dem jeweiligen Austausch von digitalen Zertifikaten 132 bzw. 120.
Sobald die sichere Session aufgebaut ist und der Benutzer A als ein registrierter Benutzer des Dokumentenservers authentifiziert ist, wird die Anforderung der Verzeichnisauflistung von Dateien oder Diensten durch den Dokumentenserver in Schritt 204 empfangen. Der Dokumentenserver, auf dem zum Beispiel der Internet Information Server (IIS) von Microsoft läuft, ordnet den registrierten Benutzer direkt dem Domain-Konto von Benutzer A in dem privaten Netzwerk 114 zu, um für den Benutzer A die gleichen Zugriffsrechte (d.h. Rechte und Beschränkungen) in der Domain bereitzustellen, wie wenn der Benutzer A innerhalb der Firewall 112 arbeiten würde. Beim Empfangen der gesendeten Verzeichnisauflistung (d.h. eines Satzes von Pfaden zu Dokumenten oder Diensten, auf die der Benutzer A Zugriff hat) in Schritt 206 ruft der Benutzer A ein Skript zum Erzeugen eines URL-Tokens für das ausgewählte Dokument oder den ausgewählten Dienst aus der Verzeichnisauflistung auf. Das aufgerufene Skript kann auf dem Skript-Server 122 gespeichert werden, oder es kann alternativ in dem Cache in der Benutzervorrichtung 106 aufgezeichnet werden.
Als Teil des Erzeugens des URL-Tokens wählt der Benutzer A in Schritt 208 einen Pfad eines Dokumentes oder eines Dienstes aus dem von dem Dokumentenserver empfangenen Satz von Pfaden aus. Der ausgewählte Pfad des Dokumentes oder Dienstes, den der Benutzer A für Benutzer B verfügbar machen möchte, wird in Schritt 210 an den Dokumentenserver gesendet. Bei Empfang des ausgewählten Pfades erzeugt der Dokumentenserver 120 in Schritt 212 einen neuen Eintrag in der Token-Datenbank mit einer eindeutigen Token-ID und dem Pfad des ausgewählten Dokumentes oder Dienstes bzw. der ausgewählten Dokumente oder Dienste. In Schritt 214 sendet der Dokumentenserver die eindeutige Token-ID, die mit dem Token in der Token-Datenbank verknüpft ist, die den ausgewählten Pfad aufzeichnet. Irgendwann, bevor der URL-Token in Schritt 218 signiert wird, muss der Benutzer A 106 in Schritt 216 digitale Zertifikatinformationen (z.B. das digitale Zertifikat 134) von dem Benutzer B empfangen. Die digitalen Zertifikatinformationen müssen zumindest den öffentlichen Schlüssel von Benutzer B enthalten.
Sobald der öffentliche Schlüssel von Benutzer B durch den Benutzer A empfangen worden ist, werden der öffentliche Schlüssel von Benutzer B und anderer ausgewählter Inhalt (wie zum Beispiel die Token-ID) durch den Benutzer A unter Verwendung des Digital Signature Standard (DSS – Standard für digitale Signaturen) signiert. 3 erläutert ein bekanntes Verfahren zum Implementieren des DSS. In 3 erzeugt eine Tokensignatur-Erzeugungseinrichtung 300 eine URL-Token-Signatur 310 (d.h. eine digital signierte verschlüsselte Kurzfassung) für den Signaturinhalt 302 unter Verwendung des geheimen Schlüssels 308 von Benutzer A. Die Tokensignatur-Erzeugungseinrichtung umfasst eine kryptografische Hash-Funktion 304 und ein Signierfeld 306. Ein Beispiel für eine kryptografische Hash-Funktion 304, die einweggerichtet (d.h. unumkehrbar) und kollisionsresistent ist, ist der überarbeitete Secure Hash Algorithm (SHA-1 – sicherer Hash-Algorithmus), der in dem Secure Hash Standard (SHS – sicherer Hash-Standard) spezifiziert ist, der eine Hash-Ausgabe 305 von 160 Bit (d.h. eine kryptografische Kurzfassung oder einen Message Digest (Nachrichten-Kurzfassung)) der eingegebenen Nachricht (z.B. des Signaturinhalts 302) erzeugt. Bei einer Ausführungsform führt das Signierfeld 306 die Funktionen des Digital Signature Algorithm (DSA) aus.
Bei einer Ausführungsform umfasst der Signaturinhalt 302 den öffentlichen Schlüssel 312 von Benutzer B und andere Informationen bezüglich des Tokens, wie zum Beispiel: eine Token-ID 314 (gesendet in Schritt 212 in 2), einen Dokumentenpfad (oder Dienstpfad) 316 (spezifiziert in Schritt 210 in 2) und Token-Rechte 318 (die in Schritt 210 zusammen mit dem Pfad spezifiziert werden können). Die Token-Rechte 318 können jederzeit vor dem Signieren des Inhalts durch den Benutzer A spezifiziert werden und können zum Beispiel ein Ablaufdatum, die Angabe, wie häufig das Dokument eingelöst werden darf, oder wie lange der Dienst genutzt werden darf, enthalten. Solche Token-Rechte können darüber hinaus angeben, ob der Token einer weiteren Person zugewiesen werden darf, und können Rechnungsdaten angeben, die mit den digitalen Eigentumsrechten des Dokumentes oder des Dienstes in Verbindung stehen. Bei einer weiteren Ausführungsform umfasst der Signaturinhalt nur den öffentlichen Schlüssel 312 von Benutzer B und die Token-ID 314.
Es wird wiederum auf 2 Bezug genommen, wo die URL-Token-Signatur, sobald sie mit dem privaten Schlüssel von Benutzer A signiert ist, in Schritt 220 an den Dokumen tenserver gesendet wird und in Schritt 222 in der Token-Datenbank 124 aufgezeichnet wird, wonach die sichere Session in Schritt 224 endet. Jederzeit, nachdem der Benutzer A die Token-ID empfängt, kann der Benutzer A den URL-Token in Schritt 226 an den Benutzer B senden, wonach der Benutzer B in Schritt 228 von seinem Empfang benachrichtigt wird. Der URL-Token kann an den Benutzer B entweder durch den Benutzer A oder durch den Dokumentenserver entweder direkt oder indirekt (z.B. durch IR-Verbindung, E-Mail, SMS-Übermittlung etc.) gesendet werden. Nach dem Empfang darf der Benutzer B den URL-Token bei dem Dokumentenserver 102 einlösen, sofern nicht der Benutzer A den festgelegten Zugriff entfernt hat oder der Benutzer A kein bevollmächtigter Benutzer des Dokumentenservers 102 mehr ist.
Bei einer Ausführungsform kann der Benutzer A für den Benutzer B einen URL-Token in der folgenden allgemeinen Form bereitstellen:
[Secure-Socket-Protokoll]://[Gateway-Adresse]/[Skript]/[Token-ID].
Ein typisches Beispiel für diese allgemeine Form ist:
https://xerox.com/scripts/ValidateToken.asp?/3243394924,
wobei es sich bei „ValidateToken.asp?" um ein Skript handelt, das von den Server-Skripten 122 auszuführen ist, und wobei die Zahl 3243394924 die eindeutige Token-ID ist.
Es ist zu erkennen, dass die zusätzlichen Informationen, wie zum Beispiel der Dokumenten- oder Dienstname als Teil des URL-Tokens enthalten sein können, selbst wenn es nicht erforderlich ist, dass der Dokumentenserver 102 den Dokumenten-Token eindeutig identifiziert. Darüber hinaus ist zu erkennen, dass das Skript in dem URL-Token nicht explizit als Teil der URL aufgeführt werden muss, sondern aus der Gateway-Adresse geschlossen werden kann, an die die URL gerichtet ist.
4 erläutert eine Ausführungsform zum Einlösen eines ausgegebenen URL-Tokens. Zunächst ruft der Benutzer B 108 das Einlösen eines URL-Tokens auf, indem er ihn in Schritt 402 auswählt, indem er ihn zum Beispiel entweder wie einen Hot-Link (eine aktive Verbindung) anklickt oder indem er ihn in die Adressleiste eines Browsers in der Vorrichtung 108 lädt. Dies veranlasst den Browser, in Schritt 404 zu beginnen, eine sichere Session mit dem Dokumentenserver 102 aufzubauen, was wiederum zu dem jeweiligen Austausch der Zertifikate 134 bzw. 120 führt.
Im Anschluss an das Aufbauen der sicheren Session oder als Teil des Aufbauens der sicheren Session sendet der Benutzer B in Schritt 406 den URL-Token an den Dokumentenserver. Eine Skript-Kennung und eine Token-Kennung bilden einen Teil des URL-Tokens. Die Skript-Kennung wird eingesetzt, um in Schritt 408 ein Skript (oder Programm) aus den Server-Skripten 122 aufzurufen, das die Befehle zum Identifizieren eines Tokens in der Token-Datenbank 124, der der eindeutigen Token-Kennung entspricht, die einen Teil des URL-Tokens bildet, ausführen wird, und das sicherstellen wird, dass der Token noch gültig ist (d.h. dass er nicht widerrufen worden ist).
Sobald der Token identifiziert ist, wird das Zertifikat des Benutzers, der den Token erzeugt hat, in Schritt 409 gegen die Datenbank der bevollmächtigten Benutzer 128 validiert. Der Benutzer, der den Token erzeugt hat, ist in der Token-Datenbank mit dem Token aufgezeichnet. Wenn der Erzeuger des Tokens kein vorhandener bevollmächtigter Benutzer ist, wird der Token gelöscht oder gesperrt, und der Benutzer B wird darüber informiert, dass der URL-Token nicht einlösbar ist. Anschließend authentifiziert dann das Skript in Schritt 410 unter Verwendung der Informationen des identifizierten Tokens den Token-Inhalt unter Verwendung des öffentlichen Schlüssels von Benutzer B, den er während des Aufbauens der sicheren Session (z.B. der SSL-Verbindung) in Schritt 404 erhalten hatte.
Falls

(a) der Signaturinhalt des Tokens authentifiziert werden kann,
(b) die Zugriffsrechte oder Prüfungsinformationen des Tokens anzeigen, dass der Benutzer B weiterhin Zugriff hat (z.B. der Zugriff nicht durch den Benutzer A widerrufen wurde, oder die Zugriffshäufigkeit oder -dauer nicht überschritten wurde, oder das Token-Ablaufdatum nicht verstrichen ist) und
(c) der Benutzer A weiterhin ein bevollmächtigter Benutzer bei dem Dokumentenserver ist,

412

414

126

416

418

420

5 zeigt eine Ausführungsform, bei der die Anforderung zum Zugriff auf ein Dokument oder einen Dienst in Schritt 410 in 4 authentifiziert wird. In 5 wird ein URL-Token-Authentifikator 502 dargestellt, der den Signaturinhalt 504 unter Verwendung der unumkehrbaren Hash-Funktion 304 (in 3 dargestellt) verarbeitet, um eine Hash-Ausgabe 505 (d.h. eine verschlüsselte Kurzfassung) zu erzeugen. Jedes Mal, wenn der Signaturinhalt 302 und der Signaturinhalt 504 zusammengestellt werden, wird der öffentliche Schlüssel von Benutzer B direkt von dem Benutzer B bezogen und wird nicht als Teil der Token-Datenbank 124 aufgezeichnet.
Die Hash-Ausgabe 505 und die in der Token-Datenbank aufgezeichnete URL-Token-Signatur werden dann durch ein Prüffeld 506 geleitet, um die Authentizität des Signaturinhalts 504 unter Verwendung des öffentlichen Schlüssels 508 von Benutzer A zu verifizieren, der mit dem privaten Schlüssel 308 von Benutzer A ein Schlüsselpaar bildet (in 3 dargestellt). Die Ausgabe des Authentifikators ist ein OK-Signal 510, falls der Signaturinhalt 504 mit dem Signaturinhalt 302 (in 3 abgebildet) identisch ist, der verwendet wurde, um die URL-Token-Signatur 310 zu erzeugen; anderenfalls ist die Ausgabe des Authentifikators ein Nicht-OK-Signal 512.
Die URL-Token stellen in vorteilhafter Weise ein Ad-hoc-Verfahren zum Aufbauen eines sicheren Zugriffs für den Benutzer B auf auf dem Dokumentenserver verfügbare Dokumente oder Dienste bereit, ohne dass der Dokumentenserver vorherige Kenntnis von dem Benutzer B hat. Darüber hinaus wird diese Beziehung nahtlos ohne Einbeziehung von Benutzer B verwaltet, indem keine vorherige Registrierung von Benutzer B als ein registrierter Benutzer an dem Dokumentenserver oder in dem privaten Netzwerk 114 erforderlich ist. Darüber hinaus stellen URL-Token für den Benutzer B zweckmäßigerweise einen fortdauernden Zugriff auf Dokumente oder Dienste bereit, die sich im Laufe der Zeit dynamisch ändern (z.B. einen Kalender oder einen Steuerverarbeitungsdienst), statt eines Schnappschusses eines ausgegebenen Dokumentes oder Dienstfreigaben zu einem bestimmten Zeitpunkt.
Kenner der Technik werden erkennen, dass die oben in Abschnitt D beschriebene Ausführungsform wie unten beschrieben auf vielfältige Arten modifiziert werden kann und dabei die gleichen Vorteile oder zusätzliche zu den oben beschriebenen Vorteilen erzielt.
Darüber hinaus sind die Abfolge oder der Aufbau der in den Abbildungen dargestellten Vorgänge nicht als beschränkend gedacht, sondern stellen eine von zahlreichen möglichen Abfolgen dar, in der die vorliegende Erfindung ausgeführt werden kann.
Mit Bezug auf die in 2 dargestellte Anordnung können der Dokumentenserver 102 und der Benutzer A 106 alternativ einen sicheren Kommunikationskanal öffnen und schließen, um die begrenzten Vorgänge 202, 204, 206 und 224 auszuführen, bevor sie jemals Zertifikatinformationen (z.B. das digitale Zertifikat 134) von dem Benutzer B in Schritt 216 empfangen und/oder bevor sie jemals die Signatur des URL-Tokens in Schritt 220 empfangen. Anschließend signiert der Benutzer A 106 den URL-Token und übermittelt ihn an den Benutzer B 108. Bei dieser Ausführungsform wird die eindeutige Token-ID in Schritt 206 durch den Dokumentenserver zusammen mit der Verzeichnisauflistung bereitgestellt oder durch den Benutzer A erzeugt (z.B. unter Verwendung eines zuvor durch den Dokumentenserver ausgegebenen Bereichs von Token-Kennungen).
Zu einem späteren Zeitpunkt kann eine weitere sichere Session zwischen dem Dokumentenserver 102 und dem Benutzer A 106 aufgebaut werden, wobei der Benutzer A zu diesem Zeitpunkt die Signatur des URL-Tokens und seine verknüpfte, eindeutige Token-Kennung an den Dokumentenserver sendet. Alternativ kann die Signatur des URL-Tokens als Teil des in Schritt 226 an den Benutzer B gesendeten URL-Tokens enthalten sein. Bei dieser alternativen Ausführungsform würde der URL-Token zusätzlich zu der Token-Kennung Informationen enthalten, die anderenfalls in Schritt 220 gesendet worden wären, damit sie mit der Token-Kennung in der Token-Datenbank 124 verknüpft werden, wie zum Beispiel die URL-Signatur, den Dokumentenpfad oder die ausgegebenen Dokumentenrechte. Diese Informationen können sämtlich durch den Dokumentenserver beim Empfang von dem Benutzer B durch Hinzufügen der Informationen zu dem Signaturinhalt 302 und 504 (jeweils in den 3 und 5 dargestellt) verifiziert werden.
In einer alternativen Ausführungsform kann der Benutzer A zum Beispiel einen URL-Token für Benutzer B zur Verfügung stellen, der die folgende allgemeine Form aufweist:
[Secure-Socket-Protokoll]://[Gateway-Adresse]/[Skript]/[Signatur]/[Rechte]/[Dokumentenpfad]/[Token-ID].
Das Rechtefeld kann zum Beispiel die folgenden Informationen enthalten:

(a) das Ablaufdatum des Tokens;
(b) die Angabe, wie häufig der Token eingelöst werden kann;
(c) ob der Dokumenten-Token an einen weiteren Benutzer weitergegeben (d.h. übertragen) werden kann;
(d) Gebühren- und Preisgestaltungsinformationen (z.B. unter Verwendung der digitalen Rechtesprache XrML 2.0 von ContentGuard^® spezifiziert);
(e) Versionen, auf die zugegriffen werden kann;
(f) Nutzungsfrist;
(g) das Ausgabedatum.

Bei dieser Ausführungsform übergibt der Benutzer B die URL-Token-Signatur zu dem Zeitpunkt, zu dem der Token eingelöst wird, da die Tokensignatur nicht in der Token-Datenbank auf dem Dokumentenserver gespeichert wird. Der Vorteil, dass der Benutzer A die URL-Token-Signatur für den Benutzer B als Teil des URL-Tokens bereitstellt, besteht in Folgendem:

(a) der Benutzer B wird befähigt, die URL-Token-Signatur dem Dokumentenserver zu übergeben, wodurch dem Dokumentenserver nicht ermöglicht wird zu behaupten, dass der Benutzer A den Token nicht wirklich ausgegeben habe;
(b) der Benutzer B wird befähigt, ein Übertragungszertifikat zu erstellen, um den Token an einen weiteren Benutzer zu übertragen (angenommen, solche Rechte wurden durch den Benutzer A bewilligt), und
(c) der Benutzer B wird durch Unleugbarkeit von dem Benutzer A geschützt (d.h. der Benutzer A kann nicht behaupten, dass jemand anderes einen Token im Namen von Benutzer A ausgegeben hat).

Wie oben in Abschnitt D beschrieben, wird die URL-Token-Signatur alternativ in der Token-Datenbank gespeichert, und es ist folglich nicht erforderlich (aber möglich), dass sie als Teil der URL enthalten ist. Bei noch einer weiteren Ausführungsform signiert der Benutzer A nur den öffentlichen Schlüssel von Benutzer B (d.h. der Signaturinhalt 302 besteht zumindest aus dem öffentlichen Schlüssel von Benutzer B). Bei dieser alternativen Ausführungsform speichert die Token-Datenbank die Informationen (z.B. Zugriffsrechte, bevollmächtigte Benutzer, Dokumentenpfad, Prüfungsinformationen etc.) des Dokumenten-Tokens und die verschlüsselte Kurzfassung des öffentlichen Schlüssels von Benutzer B. Diese Ausführungsform nimmt an, dass alles, was in der Token-Datenbank gespeichert ist, sicher ist, und spiegelt die tatsächlichen Absichten von Benutzer A wider, wie sie durch den Benutzer A während einer sicheren Session mit dem Dokumentenserver übermittelt worden sind.
Unabhängig von der Ausführungsform muss der Dokumentenserver Zugriff auf alle Informationen haben, die der Benutzer A bei dem Erstellen des Tokens verwendet hat (z.B. die Zugriffsrechte), oder er muss in der Lage sein, diese Informationen wiederherzustellen, bevor er dem Benutzer B Zugriff auf das Dokument oder den Dienst gewährt, diese Informationen müssen irgendwann durch den Benutzer A an den Dokumentenserver gesendet werden (z.B. wenn der Token registriert wird), oder sie müssen durch den Benutzer B übergeben werden, wenn der Token in Anspruch genommen wird (d.h. gebraucht oder eingelöst) wird. Der Grund, warum der Dokumentenserver in der Lage sein muss, sämtliche durch den Benutzer A bei der Erstellung des Tokens verwendeten Informationen wiederherzustellen, ist, dass er in der Lage sein muss, eine Bit für Bit identische Kopie der Informationen zu erstellen, die verwendet werden, um die verschlüsselte Kurzfassung 505 (in 5 dargestellt) zu erzeugen, um die URL-Token-Signatur 310 von Benutzer A zu verifizieren, wodurch der öffentliche Schlüssel von Benutzer B und andere zusätzliche Informationen, die als Teil des Signaturinhalts 504 enthalten sind und die für das Erzeugen der verschlüsselten Kurzfassung verwendet wurden (z.B. die Token-Kennung, ein Erstellungsdatum, Zugriffsrechte etc.), authentifiziert werden.
Darüber hinaus kann der Benutzer A für den Benutzer B zusammen mit dem URL-Token (in Schritt 226, wie in 2 dargestellt) und für den Dokumentenserver zusammen mit der Signatur des URL-Tokens (in Schritt 220, wie in 2 dargestellt) eine signierte oder unsignierte verschlüsselte Kurzfassung des Inhalts oder eines Teils des Inhalts des ausgewählten Dokumentes oder Dienstes (d.h. eine Inhaltskurzfassung) bereitstellen. Es bestehen zwei Vorteile in dem Angeben einer Inhaltskurzfassung: Erstens ermöglicht das Bereitstellen der Inhaltskurzfassung für den Benutzer B dem Benutzer B zu verifizieren, dass das Dokument oder der Dienst, das bzw. den er von dem Dokumentenserver (in Schritt 418, wie in 4 dargestellt) empfängt, das ist, was der Benutzer A für den Benutzer B zum Empfang vorgesehen hatte, als der Benutzer A den URL-Token an den Benutzer B ausgab.
Zweitens ermöglicht das Bereitstellen der Inhaltskurzfassung für den Dokumentenserver dem Benutzer A, gegenüber dem Dokumentenserver zu bestimmen, dass der Zugriff von Benutzer B auf das Dokument oder den Dienst auf bestimmte Zustände des Dokumentes oder Dienstes (z.B. Vorabversion gegenüber veröffentlichter Version) beschränkt ist oder dass der Zugriff auf das Dokument oder den Dienst bestimmte Elemente (z.B. frühes, spätes oder ausgewähltes Binden des Dokumentes oder Dienstes, auf das bzw. den in dem URL-Token verwiesen wird, an den Inhalt des Dokumentes auf dem Dokumentenserver) einschließt oder ausschließt.
Bei einer Ausführungsform kann die Inhaltskurzfassung in Informationen über Zugriffsrechte enthalten sein, die in dem Signaturinhalt 302 spezifiziert sind (in 3 dargestellt). Die Informationen über Zugriffsrechte können zum Beispiel Folgendes enthalten: eine Kurzfassung des aktuellen Inhalts einer Datei, die das ausgewählte Dokument oder den ausgewählten Dienst darstellt, oder eine Versionsnummer, die einen bestimmten Zustand der Datei zu einem bestimmten Zeitpunkt angibt, wie sie durch ein Versionsverwaltungssystem geführt wird, das auf dem Dokumentenserver arbeitet. Die Versionsnummer kann zum Beispiel die aktuelle Version, eine vergangene Version oder eine künftige Version des ausgewählten Dokumentes oder Dienstes darstellen.
Bei noch einer weiteren Ausführungsform kann der Dokumentenserver dazu verwendet werden, sicheren Zugriff auf Dokumente und Dienste unter Verwendung der URL-Token durch E-Mail an Empfänger zu verteilen, deren öffentliche Schlüssel bekannt sind.
Bei noch einer weiteren Ausführungsform werden für den Benutzer A Mechanismen für die Prüfung und den Widerruf (oder die Änderung) eines Zugriffs auf ausgegebene URL-Token bereitgestellt. Das heißt, der Benutzer A kann unter Verwendung eines Browsers jederzeit auf die Token-Datenbank 124 unter Verwendung von Skripten in den Server-Skripten 122 zugreifen. Das Durchsuchen der Token-Datenbank ermöglicht es dem Benutzer A zu identifizieren, welche Token eingelöst worden sind, wie auch andere Prüfungsinformationen zu identifizieren, wie zum Beispiel, wie häufig ein Token eingelöst wird, wann er zuletzt eingelöst worden ist, wie lange ein Token eingelöst ist (z.B. für einen Dienst). Das Durchsuchen der Token-Datenbank ermöglicht es dem Benutzer A darüber hinaus, ausgegebene URL-Token zu widerrufen oder Ablaufinformationen von ausgegebenen URL-Token zu aktualisieren.
Bei einer Ausführungsform bauen der Benutzer A und der Benutzer B eine sichere Verbindung mit dem Dokumentenserver durch Ausführen der folgenden Vorgänge auf: (1) Der Gateway 110 öffnet einen Socket (eine Softwareschnittstelle) auf einem ausgewählten Port, um auf eine Verbindung von dem Proxy 116 zu warten; (2) der Gateway 110 öffnet einen Socket auf einem anderen oder dem gleichen Port, um auf Verbindungen von einer Benutzervorrichtung zu warten; (3) der Proxy 116 verbindet sich mit dem Gateway 110 auf einem ausgewählten Port über den Firewall-Proxy 112; (4) der Gateway 110 verifiziert, dass die Internetadresse des Proxys gültig ist; (5) die Benutzervorrichtung verbindet sich mit dem Gateway 110 durch Aufbauen einer SSL-Verbindung mit dem Dokumentenserver 102; (6) der Gateway 110 richtet von der Benutzervorrichtung empfangene Daten an den Proxy 116, und der Proxy 116 richtet die Daten an den Dokumentenserver 102; (7) der Proxy 116 richtet von dem Dokumentenserver 102 empfangene Daten an den Gateway 110, und der Gateway 110 richtet die Daten zurück an die Benutzervorrichtung; (8) die Vorgänge (6) und (7) werden wiederholt, während die Benutzervorrichtung mit dem Dokumentenserver kommuniziert.
Zusammenzufassend gesagt, ermöglicht die vorliegende Erfindung einen sicheren Adhoc-Zugriff auf bestimmte, hinter einer Firewall gespeicherte Dokumente oder Dienste, ohne die Sicherheit zu gefährden. Dies ermöglicht es bevollmächtigten Benutzern eines sicheren Netzwerkes (z.B. einer Domain), speziell gekennzeichnete Dokumente und/oder Dienste (d.h. von Transaktion zu Transaktion oder je Ausgabe), die nur für die bevollmächtigten Benutzer hinter der Firewall des sicheren Netzwerkes verfügbar sind, mit dritten Teilnehmern, die keine bevollmächtigten Benutzer des sicheren Netzwerkes sind, gemeinsam zu nutzen. Der Zugriff auf die Dokumente oder Dienste wird aktiv durch den Dokumentenserver und die bevollmächtigten Benutzer verwaltet, indem Zugriff auf die Dokumente oder Dienste des sicheren Netzwerkes über die Token-Datenbank gewährt wird, wann immer es erforderlich ist, wodurch ein Verfahren zum Überprüfen der Überwachung bereitgestellt wird, und ein solcher Zugriff widerrufen wird (z.B. auf Anforderung, nach einer Zeitspanne, nach einer vordefinierten Zahl von Zugriffen, oder abhängig von anderen vordefinierten Bedingungen).
Zusätzliche Informationen bezüglich token-fähiger mobiler Rechenvorrichtungen werden des Weiteren in den US-Patenten Nr. 5.862.321 und 6.144.997 gegeben.
Jegliches resultierende Programm bzw. jegliche resultierenden Programme, die über einen maschinenlesbaren Programmcode verfügen, können in einem oder mehreren computernutzbaren Medien, wie zum Beispiel Speichereinrichtungen oder Sendeeinrichtungen, enthalten sein und so ein Computerprogrammerzeugnis oder einen Herstellungsartikel nach der Erfindung ergeben. Die Begriffe „Herstellungsartikel" und „Computerprogrammerzeugnis" sind als solche so, wie sie hier verwendet werden, so gemeint, dass sie ein Computerprogramm, das (dauerhaft, zeitweilig oder vorübergehend) auf einem beliebigen computernutzbaren Medium, wie zum Beispiel auf einer beliebigen Speichereinrichtung oder einer beliebigen Sendeeinrichtung, vorhanden ist, umfassen.

Claims

Verfahren für einen ersten Benutzer (A), einem zweiten Benutzer (B) einen sicheren Zugriff auf elektronische Dokumente oder Dienste zu gewähren, die auf einem Dokumentenserver (102) gespeichert sind, der in einem Netzwerk (114) positioniert ist, wobei der erste Benutzer ein registrierter Benutzer des Dokumentenservers ist und der zweite Benutzer kein registrierter Benutzer des Dokumentenservers ist und wobei sowohl der erste Benutzer (A) als auch der zweite Benutzer (B) und der Dokumentenserver (102) jeder mit einem öffentlichen Schlüssel verknüpft ist, der mit einem entsprechenden privaten Schlüssel verknüpft ist, wobei das auf dem Dokumentenserver (102) ausgeführte Verfahren die folgenden Schritte umfasst: Austauschen (132) von öffentlichen Schlüsseln mit dem ersten Benutzer (A) zum Aufbauen einer ersten sicheren Session; Empfangen (204) einer Anforderung von dem ersten Benutzer (A) zum Auflisten eines Dateiverzeichnisses; Authentifizieren des Zugriffs des ersten Benutzers auf das Dateiverzeichnis unter Verwendung einer Legitimation, die durch den ersten Benutzer (A) bereitgestellt wird, wenn die erste sichere Session aufgebaut wird; Senden (206) einer Auflistung des Dateiverzeichnisses über die erste sichere Session an den ersten Benutzer; wobei die Auflistung einen Satz von Pfaden zu auf dem Dokumentenserver verfügbarem Inhalt angibt; Austauschen (404) von öffentlichen Schlüsseln mit dem zweiten Benutzer (B) zum Aufbauen einer zweiten sicheren Session; Empfangen (406) einer Anforderung des Zugriffs auf ausgewählten Inhalt auf dem Dokumentenserver von dem zweiten Benutzer (B); wobei die Anforderung des Zugriffs eine Token-Kennung enthält, die auf dem Dokumentenserver (102) aufge zeichnet ist und die mit einem Pfad aus dem Satz von Pfaden zu dem auf dem Dokumentenserver ausgewählten Inhalt verknüpft ist; Authentifizieren (410) der Anforderung des Zugriffs unter Verwendung der folgenden Elemente: (a) des von dem zweiten Benutzer (B) während des Aufbauens der zweiten sicheren Session empfangenen öffentlichen Schlüssels des zweiten Benutzers (B), und (b) einer digitalen Signatur, die unter Verwendung des privaten Schlüssels des ersten Benutzers (A) signiert wird, die eine signierte verschlüsselte Kurzfassung des öffentlichen Schlüssels des zweiten Benutzers und anderer Informationen ist, die sich auf die Anforderung des Zugriffs auf den ausgewählten Dokumenteninhalt auf dem Dokumentenserver beziehen; und Bereitstellen (414) des Zugriffs auf den ausgewählten Inhalt für den zweiten Benutzer (B) über die zweite sichere Session, wenn die Anforderung des Zugriffs authentifiziert wird.
Verfahren nach Anspruch 1, das des Weiteren die folgenden Schritte umfasst: Empfangen einer Anforderung von dem ersten Benutzer (A) zum Erstellen eines Tokens, das mit dem Pfad zu dem auf dem Dokumentenserver verfügbaren ausgewählten Inhalt verknüpft ist; Erstellen (212) des Tokens in einer Datenbank (124) von Token auf dem Dokumentenserver, wobei mit dem Token die Token-Kennung verknüpft ist; und Senden der Token-Kennung, die den Token in der Token-Datenbank eindeutig identifiziert, über eine sichere Session an den ersten Benutzer (220).
Verfahren nach Anspruch 2, das des Weiteren die folgenden Schritte umfasst: Empfangen (210) des Pfades aus dem Satz von Pfaden, der den auf dem Dokumentenserver verfügbaren ausgewählten Inhalt identifiziert, über die erste sichere Session von dem ersten Benutzer; Senden der Token-Kennung über die erste sichere Session an den ersten Benutzer; wobei die Token-Kennung mit dem Pfad zu dem auf dem Dokumentenserver verfügbaren ausgewählten Inhalt verknüpft ist; und Empfangen (220) der digitalen Signatur der signierten verschlüsselten Kurzfassung des öffentlichen Schlüssels des zweiten Benutzers und der Token-Kennung von dem ersten Benutzer über die erste sichere Session.
Verfahren nach Anspruch 2 oder Anspruch 3, das des Weiteren das Empfangen der digitalen Signatur der signierten verschlüsselten Kurzfassung des öffentlichen Schlüssels des zweiten Benutzers (B) und anderer Informationen bezüglich der Anforderung des Zugriffs auf den ausgewählten Dokumenteninhalt auf dem Dokumentenserver über eine dritte sichere Session von dem ersten Benutzer (A) umfasst.
Verfahren nach einem der Ansprüche 2 bis 4, wobei die anderen Informationen bezüglich der Anforderung des Zugriffs auf den ausgewählten Dokumenteninhalt auf dem Dokumentenserver eine oder mehrere Token-Kennungen, ein Erstellungsdatum des Tokens, Zugriffsrechte auf den ausgewählten Inhalt, den gesamten ausgewählten Inhalt oder Teile davon und eine Versionsnummer des ausgewählten Inhalts umfasst.
Verfahren nach einem der vorangehenden Ansprüche, wobei der Dokumentenserver (102) in einem durch eine Firewall (112) geschützten Intranet positioniert ist und wobei die erste sichere Session und die zweite sichere Session durch die Firewall tunneln.
Dokumentenserver (102) zum Ausführen eines Verfahrens, bei dem ein erster Benutzer (A) für einen zweiten Benutzer (B) einen sicheren Zugriff auf elektronische Dokumente oder Dienste bereitstellt, die auf dem in einem Netzwerk positionierten Dokumentenserver gespeichert sind, wobei der erste Benutzer (A) ein registrierter Benutzer des Dokumentenservers ist und der zweite Benutzer (B) kein registrierter Benutzer des Dokumentenservers ist und wobei sowohl der erste Benutzer, als auch der zweite Benutzer und der Dokumentenserver jeder mit einem öffentlichen Schlüssel damit verknüpft ist, der mit einem entsprechenden privaten Schlüssel verknüpft ist, wobei der Dokumentenserver Folgendes umfasst: einen Speicher zum Speichern von Befehlen; und einen Prozessor, der zum Ausführen der Befehle des Dokumentenservers mit dem Speicher verbunden ist; wobei der Prozessor die folgenden Befehle ausführt: Austauschen (132) von öffentlichen Schlüsseln mit dem ersten Benutzer (A) zum Aufbauen einer ersten sicheren Session; Empfangen (204) einer Anforderung von dem ersten Benutzer (A) zum Auflisten eines Dateiverzeichnisses; Authentifizieren des Zugriffs des ersten Benutzers auf das Dateiverzeichnis unter Verwendung einer Legitimation, die durch den ersten Benutzer (A) bereitgestellt wird, wenn die erste sichere Session aufgebaut wird; Senden (206) einer Auflistung des Dateiverzeichnisses über die erste sichere Session an den ersten Benutzer; wobei die Auflistung einen Satz von Pfaden zu auf dem Dokumentenserver verfügbarem Inhalt angibt; Austauschen (404) von öffentlichen Schlüsseln mit dem zweiten Benutzer zum Aufbauen einer zweiten sicheren Session; Empfangen (406) einer Anforderung des Zugriffs auf ausgewählten Inhalt auf dem Dokumentenserver von dem zweiten Benutzer; wobei die Anforderung des Zugriffs eine Token-Kennung enthält, die auf dem Dokumentenserver aufgezeichnet ist und die mit einem Pfad aus dem Satz von Pfaden zu dem auf dem Dokumentenserver verfügbaren Inhalt verknüpft ist; Authentifizieren (410) der Anforderung des Zugriffs unter Verwendung der folgenden Elemente: (a) des von dem zweiten Benutzer während des Aufbauens der zweiten sicheren Session empfangenen öffentlichen Schlüssels des zweiten Benutzers, und (b) einer digitalen Signatur, die unter Verwendung des privaten Schlüssels des ersten Benutzers signiert wird, die eine signierte verschlüsselte Kurzfassung des öffentlichen Schlüssels des zweiten Benutzers und anderer Informationen ist, die sich auf die Anforderung des Zugriffs auf den ausgewählten Dokumenteninhalt auf dem Dokumentenserver beziehen; und Bereitstellen (414) des Zugriffs auf den ausgewählten Inhalt für den zweiten Benutzer über die zweite sichere Session, wenn die Anforderung des Zugriffs authentifiziert wird.
Server nach Anspruch 7, wobei der Server so eingerichtet ist, dass er ein Verfahren nach einem der Ansprüche 1 bis 6 ausführt.
Computerprogrammerzeugnis, das einen Programmcode zum Implementieren eines Verfahrens nach einem der Ansprüche 1 bis 6 speichert.