DE602004012870T2

DE602004012870T2 - Verfahren und system zur benutzerauthentifizierung in einer benutzer-anbieterumgebung

Info

Publication number: DE602004012870T2
Application number: DE602004012870T
Authority: DE
Inventors: Joachim Hagmeier; Joachim Bruchlos; Timo Kussmaul
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2003-07-11
Filing date: 2004-05-19
Publication date: 2009-05-14
Anticipated expiration: 2024-05-20
Also published as: WO2005006703A2; TWI322609B; EP1654852A2; KR20060040661A; EP1654852B1; ATE391385T1; WO2005006703A3; TW200509641A; DE602004012870D1; US20060264202A1; JP2009514050A; CN1820481B; CN1820481A; KR100856674B1

Description

Gebiet der vorliegenden Erfindung
Die vorliegende Erfindung betrifft die Berechtigungsüberprüfung (authentication – Identitätsprüfung) im Allgemeinen und insbesondere die Berechtigungsüberprüfung in einer Client-Server-Umgebung, und insbesondere die Berechtigungsüberprüfung von Clients im Internet.
Grundlagen der Erfindung
Eine Berechtigungsüberprüfung ist eine Prozedur, um festzustellen, ob jemand oder etwas tatsächlich der bzw. das ist, was er oder es zu sein vorgibt. In privaten und öffentlichen Computernetzen erfolgt die Berechtigungsüberprüfung im Allgemeinen durch die Verwendung von Anmelde-Passwörtern. Normalerweise verwaltet jeder Server seine eigene Datenbeständigkeit, um Berechtigungsüberprüfungsdaten zu speichern. Daher können Passwörter, die dem Client in einem Server zur Verfügung stehen, von einem anderen Client in einem anderen Server bereits blockiert werden. Dadurch erhöht sich die Anzahl verschiedener Berechtigungsüberprüfungssätze, an die sich der Client erinnern und die er verwalten muss. In Anwendungen, die über mehrere Server mit unterschiedlichen Berechtigungsüberprüfungssystemen verteilt sind (z. B. zugreifen auf eine Anwendung durch einen Portalserver, wobei der Portalserver seine eigene Benutzerdatenbank verwendet), würde sich der Client mehr als einmal anmelden müssen.
Zu Ad-hoc-Lösungen zum Ermöglichen einer Einmalanmeldung (single signon) gehören Lösungsansätze wie die Speicherung von Anmeldedaten für die Anwendungs-Server im Portal-Server oder die Verwendung von zentralisierten Benutzerdatenbanken wie .NET Passport von Microsoft (http://www.passport.com) oder Liberty von Liberty Alliance (http://www.projectliberty.org). Dies macht es erforderlich, dass der Client bereit ist, persönliche Daten mit all den Problemen der Datensicherheit, die mit diesem Lösungsansatz einhergehen, am Standort eines Dritten zu speichern. Außerdem ist im Falle eines Ausfalls des Passdienstes keine Anmeldung zum gewünschten Dienst möglich, selbst wenn die Web-Seite, die man nutzen möchte, verfügbar ist.
Die Verwendung einer Kennung/eines Passwortsatzes zur Berechtigungsüberprüfung hat außerdem den Nachteil, dass dies zu einem zusätzlichen Netzdatenverkehr führt. Auf eine Client-Anforderung muss der Server antworten, indem er nach den Anmeldedaten fragt. Nur nach Bereitstellung derselben werden die ursprünglich angeforderten Daten an den Client rückübertragen (siehe auch 7A unten).
Schließlich können Passwörter oftmals gestohlen, versehentlich enthüllt oder einfach vergessen werden.
Aus diesem Grund erfordern Internet-Geschäfte und viele andere Transaktionen einen strengeren Berechtigungsüberprüfungsprozess. Die Verwendung digitaler Zertifikate, die von einer Zertifizierungsstelle (Certificate Authority – CA) als Teil einer Infrastruktur mit öffentlichem Schlüssel erteilt und überprüft werden, wird als künftige Standardmöglichkeit zum Ausführen einer Berechtigungsüberprüfung im Internet angesehen.
Digitale Signaturen ermöglichen dem Empfänger (Server) die Überprüfung der Identität des Absenders (Client) und des Ursprungs sowie der Unversehrtheit des Dokuments.
Digitale Signaturen beruhen auf asymmetrischen Verschlüsselungsalgorithmen. Die Dokumente werden mit dem privaten Schlüssel des Absenders signiert. Der Empfänger kann den öffentlichen Schlüssel des Absenders, der ihm durch einen vertrauenswürdigen Dritten bereitgestellt wird, verwenden und die Unversehrtheit des empfangenen Dokumentes überprüfen.
Die Realisierung einer Prozedur mit digitaler Signatur in eine bereits vorhandene Passwort-Anmeldeinfrastruktur erfordert große Änderungen auf Seiten des Server sowie des Client, z. B. ein zusätzliches Kartenlesegerät mit spezifischen Sicherheitsanwendungen. Daher verursachen solche Realisierungen einen hohen Kosten- und Zeitaufwand mit der Folge, dass vorzugsweise nur neue Client-Server-Infrastrukturen die Prozedur der digitalen Signatur verwenden. Das Vorhandensein jener beiden Berechtigungsüberprüfungsprozeduren in der Client-Server-Umgebung hat den Nachteil, dass ein Client zuerst prüfen muss, ob der Zielserver die Passwortanmeldung oder die Prozedur der digitalen Signatur unterstützt. In Abhängigkeit von diesem Ergebnis verwendet der Client den vom Server unterstützten benötigten Berechtigungsüberprüfungsprozess. Dies verursacht viel unnötigen Netzdatenverkehr zwischen Client und Server, da die Serveranwendung selbst schließlich den Typ von Berechtigungsüberprüfung festlegt.
Außerdem haben die vorhandenen Berechtigungsüberprüfungsprozeduren mit digitaler Signatur den Nachteil, dass mehrere Bildschirminformationen zwischen Client und Server ausgetauscht werden müssen, bis der Client seine Berechtigungsüberprüfungsdaten bereitstellen kann. Dies verursacht viel unnötigen Datenverkehr.
In der US-Patentanmeldung 2002/0133700 A1 werden ein Verfahren und ein System zur Übertragung eines Zertifikats zwischen einem Sicherheitsmodul und einem Server beschrieben. Das von der vorliegenden Erfindung aufgeworfene Problem ist das Fehlen eines Mittels zum Übertragen eines Zertifikats von einem Client zwischen einem Sicherheitsmodul und einem Server, wobei das zwischen dem Client und dem Server verwendete Protokoll HTTP oder ein gleichartiges Protokoll, ein Sicherheitsprotokoll wie SSL oder ein gleichartiges Protokoll zwischen dem Client und dem Sicherheitsmodul ausgeführt wird. Es werden ein Verfahren und eine Einheit zum Übertragen des Zertifikats vom Modul an den Server geboten, bestehend aus dem Einfügen des Zertifikats in einen Cookie-Vorsatz einer vom Client übertragenen Anforderung in HTTP oder einem gleichartigen Protokoll.
Aufgabe der Erfindung
Ausgehend hiervon besteht die Aufgabe der vorliegenden Erfindung in der Bereitstellung eines Verfahrens und eines Systems zur Berechtigungsüberprüfung von Clients in einer Client-Server-Umgebung bei gleichzeitigem Vermeiden der Nachteile des oben erwähnten Standes der Technik.
Kurze Zusammenfassung der Erfindung
Die Idee der vorliegenden Erfindung besteht darin, den vorhandenen auf Passwort/Benutzerkennung beruhenden Berechtigungsüberprüfungsprozess durch einen neuen Berechtigungsüberprüfungsprozess mit digitaler Signatur zu ersetzen, in dem vorzugsweise der erste HTTP-Anforderungsvorsatz wird um die Client-Berechtigungsüberprüfungsdaten erweitert wird, unabhängig von dem vom Zielserver verwendeten Berechtigungsüberprüfungsprozess und ohne die Anforderung von Berechtigungsüberprüfungsdaten durch den Server. Die Berechtigungsüberprüfungsdaten beinhalten vorzugsweise das von einer Zertifizierungsstelle unterzeichnete Client-Zertifikat, das den öffentlichen Schlüssel des Client enthält, und vorzugsweise einen Hash-Wert, der über die in der Anforderung übertragenen HTTP-Anforderungsvorsatzdaten berechnet und mit dem privaten Schlüssel des Client verschlüsselt wurde. Das Zertifikat und die digitale Signatur können während der Erzeugung des HTTP-Anforderungsvorsatzes im Client-System selbst oder später in einem als Gateway, Proxy oder Tunnel fungierenden Server hinzugefügt werden.
Ein Zielserver, der den neuen Berechtigungsüberprüfungsprozess mit digitaler Signatur nicht unterstützt, ignoriert einfach das Zertifikat und die digitale Signatur im HTTP-Anforderungsvorsatz und leitet automatisch seinen eigenen Berechtigungsüberprüfungsprozess ein. Die vorliegende Erfindung vereinfacht den vorhandenen Berechtigungsüberprüfungsprozess mit digitaler Signatur und ermöglicht gleichzeitig das Vorhandensein anderer Berechtigungsüberprüfungsprozesse, ohne das HTTP-Protokoll zu ändern oder einen unnötigen Netzdatenverkehr zu verursachen.
Kurze Beschreibung der verschiedenen Ansichten der Zeichnungen
Die obigen sowie zusätzliche Zielsetzungen, Merkmale und Vorteile der vorliegenden Erfindung gehen aus der folgenden ausführlichen Beschreibung hervor.
Die neuartigen Merkmale der Erfindung werden in den angehängten Ansprüchen dargelegt. Die Erfindung selbst sowie eine bevorzugte Art und Weise der Benutzung, weitere Zielsetzungen und Vorteile davon, werden am besten mit Bezugnahme auf die folgende ausführliche Beschreibung einer veranschaulichenden Ausführungsform verstanden, wenn sie in Verbindung mit den begleitenden Zeichnungen gelesen wird, in denen:
1A/B HTTP-Client-Server-Umgebungen nach dem Stand der Technik zeigen, in denen die vorliegende Erfindung vorzugsweise verwendet wird,
2 die Grundstruktur eines typischen HTTP-Vorsatzes nach dem Stand der Technik zeigt,
3 die erfindungsgemäße Struktur des HTTP-Vorsatzes mit dem Zertifikat und der digitalen Signatur zeigt,
4A bis D die bevorzugten Ausführungsformen zum Einfügen des Zertifikates zusammen mit der digitalen Signatur in den HTTP-Anforderungsvorsatz zeigen, woraus sich die erfindungsgemäße Struktur des HTTP-Anforderungsvorsatzes ergibt,
5 ein Beispiel einer Server-Client-Datenaustauschumgebung unter Verwendung der vorliegenden Erfindung zeigt,
6 eine bevorzugte Ausführungsform des Berechtigungsüberprüfungs-Datenflusses in einer Client-Server-Umgebung gemäß 1A unter Verwendung der erfindungsgemäßen Struktur der HTTP-Anforderung zeigt, und
7A, B einen Vergleich des Berechtigungsüberprüfungsprozesses nach dem Stand der Technik mit dem erfindungsgemäßen Berechtigungsüberprüfungsprozess der vorliegenden Erfindung auf der Grundlage eines Beispiels eines Online-Kauftransaktionsprozesses zeigen.
Mit Bezugnahme auf 1A und 1B werden Client-Server-Umgebungen gezeigt, in denen die vorliegende Erfindung vorzugsweise verwendet wird. Es sei jedoch darauf hingewiesen, dass die vorliegende Erfindung in jeder Client-Server-Umgebung mit Verwendung von Übertragungsprotokollen, die Vorsatzerweiterungen ohne Verletzung der normalen Protokollnutzung ermöglichen, verwendet werden kann. Daher wird die vorliegende Erfindung mit ihren bevorzugten Ausführungsformen im gegenwärtig am meisten bekannten HTTP-Protokoll beschrieben und erläutert.
Das HTTP-Protokoll (Hypertext Transfer Protocol) ist ein Protokoll auf Anwendungsebene für verteilte Systeme. Es handelt sich um einen Satz von Regeln zum Austausch von Dateien (Text-, Grafik-, Bild-, Ton-, Video- und andere Multimediadateien). Jede Web-Servermaschine 3 enthält eine HTTP-Hintergrundroutine oder einen so genannten HTTP-Server 4, ein Programm, das so beschaffen ist, dass es auf HTTP-Anforderungen wartet und diese bei Eingehen bearbeitet. Außerdem enthält jede Clientmaschine 1 einen Web-Browser oder einen so genannten HTTP-Client 2, der Anforderungen an die Web-Servermaschine 3 überträgt. Wenn der Benutzer des Browser eine Anforderung eingibt, indem er eine Web-Datei öffnet (Eintippen einer Verweisadresse URL) oder eine Hypertext-Verbindung anklickt, erstellt der Browser eine HTTP-Anforderung und überträgt diese an die in der URL angezeigte Internetprotokolladresse. Der HTTP-Server 4 im der Ziel-Servermaschine 3 empfängt die Anforderung, und nach der Verarbeitung wird die angeforderte Datei rückübertragen. In einer anderen Client-Server-Umgebung tauscht der Client 1 über einen Gateway, einen Tunnel oder einen Proxy-Server 5 Daten mit dem Server 3 aus (siehe 1B).
Normalerweise erfolgt HTTP über TCP/IP (Transmission Control Protocol/Internet Protocol), HTTP ist jedoch nicht von TCP/IP abhängig.
TCP definiert einen Satz von Regeln zum Austausch von Nachrichten mit anderen Internetstellen auf der Datenpaketebene, und IP definiert einen Satz von Regeln zum Übertragen und Empfangen von Nachrichten auf der Internet-Adressebene.
Ein HTTP-Anforderungsvorsatz besteht aus dem HTTP-Verfahren (GET, HERD, POST usw.), dem Universal Resource Identifier (URI), der Protokollversion und wahlweise zusätzlichen Daten.
Eine HTTP-Antwort besteht aus einer Statuszeile, die den Erfolg oder Fehlschlag der Anforderung anzeigt, einer Beschreibung der Daten in der Antwort (Metadaten) und der eigentlichen Datenanforderung.
Mit Bezugnahme auf 2 wird die Grundstruktur eines HTTP-Anforderungsvorsatzes nach dem Stand der Technik gezeigt. Jede HTTP-Anforderung muss mindestens einen Vorsatz enthalten. Nur HTTP-POST-Anforderungen (HTTP-Post requests) enthalten Vorsatz- und Hauptteildaten. Die folgenden Daten sind vorzugsweise in einem HTTP-Anforderungsvorsatz enthalten: Ressourcen, auf die die HTTP-Anforderung zugreifen muss (z. B. Datei, Servlet).
Host-Name des Server (z. B. www.ibm.com). Browser-Name und Version (z. B. Netscape Version 7.1). Betriebssystem des Client (z. B. Windows XP). Zeichensatz, den der Browser verstehen kann (z. B. ISO-8859-1).
Jeder HTTP-Vorsatz kann zusätzliche Daten enthalten, die vom HTTP-Protokoll nicht definiert werden und die nicht zu Konflikten mit vorhandenen das HTTP-Protokoll verwendenden Anwendungen führen. Dies bedeutet, dass eine Anwendung, die das HTTP-Protokoll verwendet und nicht so konfiguriert ist, dass sie diese zusätzlichen Daten verarbeitet, diese einfach ignoriert, ohne ihre Ausführung zu unterbrechen.
Mit Bezugnahme auf 3 wird die erfindungsgemäße Struktur eines HTTP-Anforderungsvorsatzes gemäß der vorliegenden Erfindung gezeigt.
Die folgenden zusätzlichen Daten müssen gemäß der vorliegenden Erfindung in den HTTP-Anforderungsvorsatz aufgenommen werden:
das Client-Zertifikat, das den öffentlichen Schlüssel enthält und von einer Zertifizierungsstelle signiert ist, und eine digitale Signatur, die über den HTTP-Anforderungsvorsatz und gegebenenfalls den HTTP-Hauptteil (Post) berechnet wurde.
Das Zertifikat und die digitale Signatur können von spezifischen Hilfsprogrammen im Server verarbeitet werden. Ein Client-Zertifikat ist ein von einem vertrauenswürdigen Dritten verteiltes Dokument, das einen öffentlichen Schlüssel mit einer spezifischen Person verbindet. Der vertrauenswürdige Dritte garantiert, dass die im Zertifikat enthaltenen Daten gültig und korrekt sind. Zertifikate werden durch 509 standardisiert. Sie müssen die digitale Signatur des vertrauenswürdigen Dritten, den Namen der Person, die den öffentlichen Schlüssel besitzt, und den öffentlichen Schlüssel selbst enthalten.
Mit Bezugnahme auf 4A bis C werden bevorzugte Ausführungsformen zum Einfügen des Client-Zertifikats und der digitalen Signatur in den HTTP-Anforderungsvorsatz gezeigt.
Mit Bezugnahme auf 4A wird eine erste Ausführungsform der vorliegenden Erfindung zum Einfügen des Client-Zertifikats 16 zusammen mit der digitalen Signatur 18 in den HTTP-Anforderungsvorsatz 12 gezeigt. Das Clientsystem 1 enthält einen Browser 2 mit Signaturfähigkeiten. Der Browser 2 erzeugt einen HTTP-Anforderungsvorsatz 12, greift auf den privaten Schlüssel des Client zu, der in einem lokalen Dateisystem sicher gespeichert ist, verschlüsselt einen über den HTTP-Anforderungsvorsatz 12 und gegebenenfalls den Hauptteil erzeugten Hash-Wert mit dem privaten Schlüssel, woraus sich eine digitale Signatur 18 ergibt. Diese digitale Signatur 18 wird zusammen mit dem den öffentlichen Schlüssel enthaltenden Client-Zertifikat 16 in den HTTP-Anforderungsvorsatz 12 eingefügt. Der erweiterte HTTP-Anforderungsvorsatz 14 wird an den HTTP-Server 4 übertragen, der den Berechtigungsüberprüfungsprozess einleitet. Die Berechtigungsüberprüfungskomponente 6, die ein Teil des HTTP-Server oder eine gesonderte Komponente sein kann, überprüft die Client-Zertifikatdaten 16 aus dem HTTP-Anforderungsvorsatz. Die Überprüfung kann durch Prüfen der Zertifikatsignatur der Zertifizierungsstelle oder Vergleichen mit bereits bekannten, in ihrer Zertifizierungsdatenbank 9 enthaltenen Zertifikaten erfolgen. Unter Verwendung des im Client-Zertifikat 16 enthaltenen öffentlichen Schlüssels wird die im HTTP-Anforderungsvorsatz 12 enthaltene digitale Signatur 18 entschlüsselt, woraus sich ein vom Client 1 berechneter Hash-Wert ergibt. Unter Verwendung desselben Hash-Algorithmus wird der Hash-Wert über den HTTP-Anforderungsvorsatz 12 und gegebenenfalls den Hauptteil berechnet. Falls die Hash-Werte übereinstimmen, ist die Überprüfung beendet und die Berechtigungsüberprüfung erfolgreich, und der Zugriff auf eine Anwendung 8 wird erteilt.
Mit Bezugnahme auf 4B wird eine zweite Ausführungsform der vorliegenden Erfindung gezeigt, um das Client-Zertifikat 18 zusammen mit der digitalen Signatur 16 in den HTTP-Anforderungsvorsatz 12 einzufügen. Nun hat der Browser 2 die Funktionalität, über ein Chipkartenlesegerät 10 mit einer Chipkarte 10 Daten auszutauschen. Der Browser 2 erzeugt einen HTTP-Anforderungsvorsatz, richtet eine Verbindung zum Datenaustausch mit der Chipkarte 10 ein, die Chipkarte 10, die in ihrem Sicherheitsmodul einen privaten Schlüssel und das Zertifikat des Client enthält, verschlüsselt einen über den HTTP-Anforderungsvorsatz 12 und gegebenenfalls den Hauptteil erzeugten Hash-Wert mit dem privaten Schlüssel (digitale Signatur) und rücküberträgt eine digitale Signatur 18 zusammen mit dem Client-Zertifikat 16 an den Browser 2. Diese digitale Signatur 18 wird zusammen mit dem den öffentlichen Schlüssel enthaltenden Client-Zertifikat 16 in den HTTP-Anforderungsvorsatz 12 eingefügt. Der erweiterte HTTP-Anforderungsvorsatz 14 wird an den HTTP-Server 4 übertragen, der unter Verwendung einer Berechtigungsüberprüfungskomponente den Berechtigungsüberprüfungsprozess einleitet (siehe Beschreibung von 4A).
Mit Bezugnahme auf 4C wird eine dritte Ausführungsform der vorliegenden Erfindung zum Einfügen des Client-Zertifikats 16 zusammen mit der digitalen Signatur 18 in den HTTP-Anforderungsvorsatz 12 gezeigt. In der dritten Ausführungsform enthält das Clientsystem eine eigene Signaturkomponente 20. Diese Komponente fungiert als Proxy-Server, der im selben Client 1 wie der Browser 2 ausgeführt wird. Der Browser 2 ist so konfiguriert, dass er diesen Proxy-Server 20 verwendet. Aus diesem Grund überträgt der Browser 2 den regulären HTTP-Anforderungsvorsatz 12 an die Signaturkomponente 20, die das Zertifikat 16 und die digitale Signatur 18 sodann analog zu den oben beschriebenen Ausführungsformen einfügt. Der erweiterte HTTP-Anforderungsvorsatz wird an den HTTP-Server 4 übertragen, der den Berechtigungsüberprüfungsprozess unter Verwendung einer Berechtigungsüberprüfungskomponente einleitet (siehe Beschreibung von 4A).
Mit Bezugnahme auf 4D wird eine vierte Ausführungsform der vorliegenden Erfindung zum Einfügen des Client-Zertifikats 16 zusammen mit der digitalen Signatur 18 in den HTTP-Anforderungsvorsatz 12 gezeigt. In dieser Ausführungsform wird die Client-Anforderung (1a/2a; 1b/2b) über einen Proxy-Server 22 mit einer Einfügungskomponente 20 geleitet. Die Einfügungskomponente 20 tauscht Daten mit einer Verschlüsselungshardware 24 aus, die private Schlüssel und deren zugeordnete Zertifikate enthält und die einen über den HTTP-Anforderungsvorsatz 12 und gegebenenfalls den Hauptteil erzeugten Hash-Wert mit dem privaten Schlüssel (digitale Signatur) verschlüsselt, und rücküberträgt die digitale Signatur 18 mit dem Client-Zertifikat 16 an die Einfügungskomponente 20, die diese in den HTTP-Anforderungsvorsatz 12 einfügt. Der erweiterte HTTP-Anforderungsvorsatz 14 wird an den HTTP-Server 4 übertragen, der unter Verwendung einer Berechtigungsüberprüfungskomponente den Berechtigungsüberprüfungsprozess einleitet (siehe Beschreibung von 4A).
Da die vorliegende Erfindung zusätzliche Vorsatzdaten im HTTP-Protokoll beschreibt, können jedenfalls alle Kombinationen von vorhandenen Clients und Servern, die die zusätzlichen Daten im Vorsatz verarbeiten können, zusammenarbeiten. Falls es einem der Systeme nicht möglich ist, zusätzliche Daten zu bearbeiten, funktioniert alles auf gegenwärtig bekannte Art und Weise.
Zur Beibehaltung der vorhandenen Basis von Milliarden installierter Client-Browser könnte eine zusätzliche Signatur-Software die HTTP-Erweiterung bearbeiten, indem sie als eine Proxy-Komponente in der lokalen Client-Maschine fungiert (siehe 4C). In Firmennetzwerken (z. B. Intranet) könnte dies von einem zentralen Proxy-Server bearbeitet werden (4C).
In zukünftigen Versionen von Web-Browsern ist die Funktionalität dann möglicherweise integriert (4A). Auf diese Weise kann im Laufe der Zeit der Übergang zu dem neuen Paradigma erfolgen.
Die digitale Signatur kann unter Verwendung einer Signatur-Chipkarte oder einer beliebigen anderen Signaturhardware erzeugt werden. Auch eine reine Software-Lösung mit einem Speicher für Verschlüsselungsschlüssel im Client-Computer wäre eine mögliche Ausführung.
5 zeigt ein Beispiel einer Server-Client-Datenübertragungsumgebung unter Verwendung der vorliegenden Erfindung.
In diesem Beispiel wird vorausgesetzt, dass ein Portalserver 3 auf eine Anwendung 5 zugreift. Nach dem Stand der Technik wird in dieser Situation so vorgegangen, dass entweder die Identitätsdaten des Client in einem Server gespeichert werden, auf den der Portalserver 3 und der Anwendungsserver 5 zugreifen können (z. B. .NET Passport von Microsoft^®), oder die Identitätsdaten für den Anwendungsserver im Portalserver 3 gespeichert werden müssen. Beide Lösungsansätze machen es erforderlich, dass der Benutzer seine Daten in einem dritten System gespeichert hat, wobei sich viele Sicherheitsprobleme ergeben.
Durch das digitale Signieren der Anforderung, wie es in 4A bis D erläutert wird, muss kein Server die Benutzerdaten speichern. Der Portalserver 3 kann die Identität des Anforderers durch Vergleich mit seiner Benutzerdatenbank überprüfen, wobei die Anforderung an den Anwendungsserver 5 weitergeleitet wird, der dasselbe unter Verwendung seiner Benutzerdatenbank 6 tun kann. Der Client 1a greift durch den Portalserver 3 auf den Anwendungsserver 5 zu, während der Client 1b direkt auf den Anwendungsserver 5 zugreifen kann. Der Anwendungsserver 5 kann seine eigene Benutzerdatenbank 6 verwenden, um Profildaten für den Benutzer abzurufen.
Der Lösungsansatz stellt sogar eine höhere Sicherheit bereit, da der Anwendungsserver 5 möglicherweise nur jene Anforderungen bearbeiten möchte, die den Portalserver 3 durchlaufen haben. In diesem Fall leitet der Portalserver 3 die Anforderung weiter und signiert diese zusätzlich. Dies ermöglicht es dem Anwendungsserver 5, beide Signaturen zu überprüfen, um den Zugriff auf seine Dienste zu erteilen oder zu verweigern. Der Client 1a würde den Zugriff auf den Anwendungsserver 5 erhalten, während der Client 1b nicht bedient werden würde, da seine Anforderung nicht durch den Portalserver 3 läuft.
Mit Bezugnahme auf 6 wird der Datenfluss einer Berechtigungsüberprüfung gemäß der vorliegenden Erfindung gezeigt. Der Browser des Client bereitet eine Anforderung an den Server 10 vor. In einer bevorzugten Ausführungsform der vorliegenden Erfindung wird überprüft, ob der Signiervorgang des HTTP-Anforderungsvorsatzes eingeschaltet ist, 20. Falls nicht, überträgt der Browser des Client eine nichtsignierte Anforderung an den Server 40, und der Server prüft, ob ein Signiervorgang erforderlich ist, 50. Falls ein Signiervorgang erforderlich ist, überträgt der Server eine Fehlermeldung an den Client 50. Falls kein Signiervorgang erforderlich ist, stellt der Server den Zugriff auf die gewünschten Daten bereit, 60. Falls ein Signiervorgang eingeschaltet ist, fügt der Browser des Client das Zertifikat und die digitale Signatur in den HTTP-Anforderungsvorsatz ein und überträgt diesen an den Server 30. Durch das Anhängen der zusätzlichen Felder an den HTTP-Anforderungsvorsatz kann der Server die Identität des Anforderers aus dem Zertifikat abrufen (Berechtigungsüberprüfung), 35.
Das Zertifikat des Client enthält den Namen und den öffentlichen Schlüssel des Anforderers.
Da das Zertifikat von einer vertrauenswürdigen Stelle signiert worden ist, kann der Server überprüfen, ob es sich um ein gültiges Zertifikat handelt, das von der vertrauenswürdigen Stelle ausgegeben wurde. Die Überprüfung, ob die Nachricht tatsächlich vom Eigner des Zertifikats übertragen wurde, ist möglich, da nur der Eigner des zum Zertifikat gehörigen privaten Schlüssels den digitalen Signaturwert im HTTP-Anforderungsvorsatz, der über die HTTP-Anforderungsvorsatzdaten berechnet wurde und durch die Verwendung des im Zertifikat enthaltenen öffentlichen Schlüssels überprüft werden kann, erzeugt haben kann. Wenn die Berechtigungsüberprüfung erfolgreich war, stellt der Server den Zugriff auf die angeforderten Daten bereit, 60.
Mit Bezugnahme auf 7A, B werden typische Szenarien des Austauschs von Daten zwischen Web-Browser (Client) und Web Server (Server) unter Verwendung des Berechtigungsüberprüfungsprozesses nach dem Stand der Technik im Vergleich zum erfindungsgemäßen Berechtigungsüberprüfungsprozess der vorliegenden Erfindung gezeigt.
Beispielsweise empfängt bzw. überträgt der Client während eines Kaufprozesses Daten (z. B. eine Reihe von Text- oder HTML-Seiten oder Blöcke von formatierten Daten wie XML) vom bzw. an den das Online-Einkaufsystem darstellenden Server, bis die Bestellung durch einen spezifischen Datenübertragungsvorgang bestätigt wird (z. B. HTTP-Post). In gegenwärtig vorliegenden Anwendungen gibt der Server eine Anforderung aus, um während dieses Prozesses eine Benutzerkennung und ein Passwort vom Client zu erhalten. Der Benutzer muss diese Daten manuell eingeben, bevor sie durch die Client-Anwendung an den Server übertragen werden (siehe 7A).
In einer der vorliegenden Erfindung entsprechenden Anwendung (siehe 7B) signiert der Client die an den Server übertragenen HTTP-Anforderungsvorsatzdaten mittels einer digitalen Signatur. Durch Überprüfen der Signatur identifiziert der Server den Client problemlos. Daher ist es nicht notwendig, die Benutzerkennung und das Passwort anzufordern und einzugeben, da jedes übertragene Datenelement der Identität des Benutzers zugeordnet ist. Der Server kann für diesen Client gespeicherte Daten abrufen und diese bei der Vorbereitung der Daten, die an den Client übertragen werden müssen, verwenden ("Personalisierung", Profilerstellungsseite). Beispiele für zur Personalisierung verwendete Daten sind die Adresse des Benutzers (wohin sollen die bestellten Artikel geliefert werden), das Einkaufsprotokoll des Benutzers, der Warenkorb des Benutzers, die während der letzten Sitzungen besuchten Web-Seiten usw.
Durch Überprüfen der Identität des Benutzers (was zu jedem beliebigen Zeitpunkt während des Datenflusses erfolgen kann) stellt der Server möglicherweise fest, dass der Benutzer diese Web-Seite nie zuvor besucht hat. Der Server kann sodann Daten übertragen, die eine Anforderung zur Angabe von Vorlieben und ausführlichen Benutzerdaten enthalten (Profilerstellungsseite). Der Benutzer gibt diese Daten ein, die Client-Anwendung überträgt diese an den Server, und der Server speichert diese Daten zur Personalisierung in seiner Datenbank. Da jede Datenübertragung signiert wird, ist die Benutzerkennung des Client dem Server bekannt, sobald der Client die erste Seite besucht. Die Personalisierung kann daher zu einem frühen Zeitpunkt während des Prozesses stattfinden.
Wenn der Benutzer sich entscheidet, den Signiervorgang auszuschalten, erkennt der Server diese Tatsache und kann eine Seite übertragen, die einen Hinweis zum Einschalten des Signiervorgangs enthält, oder er könnte stattdessen herkömmliche Szenarios mit Benutzerkennung/Passwort verwenden (nicht gezeigt).

Claims

Verfahren zur Berechtigungsüberprüfung von Clients in einer Client-Server-Umgebung, wobei die Client-Server-Umgebung ein Übertragungsprotokoll verwendet, das Erweiterungen der Vorsatzanforderung ohne Verletzung des Übertragungsprotokolls ermöglicht, wobei das Verfahren auf der Clientseite die folgenden Schritte umfasst: Erzeugen einer Vorsatzanforderung (10), Einfügen von Client-Berechtigungsüberprüfungsdaten in die Vorsatzanforderung, was zu einer erweiterten Vorsatzanforderung (20) führt, unabhängig von dem vom Server verwendeten Berechtigungsüberprüfungsprozess und ohne Anforderung von Berechtigungsüberprüfungsdaten durch den Server, wobei die Berechtigungsüberprüfungsdaten das den Namen des Client und den öffentlichen Schlüssel des Client enthaltende Client-Zertifikat sowie eine digitale Signatur umfassen, die über einen Hash-Wert der das Client-Zertifikat enthaltenden Vorsatzanforderung unter Verwendung des privaten Schlüssels des Client erzeugt wurde, Übertragen der erweiterten Vorsatzanforderung an einen Server (30), und Empfangen von Daten vom Server, falls die Berechtigungsüberprüfung erfolgreich war (35, 60).
Verfahren nach Anspruch 1, wobei das Übertragungsprotokoll ein HTTP-Protokoll ist.
Verfahren nach Anspruch 1, wobei die Berechtigungsüberprüfungsdaten in der ersten Vorsatzanforderung zur Einrichtung einer Sitzung mit dem Server enthalten sind.
Verfahren nach Anspruch 1, wobei die Berechtigungsüberprüfungsdaten vom Browser des Client automatisch in die Vorsatzanforderung eingefügt werden.
Verfahren nach Anspruch 4, wobei der Client-Browser die Berechtigungsüberprüfungsdaten über ein Chipkartenlesegerät von einer Chipkarte (10) empfangt.
Verfahren nach Anspruch 1, wobei die Berechtigungsüberprüfungsdaten von einer Client-Signaturkomponente (20), die die Berechtigungsüberprüfungsdaten über ein Chipkartenlesegerät von einer Chipkarte (10) empfängt, automatisch in die Vorsatzanforderung eingefügt werden.
Verfahren zur Berechtigungsüberprüfung von Clients (1a, 1b) in einer Client-Server-Umgebung, wobei die Client-Server-Umgebung ein Übertragungsprotokoll verwendet, das Erweiterungen der Vorsatzanforderung ohne Verletzung des Übertragungsprotokolls ermöglicht, wobei ein System (22) einen Datenaustausch zwischen dem Client (1a, 1b) und dem Server (3) einrichtet, wobei das Verfahren im System die folgenden Schritte umfasst: Empfangen einer Vorsatzanforderung vom Client (1a, 1b), Einfügen von Berechtigungsüberprüfungsdaten in die Vorsatzanforderung, was zu einer erweiterten Vorsatzanforderung (20) führt, unabhängig von dem vom Server verwendeten Berechtigungsüberprüfungsprozess und ohne Anforderung von Berechtigungsüberprüfungsdaten durch den Server, wobei die Berechtigungsüberprüfungsdaten das den Namen des Client und den öffentlichen Schlüssel des Client enthaltende Client-Zertifikat sowie eine digitale Signatur umfassen, die über die gesamte das Client-Zertifikat enthaltende Vorsatzanforderung unter Verwendung des privaten Schlüssels des Client erzeugt wurde, Übertragen der erweiterten Vorsatzanforderung an einen Server (30), und Empfangen von Daten vom Server (3), falls die Berechtigungsüberprüfung erfolgreich war.
Verfahren nach Anspruch 7, wobei das System (20) ein Proxy-Server oder ein Gateway sein kann.
Verfahren nach Anspruch 7, wobei das Übertragungsprotokoll das HTTP-Protokoll ist und die Berechtigungsüberprüfungsdaten von einer Einfügungskomponente (20), die die Berechtigungsüberprüfungsdaten von einer Signaturkomponente (24) empfängt, automatisch in den HTTP-Anforderungsvorsatz eingefügt werden.
Verfahren zur Berechtigungsüberprüfung von Clients in einer Client-Server-Umgebung, wobei die Client-Server-Umgebung ein Übertragungsprotokoll verwendet, das Erweiterungen der Vorsatzanforderung ohne Verletzung des Übertragungsprotokolls ermöglicht, wobei das Verfahren auf der Serverseite die folgenden Schritte umfasst: Empfangen einer Berechtigungsüberprüfungsdaten enthaltenden Client-Vorsatzanforderung, wobei die Berechtigungsüberprüfungsdaten das den Namen des Client und den öffentlichen Schlüssel des Client enthaltende Client-Zertifikat sowie eine digitale Signatur umfassen, die über die gesamte das Client-Zertifikat enthaltende Vorsatzanforderung unter Verwendung des privaten Schlüssels des Client erzeugt wurde, Überprüfen der in der Vorsatzanforderung enthaltenen Berechtigungsüberprüfungsdaten durch die Server-Berechtigungsüberprüfungskomponente, und Übertragen von Daten an den Client, wenn die Berechtigungsüberprüfung erfolgreich war.
Verfahren nach Anspruch 10, wobei das Übertragungsprotokoll das HTTP-Protokoll ist und die Berechtigungsüberprüfungskomponente die folgenden Schritte ausführt: Zugreifen auf den im Client-Zertifikat enthaltenen öffentlichen Schlüssel, Entschlüsseln der im HTTP-Anforderungsvorsatz enthaltenen digitalen Signatur mit dem öffentlichen Schlüssel, woraus sich ein Hash-Wert ergibt, Anwenden desselben Hash-Algorithmus, wie er vom Client verwendet wurde, auf den HTTP-Anforderungsvorsatz, und Betrachten der Berechtigungsüberprüfung als erfolgreich, wenn beide Hash-Werte übereinstimmen.
Serversystem (3) zur Berechtigungsüberprüfung von Clients (1) in einer Client-Server-Umgebung, wobei die Client-Server-Umgebung ein Übertragungsprotokoll verwendet, das Erweiterungen der Vorsatzanforderung ohne Verletzung des Übertragungsprotokolls ermöglicht, wobei der Client (1) Berechtigungsüberprüfungsdaten in der Vorsatzanforderung an das Serversystem überträgt, wobei das Serversystem (3) Folgendes umfasst: eine Berechtigungsüberprüfungskomponente (4) mit der Funktionalität zum Lesen der in der eingehenden Client-Vorsatzanforderung enthaltenen Berechtigungsüberprüfungsdaten, wobei die Berechtigungsüberprüfungsdaten das den Namen des Client und den öffentlichen Schlüssel des Client enthaltende Client-Zertifikat sowie eine digitale Signatur umfassen, die über die gesamte das Client-Zertifikat enthaltende Vorsatzanforderung unter Verwendung des privaten Schlüssels des Client erzeugt wurde, und zum Überprüfen der Berechtigungsüberprüfungsdaten, ohne dass die Berechtigungsüberprüfungsdaten vom Client angefordert wurden.
Clientsystem (1), dessen Identität von einem Serversystem in einer Client-Server-Umgebung überprüft werden muss, wobei die Client-Server-Umgebung ein Übertragungsprotokoll verwendet, das Erweiterungen der Vorsatzanforderung ohne Verletzung des Übertragungsprotokolls ermöglicht, wobei das Clientsystem Folgendes umfasst: einen Browser (2), und eine Komponente zum Einfügen von Client-Berechtigungsüberprüfungsdaten in die Vorsatzanforderung unabhängig von dem vom Server verwendeten Berechtigungsüberprüfungsprozess und ohne Anforderung von Berechtigungsüberprüfungsdaten durch den Server, wobei die Berechtigungsüberprüfungsdaten das den Namen des Client und den öffentlichen Schlüssel des Client enthaltende Client-Zertifikat sowie eine digitale Signatur umfassen, die über den Hash-Wert des Vorsatzanforderungsinhaltes unter Verwendung des privaten Schlüssels des Client erzeugt wurde.
Clientsystem nach Anspruch 13, das außerdem Folgendes umfasst: ein Chipkartenlesegerät (10), und eine Chipkarte (10) mit einem Sicherheitsmodul, das den privaten Schlüssel des Client sowie ein den Namen und den privaten Schlüssel des Client enthaltendes Client-Zertifikat enthält, wobei die Chipkarte das Zertifikat zusammen mit einer digitalen Signatur an die Einfügungskomponente überträgt, wobei die digitale Signatur das Ergebnis einer Verschlüsselung eines Hash-Wertes der die Zertifikatdaten enthaltenden Vorsatzanforderung mittels des privaten Schlüssels ist.
Proxy-Serversystem (22) zum Übertragen von Client-Berechtigungsüberprüfungsdaten an ein Server-System (3), wobei das Proxy-Serversystem (22) eine Datenübertragungsverbindung mit einem Clientsystem (1a, 1b) und einem Serversystem (3) aufweist, wobei das zwischen den Systemen verwendete Übertragungsprotokoll Erweiterungen der Vorsatzanforderung ohne Verletzung des Übertragungsprotokolls ermöglicht, wobei das Proxy-Serversystem (22) Folgendes umfasst: eine Proxy-Einfügungskomponente (20) zum Einfügen des Client-Zertifikats und einer digitalen Signatur in die vom Client empfangene Vorsatzanforderung unabhängig von dem vom Server verwendeten Berechtigungsüberprüfungsprozess und ohne Anforderung von Berechtigungsüberprüfungsdaten durch den Server, und eine Signaturkomponente (24) zum Erzeugen einer digitalen Signatur und zum Übertragen derselben zusammen mit dem Client-Zertifikat an die Proxy-Einfügungskomponente (20).
Im internen Speicher eines digitalen Computers gespeichertes Computerprogrammprodukt, das Teile eines Softwarecodes zum Ausführen des Verfahrens nach irgendeinem der Ansprüche 1 bis 11 enthält, wenn das Produkt im Computer ausgeführt wird.