DE60308692T2

DE60308692T2 - Verfahren und system für benutzerbestimmte authentifizierung und einmalige anmeldung in einer föderalisierten umgebung

Info

Publication number: DE60308692T2
Application number: DE60308692T
Authority: DE
Inventors: Maria Heather Austin HINTON
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2002-06-28
Filing date: 2003-06-24
Publication date: 2007-08-16
Anticipated expiration: 2023-06-25
Also published as: CN1653781B; EP1530860B1; DE60308692D1; CN1653781A; JP2005538434A; KR100800339B1; EP1530860A1; AU2003238031A1; US20040002878A1; ATE341146T1; CA2488881A1; WO2004004273A1; BR0312228A; KR20050013559A

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Die vorliegende Erfindung betrifft ein verbessertes Datenverarbeitungssystem und insbesondere ein Verfahren und eine Vorrichtung zur Datenübertragung zwischen mehreren Computern. Ganz besonders stellt die vorliegende Erfindung ein Verfahren und eine Vorrichtung zur Authentifizierung zwischen Computernbereit.
2. Beschreibung der zugrunde liegenden Technik
Informationstechnologiesysteme (IT-Systeme) und das Internet haben zum Wachstum der heutigen Weltwirtschaft beigetragen. IT-Systeme weisen zwar bedeutende Vorteile auf, können aber durch nicht autorisierte Dritte angegriffen werden. Die mangelhafte Sicherheit in modernen IT-Systemen hat sich tatsächlich zu einer Bedrohung der Integrität globaler Computernetze entwickelt. Um diesem Problem zu begegnen, bieten IT-Systeme eine Reihe von bekannten Diensten: Datenauthentifizierung, Datenvertraulichkeit, Entitätenauthentifizierung, Autorisierung usw.
Die Authentifizierung und die Autorisierung können auf viele Arten erfolgen und Unternehmen können möglicherweise verlangen, dass autorisierten Benutzern von verschiedenen Standorten aus auf benutzerfreundliche Weise der sichere Zugriff auf geschützte Ressourcen gewährt wird. Obwohl durch die Bereitstellung sicherer Authentifizierungsmechanismen die Gefahren des unbefugten Zugriffs auf geschützte Ressourcen verringert werden, können dieselben Authentifizierungsmechanismen die Interaktion der Benutzer mit den geschützten Ressourcen behindern. Benutzer möchten im Allgemeinen gern von einer Anwendung zu einer anderen Anwendung springen können, ohne auf die Authentifizierungsschranken Rücksicht nehmen zu müssen, die das jeweilige diese Anwendungen unterstützende System schützen.
Da Benutzer immer anspruchsvoller werden, erwarten sie von den Computersystemen, dass diese ihre Aktionen koordinieren und so den Aufwand für den Benutzer verringern. Derartige Erwartungen treffen auch auf die Authentifizierungsprozesse zu. Ein Benutzer könnte möglicherweise davon ausgehen, dass, nachdem er oder sie einmal durch ein Computersystem authentifiziert worden ist, diese Authentifizierung während der gesamten Arbeitssitzung des Benutzers oder zumindest für eine bestimmte Zeitspanne gültig bleibt, ungeachtet der Grenzen der verschiedenen Computerarchitekturen, die dem Benutzer nahezu verborgen bleiben. Unternehmen versuchen im Allgemeinen, diesen Erwartungen an die Betriebseigenschaften ihrer implementierten Systeme gerecht zu werden, nicht nur, um den Benutzern entgegenzukommen, sondern auch um die Benutzerproduktivität zu steigern, ob in Form der Produktivität der Angestellten oder der Kundenzufriedenheit.
Insbesondere bei der heutigen IT-Umgebung, bei der viele Anwendungen über eine webbasierte Benutzerschnittstelle verfügen, die über einen gewöhnlichen Browser zugänglich ist, erwarten die Benutzer eine höhere Benutzerfreundlichkeit und niedrige oder seltenere Schranken beim Wechsel von einer webbasierten Anwendung zu einer anderen. In diesem Zusammenhang möchten Benutzer immer mehr in der Lage sein, vom Interagieren mit einer Anwendung in einer Internetdomäne, ungeachtet der Authentifizierungsschranken zum Schutz der jeweiligen Domäne, zu einer anderen Anwendung in einer anderen Domäne zu springen. Aber selbst wenn viele Systeme durch einfach zu bedienende webbasierte Schnittstellen eine sichere Authentifizierung schaffen, muss ein Benutzer möglicherweise immer noch mit zahlreichen Authentifizierungsprozessen rechnen, die den Benutzerzugriff über mehrere Domänen hinweg behindern. Die Leistung eines Benutzers kann deutlich beeinträchtigt werden, wenn er sich während einer bestimmten Zeit mehreren Authentifizierungsprozesse unterziehen muss.
Da sich immer mehr Organisationen an föderierten (zusammengeschlossenen) Computerumgebungen beteiligen, werden die durch mehrfache Authentifizierungsprozesse oder -systeme gesetzten Schranken zunehmend üblich. In einer föderierten Umgebung kann ein Benutzer, der ein registriertes Mitglied einer Organisation ist, auf eine ferne Ressource zugreifen, die durch eine andere Organisation kontrolliert wird. In einer föderierten Umgebung ist jede Organisation für die Verwaltung ihrer eigenen registrierten Benutzer und Ressourcen zuständig, jedoch arbeiten die Computersysteme der zusammengeschlossenen Organisationen auf bestimmte Weise zusammen, um ihre Ressourcen den registrierten Mitgliedern der Organisationen gemeinsam zur Verfügung zu stellen.
Beispielsweise ist jeder Benutzer in einer eigenen „Ursprungsdomäne" (Home Domain) registriert, die einem Benutzer bestimmte Grunddienste zur Verfügung stellt. Ein Benutzer meldet sich üblicherweise mittels eines bestimmten Authentifizierungsprozesses bei seiner Ursprungsdomäne an und darf dann auf die geschützten Ressourcen zugreifen, welche die Ursprungsdomäne gemäß den vorher für den Benutzer definierten Authentifizierungsattributen unterstützt. Auf diese Weise unterhält der Benutzer eine Dauerbeziehung zu seiner Ursprungsdomäne. Außerdem kann die Ursprungsdomäne eine Dauerbeziehung zu vielen anderen Domänen in einer als „Föderation" (Zusammenschluss) oder als „föderierte Umgebung" bezeichneten Umgebung unterhalten, die mitunter auch als B2B(Business-to-Business, Unternehmen-zu-Unternehmen) oder als E-Community-Domäne bezeichnet wird.
Es sind Lösungen zur Verringerung der Schranken vorgeschlagen worden, die durch mehrfache Authentifizierungsprozesse oder -systeme in föderierten Umgebungen entstehen. In der EP-Anmeldung 01/12361, eingereicht am 09. November 2000, mit dem Titel „Method and system for Web-based cross-domain single-signon authentication" wurde ein Ansatz mit der Bezeichnung „crossdomain single-sign-on" (Domänenüberschreitung mit einmaliger Anmeldung) beschrieben, bei dem ein Benutzer von einer Ursprungsdomäne zu einer beteiligten Sicherheitsdomäne wechseln kann, ohne sich bei der zweiten Domäne erneut authentifizieren lassen zu müssen. Ein Nachteil des beschriebenen Ansatzes besteht darin, dass ein Benutzer nur von der eigenen Ursprungsdomäne direkt zu einer beteiligten Domäne wechseln kann. In der US-Patentanmeldung 10/034725, eingereicht am 19. Dezember 2001, mit dem Titel „System and method for user enrollment in an e-community" wurde ein Ansatz beschrieben, bei dem ein Benutzer durch ein „domain identity cookie" (Domänen-ID-Cookie) eine Dauerbeziehung zu einer beteiligten Domäne herstellen kann. Über diesen Ansatz ist der Benutzer in der Lage, direkt zu dieser Domäne zu wechseln, z. B. durch Lesezeichen oder direkte URLs (Uniform Resource Locators, Internetadressen), ohne vorher über die eigene Ursprungsdomäne gehen zu müssen. Dieser flexible Ansatz ermöglicht eine einfachere Funktionalität für den Benutzer, bei der er von den Implementierungsdetails der E-Community, an der er sich beteiligt, keine Kenntnis haben muss. Dieser Ansatz lässt sich leicht in die Praxis umsetzen, ist einfach anzuwenden und liefert ein sicheres Verfahren für eine domänenübergreifende Funktionalität mit einmaliger Anmeldung.
Die Schwierigkeit bei diesen beiden Ansätzen besteht darin, dass ein Benutzer eine und nur eine zur Authentifizierung des Benutzers fähige Domäne hat und dass jede durch den Benutzer aufgesuchte Domäne zuvor über Kenntnisse der Ursprungsdomäne verfügen und dieser vertrauen muss.
Die Internationale Patentanmeldung WO 02/14974 A2 mit dem Titel „Multi-Server Authentication" schafft ein Verfahren zur Transaktionsauthentifizierung, welches das Empfangen von Transaktionsinformationen umfasst (die wiederum Folgendes umfassen: eine Karten-ID, einen Code und einen Zähler an einem ersten Standort), das selektive Übertragen der Informationen an mindestens einen aus einer Vielzahl von Authentifizierungs-Servern, das Anwenden einer Hashfunktion auf die Informationen und das Vergleichen der gehashten Informationen mit einer Hashdatenbank von gültigen Informationen auf einem aus der Vielzahl von Authentifizierungsservern.
Das Verfahren ermöglicht die Authentifizierung von Client-Transaktionen in einem einzigen Empfänger aus einer Vielzahl von Authentifizierungsservern. Der zur Authentifizierung verwendete Authentifizierungsserver kann durch verschiedene Ausführungsarten ausgewählt werden, zum Beispiel anhand des Inhalts einer Webseite des Clients. Die Authentifizierung selbst erfolgt jedoch für jede Transaktion anhand der Informationen einer Karte, die zum Browser des Clients gesendet werden.
Deshalb wären ein Verfahren und ein System von Vorteil, bei denen die Benutzerauthentifizierung überall in einem verteilten System für jede Sicherheitsdomäne ohne Authentifizierungsschranke erfolgen könnte. Mit anderen Worten, es wäre eine domänenübergreifende Authentifizierung mit einmaliger Anmeldung von Vorteil, bei der sich ein Benutzer zunächst bei einer Sicherheitsdomäne authentifizieren lassen und dann zu einer anderen Sicherheitsdomäne wechseln kann, ohne sich bei der zweiten Domäne erneut authentifizieren lassen zu müssen. Insbesondere wäre die Anwendung offener Standards in einem Ansatz von Vorteil, der vollständig auf der legitimen Anwendung dieser offenen Standards basiert.
ÜBERBLICK ÜBER DIE ERFINDUNG
Es werden ein Verfahren, eine Vorrichtung, ein System oder ein Computerprogrammprodukt für eine domänenübergreifende Authentifizierungsfunktionalität mit einmaliger Anmeldung dargelegt. Ein E-Commerce-Serviceanbieter empfängt von einem Client eine Anforderung für den Zugriff auf eine kontrollierte Ressource, und der E-Commerce-Serviceanbieter gestattet die Angabe eines aus einer Vielzahl durch den E-Commerce-Serviceanbieter zu nutzender Authentifizierungs-Serviceanbieter, um den Zugriff des Clients auf die kontrollierte Ressource zu entscheiden. Der E-Commerce-Serviceanbieter kann eine Angabe eines Authentifizierungs-Serviceanbieters zusammen mit der Anforderung für den Zugriff auf die kontrollierte Ressource z. B. in Form eines Cookies empfangen. Alternativ kann der E-Commerce-Serviceanbieter die Benutzerauswahl eines aus der Vielzahl von Authentifizierungs-Serviceanbietern vorsehen, wenn zusammen mit der Anforderung für den Zugriff auf die kontrollierte Ressource keine Angabe über den Authentifizierungs-Serviceanbieter empfangen wurde. Der E-Commerce-Serviceanbieter kann auch die Benutzerauswahl vorsehen, einen aus der Vielzahl der Serviceanbieter vom Benutzer ausgewählten Authentifizierungs-Serviceanbieter dauerhaft dem Benutzer zuzuweisen. Der E-Commerce-Serviceanbieter sendet eine Authentifizierungsanforderung von sich an den angegebenen Authentifizierungs-Serviceanbieter und entscheidet dann anhand einer von dem angegebenen Authentifizierungs-Serviceanbieter empfangenen Authentifizierungsantwort, ob er den Zugriff auf die kontrollierte Ressource gestattet.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die für die Erfindung als charakteristisch angesehenen neuartigen Merkmale sind in den beigefügten Ansprüchen dargelegt. Die Erfindung selbst sowie weitere ihrer Ziele und Vorteile lassen sich am besten aus der folgenden detaillierten Beschreibung in Verbindung mit den beiliegenden Zeichnungen verstehen, wobei:
1A ein typisches Netz von Datenverarbeitungssystemen zeigt, von denen jedes die vorliegende Erfindung implementieren kann;
1B eine typische Computerarchitektur zeigt, die in einem Datenverarbeitungssystem mit der darin implementierten vorliegenden Erfindung genutzt werden kann;
1C eine webbasierte Umgebung veranschaulicht, in der die vorliegende Erfindung implementiert werden kann;
1D ein Datenflussdiagramm zur Veranschaulichung eines Prozesses nach dem Stand der Technik ist, der verwendet werden kann, wenn ein Client auf eine geschützte Ressource zuzugreifen versucht;
2 ein Blockdiagramm ist, das eine föderierte Umgebung darstellt, in der die vorliegende Erfindung implementiert werden kann;
3 ein Flussdiagramm zur Darstellung eines Prozesses ist, durch den ein E-Commerce-Serviceanbieter von einem durch den Benutzer angegebenen Authentifizierungs-Serviceanbieter eine authentifizierte Identität für einen Benutzer abzurufen versucht, der bei dem E-Commerce-Serviceanbieter auf eine kontrollierte Ressource zugreifen will;
4 ein Flussdiagramm zur Darstellung eines Prozesses ist, durch den ein Authentifizierungsserver ermittelt, ob er einem Benutzer auf Anforderung eines E-Commerce-Serviceanbieters eine Bestätigung erteilen kann;
5 ein Flussdiagramm zur Darstellung eines Prozesses ist, durch den ein E-Commerce-Serviceanbieter einem Benutzer die Auswahl eines Authentifizierungs-Serviceanbieters und/oder entsprechender Optionen ermöglicht; und
6 ein Fenster einer grafischen Benutzeroberfläche ist, welches die einem Benutzer zur Verfügung stehenden Auswahlmöglichkeiten zur Auswahl eines Authentifizierungs-Serviceanbieters in Verbindung mit einer einmaligen Anmeldeoperation in einer föderierten Umgebung zeigt.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Allgemein beinhalten die Vorrichtungen, welche die vorliegende Erfindung umfassen oder sich darauf beziehen können, eine große Vielfalt an Datenverarbeitungstechnologien. Deshalb wird vor der genaueren Beschreibung der vorliegenden Erfindung als Hintergrund eine typische Organisation von Hardware- und Softwarekomponenten in einem verteilten Datenverarbeitungssystem beschrieben.
1A zeigt ein typisches Netz von Datenverarbeitungssystemen, von denen jedes die vorliegende Erfindung implementieren kann. Das verteilte Datenverarbeitungssystem 100 enthält ein Netz 101, das als Medium für Datenübertragungsverbindungen zwischen verschiedenen miteinander verbundenen Einheiten und Computern im verteilten Datenverarbeitungssystem 100 dienen kann. Das Netz 101 kann ständige Verbindungen, zum Beispiel Draht- oder Lichtwellenleiterkabel, oder zeitweilige Verbindungen über Telefon oder drahtlose Kommunikation beinhalten. Bei dem dargestellten Beispiel sind ein Server 102 und ein Server 103 sowie eine Speichereinheit 104 mit dem Netz 101 verbunden. Außerdem sind die Clients 105 bis 107 mit dem Netz 101 verbunden. Die Clients 105 bis 107 und die Server 102 bis 103 können durch eine Vielzahl von Datenverarbeitungsgeräten dargestellt werden, zum Beispiel Großrechner, Personal Computer (PCs), Personal Digital Assistents (PDAs) usw. Das verteilte Datenverarbeitungssystem 100 kann weitere Server, Clients, Router, andere Einheiten und Peer-to-Peer-Architekturen beinhalten, die nicht dargestellt sind.
Bei dem gezeigten Beispiel kann das verteilte Datenverarbeitungssystem 100 das Internet beinhalten, wobei das Netz 101 eine weltweite Sammlung von Netzen und Gateways darstellt, die verschiedene Protokolle verwenden, zum Beispiel LDAP, TCP/IP, HTTP usw., um miteinander zu kommunizieren. Das verteilte Datenverarbeitungssystem 100 kann natürlich auch eine Anzahl verschiedener Arten von Netzen beinhalten, zum Beispiel ein Intranet, ein lokales Netz (Local Area Network, LAN) oder ein Weitverkehrsnetz (Wide Area Network, WAN). Der Server 102 unterstützt beispielsweise direkt den Client 109 und das Netz 110, das drahtlose Kommunikationsverbindungen umfasst. Das netzfähige Telefon 111 ist über eine drahtlose Verbindung 112 und der PDA 113 über eine drahtlose Verbindung 114 mit dem Netz 110 verbunden. Das Telefon 111 und der PDA 113 können auch untereinander Daten direkt über eine drahtlose Verbindung 115 mittels einer geeigneten Technologie übertragen, zum Beispiel mit der drahtlosen Bluetooth^TM-Technologie, und so genannte persönliche Netze oder persönliche Ad-hoc-Netze zu schaffen. Auf ähnliche Weise kann auch der PDA 113 Daten über die drahtlose Kommunikationsverbindung 116 an den PDA 107 übertragen.
Die vorliegende Erfindung kann auf einer Vielfalt von Hardwareplattformen und Softwareumgebungen implementiert werden. 1A dient als Beispiel für eine heterogene Computerumgebung und ist nicht als Beschränkung der Architektur der vorliegenden Erfindung zu verstehen.
1B zeigt die Darstellung einer typischen Computerarchitektur eines Datenverarbeitungssystems, zum Beispiel des in 1A gezeigten Datenverarbeitungssystems, in dem die vorliegende Erfindung implementiert sein kann. Das Datenverarbeitungssystem 120 enthält eine oder mehrere Zentraleinheiten (Central Processing Units, CPUs) 122, die mit einem internen Systembus 123 verbunden sind, das einen Arbeitsspeicher (Random Access Memory, RAM) 124, einen Nur-Lese-Speicher (Read Only Memory, ROM) 126 und einen Ein-/Ausgabe-Adapter 128 zur Unterstützung verschiedener E/A-Einheiten, beispielsweise eines Druckers 130, Platteneinheiten 132 oder anderer nicht gezeigter Einheiten, zum Beispiel eines Audioausgabesystems usw. zeigt. Der Systembus 123 ist auch mit einem Kommunikationsadapter 134 verbunden, der den Zugriff auf eine Kommunikationsverbindung 136 ermöglicht. Der Benutzerschnittstellenadapter 148 stellt die Verbindung zu verschiedenen Peripherieeinheiten, zum Beispiel einer Tastatur 140 und einer Maus 142 oder anderen nicht gezeigten Einheiten, zum Beispiel zu einem Touchscreen (Tastbildschirm), einem Stift, einem Mikrofon usw. her. Der Bildschirmadapter 144 stellt eine Verbindung zwischen dem Systembus 123 und dem Bildschirm 146 her.
Dem Fachmann wird klar sein, dass die in 1B dargestellte Hardware entsprechend der Systemimplementierung variieren kann. Zum Beispiel kann das System einen oder mehrere Prozessoren, wie einen Intel^® Pentium^®-basierten Prozessor und einen digitalen Signalprozessor (Digital Signal Processor, DSP), und eine oder mehrere Arten von flüchtigen und nicht flüchtigen Speichern beinhalten. Zusätzlich zu oder anstelle der in 1B dargestellten Hardware können weitere Peripherieeinheiten verwendet werden. Die gezeigten Beispiele sind im Hinblick auf die vorliegende Erfindung nicht als Beschränkung der Architektur zu verstehen.
Die vorliegende Erfindung kann sowohl auf einer Vielfalt von Hardwareplattformen als auch in einer Vielfalt von Softwareumgebungen implementiert werden. Zur Steuerung der Programmausführung in jedem Datenverarbeitungssystem kann ein typisches Betriebssystem verwendet werden. Zum Beispiel kann eine Einheit auf einem Unix^®-Betriebssystem laufen, während eine andere Einheit eine einfache Java^®-Laufzeitumgebung enthält. Eine typische Computerplattform kann einen Browser beinhalten, eine wohlbekannte Softwareanwendung für den Zugriff auf Hypertextdokumente in einer Vielfalt von Formaten, zum Beispiel Grafikdateien, Textverarbeitungsdateien, XML (Extensible Markup Language), HTML (Hypertext Markup Language), HDML (Handheld Device Markup Language), WML (Wireless Markup Language) und verschiedenen anderen Formaten und Dateiarten. Zudem ist noch anzumerken, dass das in 1A gezeigte verteilte Datenverarbeitungssystem komplett in der Lage sein soll, eine Vielfalt von Peer-to-Peer-Teilnetzen und Peer-to-Peer-Services zu unterstützen.
1C zeigt eine Netzdarstellung einer spezielleren und dennoch generischen webbasierten Umgebung, in der die vorliegende Erfindung implementiert werden kann. In dieser Umgebung verlangt ein Benutzer eines Browsers 152 am Client 150, auf eine geschützte Ressource auf dem Webanwendungsserver 154 in der DNS-Domäne 156 oder auf dem Webanwendungsserver 158 in der DNS-Domäne 160 zuzugreifen. Unter einer geschützten Ressource ist eine Ressource (eine Anwendung, ein Objekt, ein Dokument, eine Seite, eine Datei, ein ausführbarer Code oder eine andere Computer- oder Datenübertragungsressource usw.) zu verstehen, auf die nur dann zugegriffen oder die nur dann abgerufen werden kann, wenn der Browser des anfordernden Clients sowohl authentifiziert als auch autorisiert ist. Zu jeder DNS-Domäne kann ein entsprechender Authentifizierungsserver 162 gehören. Üblicherweise kann in einem Cookie-Cachespeicher des Browsers ein Cookie gesetzt und gespeichert werden, sobald der Benutzer durch den Authentifizierungsserver authentifiziert worden ist. Der anfordernde Client kann eine Anforderung nach einer geschützten Ressource innerhalb einer Domäne oder zwischen verschiedenen Domänen stellen. Unter einer Anforderung innerhalb einer Domäne (intra-domain) ist zu verstehen, dass sich die Zielressource auf demselben Server befindet, der die Authentifizierung durchführt. Unter einer Anforderung zwischen verschiedenen Domänen (inter-domain) ist zu verstehen, dass sich die Zielressource innerhalb derselben Internetdomäne, aber auf einem anderen Server als dem Authentifizierungs-Server befindet, der die Authentifizierung durchgeführt hat. Unter einer domänenübergreifenden (cross-domain) Anforderung ist zu verstehen, dass der Benutzer auf eine geschützte Ressource zugreifen möchte, die sich außerhalb der gerade vom Benutzer genutzten DNS-Domäne befindet.
1D zeigt ein Datenflussdiagramm eines Prozesses nach dem Stand der Technik, das verwendet werden kann, wenn ein Client auf eine geschützte Ressource zuzugreifen versucht. Wie die Figur zeigt, versucht der Benutzer einer Client-Workstation 170 mittels seines auf der Client-Workstation laufenden Web-Browsers über ein Computernetz auf eine geschützte Ressource auf einem Server 172 zuzugreifen. Eine geschützte Ressource ist wie erwähnt durch eine Internetadresse (URL) gekennzeichnet, genauer gesagt, durch eine einheitliche Referenz-ID (Uniform Resource Identifier, URI), auf die nur ein authentifizierter und autorisierter Benutzer zugreifen kann. Als Computernetz kommen das Internet, ein Intranet oder ein anderes Netz gemäß 1A und 1B, und als Server ein Webanwendungsserver (WAS), eine Serveranwendung, ein Servlet-Prozess oder Ähnliches in Frage.
Der Prozess wird eingeleitet, wenn der Benutzer die geschützte Ressource anfordert, zum Beispiel eine Webseite in der Domäne „ibm.com" (Schritt 174). Der Webbrowser (oder eine entsprechende Anwendung oder ein Applet) erzeugt eine HTTP-Anforderung, die er an den Webserver sendet, auf dem die Domäne „ibm.com" betrieben wird (Schritt 176). Der Server stellt fest, dass es für den Client noch keine aktive Sitzung gibt (Schritt 178), daher fordert der Server den Benutzer zur Durchführung eines Authentifizierungsprozesses auf, indem er eine Art von Authentifizierungsaufforderung an den Client sendet (Schritt 180). Die Authentifizierungsaufforderung kann durch verschiedene Masken erfolgen, zum Beispiel durch eine HTML-Maske, in die der Benutzer geforderte Informationen wie beispielsweise eine Benutzer-ID und ein zugehöriges Passwort eingeben muss.
Die Antwort in Form der Authentifizierungsinformationen in der HTML-Maske wird an den Server gesendet (Schritt 184), wonach der Server die Authentizität des Benutzers durch Abrufen zuvor übermittelter Registrierungsdaten und Vergleichen der vorliegenden Authentifizierungsinformationen mit den für den Benutzer gespeicherten Informationen ermittelt. Sollte die Authentifizierung erfolgreich verlaufen, wird dem authentifizierten Benutzer eine SSL-Sitzung (Secure Socket Layer) mit einer eindeutigen Sitzungskennung (Sitzungs-ID) zugewiesen (Schritt 186).
Obwohl 1D einen typischen Prozess nach dem Stand der Technik darstellt, ist anzumerken, dass an dieser Stelle andere alternative Verfahren zur Verwaltung des Sitzungsstatus dargestellt werden können, zum Beispiel die Verwendung von Cookies zur Erkennung von Benutzern mit aktiven Sitzungen, wobei als Cookie möglicherweise dasselbe Cookie verwendet werden kann, das zur Authentifizierung verwendet wird.
Nun ruft der Server die angeforderte Webseite ab und sendet eine HTTP-Antwort an den Client (Schritt 188). In diesem Augenblick kann der Benutzer im Browser durch Anklicken eines Hypertext-Links eine andere Seite in der Domäne „ibm.com" anfordern (Schritt 190), woraufhin der Browser eine weitere HTTP-Anforderung an den Server sendet (Schritt 192). Zu diesem Zeitpunkt erkennt der Server, dass es für den Benutzer bereits eine aktive Sitzung gibt (Schritt 194), und sendet die angeforderte Webseite in einer weiteren HTTP-Antwort an den Client zurück (Schritt 196).
Wie oben erwähnt, kann die vorliegende Erfindung in einer Vielfalt von Netzen und Hardwareplattformen verwendet werden. Insbesondere stellt die vorliegende Erfindung jedoch eine Methodik bereit, durch die ein Benutzer beim Zugreifen auf geschützte Ressourcen innerhalb mehrerer miteinander verbundener Domänen nicht zur Authentifizierung aufgefordert wird. Dadurch kann sich der Benutzer zu einem bestimmten Grad frei zwischen Domänen bewegen, die an einem domänenübergreifenden Zusammenschluss oder einer Anordnung mit einmaliger Anmeldung beteiligt sind. Zum Beispiel kann ein großes Extranet über mehrere Domänen verfügen, denen jeweils eine eigene Gruppe von Benutzern und geschützten Ressourcen zugeordnet ist. Die geschützten Ressourcen können jedoch dem ganzen Unternehmen gemeinsam zugeordnet sein und es kann zu beträchtlichen Überlappungen zwischen den Benutzergruppen kommen. Ein Benutzer kann an Leistung oder Produktivität hinzugewinnen, wenn er beim Aufsuchen der einzelnen Domänen nicht mehrere Authentifizierungsaufforderungen durchlaufen muss. Somit versucht die vorliegende Erfindung, die Schranken, die der freien Bewegung durch die Websites entgegenstehen, zu beseitigen.
Insbesondere besteht, wie oben erwähnt, die Schwierigkeit bei einigen früheren Ansätzen zur verteilten Authentifizierung darin, dass diese Ansätze voraussetzten, dass ein Benutzer eine und nur eine Domäne hat, die in der Lage ist, den Benutzer zu authentifizieren, und jede vom Benutzer aufgesuchte Domäne zuvor über Kenntnisse von der Ursprungsdomäne verfügen und dieser vertrauen muss. Die vorliegende Erfindung hingegen gestattet einem Benutzer, Vereinbarungen mit einem oder mehreren Authentifizierungs-Serviceanbietern (Authentication Service Provider, ANSP) zu treffen. Der Benutzer unterhält eine Beziehung zu diesen ANSPs und lässt sich bei einem Authentifizierungs-Serviceanbieter authentifizieren. E-Commerce-Serviceanbieter (ECSPs), zum Beispiel Onlinebanken oder Onlinehändler, unterhalten ebenfalls eine Beziehung zu einem ASNP, sodass der E-Commerce-Serviceanbieter der im Auftrag des Benutzers vom ANSP bereitgestellten authentifizierten Identität eines Benutzers vertrauen kann. Der Benutzer kann jeden E-Commerce-Serviceanbieter aufsuchen, ohne vorher eine Beziehung zu einem bestimmten E-Commerce-Serviceanbieter hergestellt haben zu müssen. Solange die Domäne des E-Commerce-Serviceanbieters eine Beziehung zu mindestens einem der Authentifizierungs-Serviceanbieter des Benutzers unterhält, braucht sich der Benutzer lediglich einmal bei diesem E-Commerce-Serviceanbieter anzumelden.
Die vorliegende Erfindung erweitert den in der eingereichten (TBD) US-Patentanmeldung (Attorney Docket No. AUS920010769US1) mit dem Titel „System and method for user enrollment in an e-community" beschriebenen Anmeldeprozess dahingehend, dass ein Benutzer seine Anmeldung bei einer Site selbst anpassen kann. Mit anderen Worten, der Benutzer kann sich entscheiden, für die „Anmeldung" bei einer Site dieser den Standort eines vertrauenswürdigen Dritten mitzuteilen, der die authentifizierte Identität des Benutzers bestätigen kann. Dieser Prozess kann dazu führen, dass ein Domänen-ID-Cookie gesetzt wird, was in der US-Patentanmeldung (Attorney Docket No. AUS920010769US1) beschrieben wurde. Alternativ kann sich ein Benutzer gegen das Setzen eines Domänen-ID-Cookies entscheiden sodass der Benutzer bei jedem Erstzugriff auf eine bestimmte Site, genauer gesagt, bei jedem Zugriff, bei dem es für den Benutzer noch keine laufende aktive Sitzung bei dieser Site gibt, den Standort des vertrauenswürdigen Dritten angeben muss. Diese und andere Merkmale der vorliegenden Erfindung werden im Folgenden in Verbindung mit den übrigen Figuren ausführlicher beschrieben.
2 zeigt ein Blockdiagramm einer föderierten Umgebung, in der die vorliegende Erfindung implementiert werden kann. Föderierte Umgebungen wie die in 2 gezeigte umfassen Benutzer, E-Commerce-Serviceanbieter (ECSPs) und Authentifizierungs-Serviceanbieter (ANSPs). ECSPs entsprechen Wirtschaftseinheiten, die an einem Zusammenschluss beteiligt sind. ANSPs entsprechen Einheiten, bei denen sich ein Benutzer authentifizieren lässt und die dessen Authentifizierung den ECSPs gegenüber bestätigen. Innerhalb einer bestimmten E-Community können die Aufgaben des E-Commerce-Serviceanbieters und des Authentifizierungs-Serviceanbieters durch getrennte Einheiten oder durch eine einzige Einheit erfüllt werden.
Die föderierte Umgebung 200 umfasst Folgendes: einen Benutzer, der durch den Client 202 mit einer Browseranwendung 204 dargestellt ist; zwei E-Commerce-Serviceanbieter ECSP 210 und ECSP 212; und zwei Authentifizierungs-Serviceanbieter ANSP 214 und ANSP 216. Zwischen dem Benutzer und ANSP 216 besteht eine Authentifizierungsbeziehung 220. ECSP 210 unterhält eine vertrauenswürdige Beziehung 222 zu ANSP 214 und eine vertrauenswürdige Beziehung 224 zu ANSP 216. ECSP 212 unterhält eine vertrauenswürdige Beziehung 226 zu ANSP 216. Der Benutzer versucht über die Netzpfade 230 bzw. 232 auf ECSP 210 und ECSP 212 zuzugreifen.
Wie in diesem Beispiel gezeigt und im Folgenden ausführlich erläutert wird, geht die vorliegende Erfindung davon aus, dass der Benutzer vorher bereits eine Authentifizierungsbeziehung zu mindestens einem Authentifizierungs-Serviceanbieter und möglicherweise zu einer Vielzahl von Authentifizierungs-Serviceanbietern hergestellt hat, was überwiegend in einem „externen" (Out-of-Band) Prozess geschieht, durch den sich der Benutzer bei einem Authentifizierungs-Serviceanbieter registriert oder anmeldet. Ein Benutzer kann unterschiedlich strenge Authentifizierungsmaßnahmen vereinbaren, zum Beispiel Benutzername/Passwort, Chipkarte (Smart Card), biometrische Erkennung oder digitales Zertifikat; mit anderen Worten, die vorliegende Erfindung ist in der Lage, mit einer Vielfalt von zugrunde liegenden Authentifizierungsschemata zusammenzuarbeiten.
Die vorliegende Erfindung geht ferner davon aus, dass ein E-Commerce-Serviceanbieter vorher bereits eine vertrauenswürdige Beziehung zu mindestens einem Authentifizierungs-Serviceanbieter und möglicherweise zu einer Vielzahl von Authentifizierungs-Serviceanbietern hergestellt hat, was überwiegend in einem „externen" (Out-of-Band) Prozess geschieht, durch den der E-Commerce-Serviceanbieter und ein Authentifizierungs-Serviceanbieter die unterschiedlichsten Vereinbarungen zu den Pflichten jeder Seite bezüglich der Authentifizierungs- und Identitätsnachweis-Services treffen. Ein E-Commerce-Serviceanbieter kann unterschiedlich strenge Authentifizierungsmaßnahmen vereinbaren, und die vorliegende Erfindung ist in der Lage, mit einer Vielzahl von zugrunde liegenden Authentifizierungsmethoden zusammenzuarbeiten.
Zum Teil besteht der Prozess zur Herstellung einer vertrauenswürdigen Beziehung darin, dass der E-Commerce-Serviceanbieter und der Authentifizierungs-Serviceanbieter einen externen (Out-of-Band) Informationsaustausch zur Herstellung einer vertrauenswürdigen Beziehung durchführen, wozu ein gemeinsamer geheimer Schlüssel, digitale Zertifikate oder andere Arten von Informationen gehören können. Diese Informationen dienen dem Schutz der Identitätsnachweis-Informationen des Benutzers, welche der E-Commerce-Serviceanbieter während einer Benutzertransaktion dem Authentifizierungs-Serviceanbieter mitteilt. Dieser Informationsaustausch kann durch Verfahren mit öffentlichem Schlüssel abgewickelt werden, jedoch sollte, aufgrund der Beschränkungen von öffentlichen Schlüsseln und zugehörigen Zertifikaten sowie der an einen E-Commerce-Serviceanbieter gestellten Sicherheitsanforderungen hinsichtlich des Identitätsnachweises, geheimen Schlüsseln der Vorrang gegeben werden – obgleich die vorliegende Erfindung auch in einem Verfahren mit öffentlichem Schlüssel angewendet werden kann.
Anstatt eines Verfahrens mit öffentlichem Schlüssel wird bei einer bevorzugten Ausführungsart aus den folgenden Gründen ein Verfahren mit geheimem Schlüssel benutzt. Die Informationen über den Identitätsnachweis und/oder die authentifizierte Identität werden über die Clientanwendung des Benutzers, üblicherweise einen Browser, durch HTTP-Umleitungen vom Authentifizierungs-Serviceanbieter über das Internet zum E-Commerce-Serviceanbieter übertragen. In diesem Falle müssen die Informationen geschützt werden, was durch die Verschlüsselung des Tokens erfolgt, in dem die authentifizierten Identitätsinformationen und zusätzliche Informationen des Benutzers enthalten sind (zum Beispiel die Authentifizierungsverfahren, persönliche Daten usw.). Ein Verfahren mit geheimem Schlüssel ist vorzuziehen, da dieses effizienter als ein Verfahren mit öffentlichem Schlüssel ist. Wenn diese Daten beispielsweise mit dem öffentlichen Schlüssel des E-Commerce-Serviceanbieters verschlüsselt werden, gäbe es keinen Beweis, dass die Daten vom Authentifizierungs-Serviceanbieter kommen. Wenn die Daten mit dem privaten Schlüssel des Authentifizierungs-Serviceanbieters verschlüsselt werden, kann niemand, der eine Kopie des Tokens erhält, an dessen Entschlüsselung gehindert werden, sodass es möglicherweise zur Offenlegung vertraulicher Daten kommt. Das bedeutet, dass das Token doppelt verschlüsselt werden muss, einmal mit dem privaten Schlüssel des Authentifizierungs-Serviceanbieters und anschließend mit dem öffentlichen Schlüssel des E-Commerce-Serviceanbieters. Somit sind zum Schutz des Tokens zwei Verschlüsselungen und zu seiner Wiederherstellung zwei Entschlüsselungen erforderlich. Bei Verwendung eines Verfahrens mit geheimem Schlüssel sind jeweils nur eine Verschlüsselung und eine Entschlüsselung nötig.
Das Flussdiagramm in 3 zeigt einen Prozess, mit dessen Hilfe ein E-Commerce-Serviceanbieter versucht, von einem durch den Benutzer ausgewählten Authentifizierungs-Serviceanbieter eine authentifizierte Identität für einen Benutzer abzurufen, der auf eine kontrollierte/geschützte Ressource beim E-Commerce-Serviceanbieter zuzugreifen versucht. 3 zeigt einen Prozess, der eingeleitet wird, wenn ein Benutzer den Zugriff auf eine Ressource anfordert und ein E-Commerce-Serviceanbieter entschieden hat, dass über die Zugriffskontrolle entschieden werden muss. Zur Entscheidung über die Zugriffskontrolle benötigt der E-Commerce-Serviceanbieter eine authentifizierte Identität des Benutzers. Bei einer einmaligen Anmeldeoperation in einer föderierten Umgebung fordert der E-Commerce-Serviceanbieter den Benutzer nicht zu einem Identitätsnachweis auf, zum Beispiel durch Anmeldung mittels Benutzernamen/Passwort. Stattdessen versucht der E-Commerce-Serviceanbieter, von einem Authentifizierungs-Serviceanbieter eine authentifizierte Identität (oder einen Identitätsnachweis wie beispielsweise ein Bestätigungs-Token) abzurufen. Gemäß der vorliegenden Erfindung kann ein Benutzer die Authentifizierungsoperation einem der möglicherweise vielen Authentifizierungs-Serviceanbieter übertragen. Allerdings ist anzumerken, dass ein E-Commerce-Serviceanbieter einen Benutzer selbst authentifizieren kann, insbesondere wenn der E-Commerce-Serviceanbieter selbst die Ursprungsdomäne des Benutzers ist, obwohl sich ein E-Commerce-Serviceanbieter" zur Authentifizierung eines Benutzers normalerweise eines Authentifizierungs-Serviceanbieters bedient, wenn der E-Commerce-Serviceanbieter nicht selbst die Ursprungsdomäne des Benutzers ist.
Der Prozess in 3 beginnt damit, dass ein E-Commerce-Serviceanbieter eine Anforderung eines Benutzers für den Zugriff auf eine geschützte Ressource empfängt (Schritt 302). Dann wird ermittelt, ob beim E-Commerce-Serviceanbieter bereits eine authentifizierte Identität oder ein Berechtigungsnachweis für den Benutzer vorliegt (Schritt 304). Wenn dies nicht der Fall ist, ermittelt der E-Commerce-Serviceanbieter, ob bei ihm ein Langzeit-Token für den Benutzer vorliegt (Schritt 306). Das
Langzeit-Token kann möglicherweise ein ANSP-Identitäts-Cookie (AIDC) sein, das dem oben erwähnten Domänen-ID-Cookie ähnelt, aber den vom Benutzer bevorzugten Authentifizierungs-Serviceanbieter kennzeichnet. Der E-Commerce-Serviceanbieter könnte möglicherweise bereits über ein AIDC für den Benutzer verfügen, da im Browser des Benutzers vorher bereits ein Cookie gesetzt worden sein könnte, und da der Browser des Benutzers sicherstellt, dass das AIDC alle an die Domäne des E-Commerce-Serviceanbieters gerichteten Anforderungen begleitet, würde der E-Commerce-Serviceanbieter das Cookie empfangen haben, wenn dieses die Anforderung für den Zugriff auf die kontrollierte Ressource begleitet hat. Der E-Commerce-Serviceanbieter entnimmt dem Langzeit-Token die Identität des vom Benutzer bevorzugten Authentifizierungs-Serviceanbieters (Schritt 308) und erzeugt eine Bestätigungsanforderung für den angegebenen oder bevorzugten Authentifizierungs-Serviceanbieter (Schritt 310). Der E-Commerce-Serviceanbieter sendet die Bestätigungsanforderung durch eine HTTP-Umleitung über den Browser des Benutzers an den Authentifizierungs-Serviceanbieter (Schritt 312).
Die Wirksamkeit der vorliegenden Erfindung ergibt sich aus dem unter Bezug auf die Schritte 302 bis 312 beschriebenen Szenario. Obwohl der E-Commerce-Serviceanbieter noch nicht über eine(n) authentifizierte Identität/Berechtigungsnachweis für den Benutzer verfügt, d. h., dass der Benutzer eine neue Sitzungbeim E-Commerce-Serviceanbieter beginnt, kann der E-Commerce-Serviceanbieter bei dem vom Benutzer bevorzugten Authentifizierungs-Serviceanbieter ein Bestätigungs-Token für den Benutzer beantragen, obwohl der Benutzer während dieser betreffenden Sitzung nicht aufgefordert wurde, derartige Authentifizierungsdaten direkt an den E-Commerce-Serviceanbieter zu senden.
Ferner empfängt beim vorliegenden Beispiel der E-Commerce-Serviceanbieter zu einem bestimmten Zeitpunkt über den Browser des Benutzers durch HTTP-Umleitung die Bestätigungsantwort vom Authentifizierungs-Serviceanbieter (Schritt 314). Der E-Commerce-Serviceanbieter entpackt das Token, um die Antwort mit der Benutzerauthentifizierung zu erhalten (Schritt 316), und prüft, ob es sich um eine gültige Authentifizierung handelt (Schritt 318). Wenn dies der Fall ist, erzeugt der E-Commerce-Serviceanbieter die Sitzungsnachweise für den Benutzer (Schritt 320) und leitet die Entscheidungsoperation für die Zugriffskontrolle ein (Schritt 322). Es wird geprüft, ob der Benutzer autorisiert ist (Schritt 324), und wenn das Ergebnis der Entscheidung über die Zugriffskontrolle positiv ist, d. h., wenn der Benutzer autorisiert ist, gibt der E-Commerce-Serviceanbieter den Zugriff auf die geschützte Ressource frei (Schritt 326) und der Prozess ist abgeschlossen. Wenn beim E-Commerce-Serviceanbieter in Schritt 304 bereits eine authentifizierte Identität oder ein Berechtigungsnachweis für den Benutzer vorliegt, verzweigt der Prozess zu Schritt 322, in welchem der E-Commerce-Serviceanbieter sofort eine Entscheidung über die Zugriffskontrolle herbeiführt. Dieses Szenario kann eintreten, wenn der Benutzer bereits auf dieselbe oder eine ähnliche kontrollierte Ressource beim E-Commerce-Serviceanbieter zugegriffen hat.
Wenn in Schritt 306 beim E-Commerce-Serviceanbieter kein Langzeit-Token für den Benutzer vorliegt, verzweigt der Prozess, um einen in 5 gezeigten Unterprozess fertig zu stellen, der im Folgenden beschrieben wird.
Das Flussdiagramm in 4 zeigt einen Prozess, mit dessen Hilfe ein Authentifizierungs-Serviceanbieter ermittelt, ob er auf Anforderung eines E-Commerce-Serviceanbieters eine Bestätigung für einen Benutzer erteilen soll. Das Flussdiagramm in 4 zeigt die Ablaufsteuerung beim Authentifizierungs-Serviceanbieter, wenn der E-Commerce-Serviceanbieter eine Bestätigungsanforderung gemäß dem oben erwähnten Schritt 312 an den Authentifizierungs-Serviceanbieter sendet.
Der Prozess in 4 beginnt damit, dass ein bestimmter Authentifizierungs-Serviceanbieter von einem E-Commerce-Serviceanbieter eine Bestätigungsanforderung für einen bestimmten Benutzer empfängt (Schritt 402). Dann wird geprüft, ob beim Authentifizierungs-Serviceanbieter bereits eine aktive Sitzung für den Benutzer vorliegt (Schritt 404). Wenn beim Authentifizierungs-Serviceanbieter noch keine aktive oder laufende Sitzung für den Benutzer vorliegt, fordert der Authentifizierungs-Serviceanbieter den Benutzer auf, eine Art Authentifizierungsoperation durchzuführen (Schritt 406).
Dann wird geprüft, ob der Benutzer authentifiziert worden ist (Schritt 408). Wenn der Benutzer authentifiziert worden ist, erzeugt der Authentifizierungs-Serviceanbieter ein Authentifizierungs-Token, welches anzeigt, dass der Benutzer positiv authentifiziert worden ist (Schritt 410). Wenn der Benutzer nicht authentifiziert worden ist, erzeugt der Authentifizierungs-Serviceanbieter ein Authentifizierungs-Token, welches anzeigt, dass die Authentifizierungsoperation des Benutzers fehlgeschlagen ist (Schritt 412). In beiden Fällen sendet der Authentifizierungs-Serviceanbieter dann durch den Browser des Benutzers über eine HTTP-Umleitung eine das Authentifizierungs-Token enthaltende Bestätigungsmitteilung an den anfordernden E-Commerce-Serviceanbieter (Schritt 414), womit der Prozess abgeschlossen ist. Hierzu ist anzumerken, dass der Authentifizierungs-Serviceanbieter in beiden Fällen Pseudodaten einfügen oder den Inhalt der Bestätigungsmitteilung auf andere Weise maskieren kann, um zu verhindern, dass ein Spion zwischen positiven und negativen Bestätigungs-Token unterscheiden kann, was diesem Kenntnis über die Authentifizierungsversuche des Benutzers verschaffen würde.
Wenn in Schritt 404 beim Authentifizierungs-Serviceanbieter bereits eine aktive Sitzung für den Benutzer. vorliegt, verzweigt der Prozess zu Schritt 410, da der Authentifizierungs-Serviceanbieter sofort ein Authentifizierungs-Token erzeugen kann, welches anzeigt, dass der Benutzer positiv authentifiziert worden ist. Dieses Szenario tritt ein, wenn ein Benutzer den Nachweis für eine authentifizierte Identität bereits bei einem anderen E-Commerce-Serviceanbieter angefordert hat, der den Benutzer dann zum Ausführen einer Authentifizierungsoperation aufgefordert hätte. Der Authentifizierungs-Serviceanbieter erhält für den Benutzer eine Sitzung aufrecht, höchstwahrscheinlich mit einigen Einschränkungen, zum Beispiel in Form einer maximalen Zeitdauer, während der die Authentifizierungssitzung des Benutzers beim Authentifizierungs-Serviceanbieter gültig bleibt.
In 5 zeigt ein Flussdiagramm einen Prozess, mit dessen Hilfe ein E-Commerce-Serviceanbieter einem Benutzer gestattet, einen Authentifizierungs-Serviceanbieter und/oder zugehörige Optionen auszuwählen. Der in 3 dargestellte Prozess gelangt über Schritt 306 zu dem in 5 gezeigten Unterprozess. Wenn der E-Commerce-Serviceanbieter bei diesem Szenario nicht über ein Langzeit-Token für den Benutzer verfügt, verzweigt der Prozess, um den in 5 gezeigten Unterprozess abzuarbeiten.
Der in 5 dargestellte Prozess beginnt damit, dass der E-Commerce-Serviceanbieter dem Benutzer ein Menü mit einer Liste von ANSPs vorlegt, die vom E-Commerce-Serviceanbieter anerkannt werden (Schritt 502). Gemäß der vorliegenden Erfindung gestattet der E-Commerce-Serviceanbieter einem Benutzer, einen bevorzugten Authentifizierungs-Serviceanbieter auszuwählen, wobei es sich jedoch um einen Authentifizierungs-Serviceanbieter handeln muss, mit dem der E-Commerce-Serviceanbieter bereits eine vertrauenswürdige Beziehung unterhält. Wenn dies nicht der Fall ist, wird dem Benutzer die Gelegenheit gegeben, eine Beziehung zu einem Authentifizierungs-Serviceanbieter herzustellen, der vom E-Commerce-Serviceanbieter anerkannt wird, d. h. mit dem der E-Commerce-Serviceanbieter in der im Folgenden beschriebenen Weise eine vertrauenswürdige Beziehung unterhält.
Nach dem Vorlegen des Menüs, das die Form eines Dialogfensters oder eines anderen Benutzereingabemechanismus haben kann, empfängt der E-Commerce-Serviceanbieter die Benutzerauswahl (Schritt 504). Dann wird geprüft, ob der Benutzer den Abbruch der anstehenden Transaktion zu diesem Zeitpunkt angefordert hat (Schritt 506), und wenn dies der Fall ist, springt der Prozess wieder zurück zu Schritt 328 in 3, wo dem Benutzer der Zugriff auf die kontrollierte Ressource verweigert wird. Wenn der Benutzer den Abbruch der anstehenden Transaktion zu diesem Zeitpunkt hingegen nicht angefordert hat, wird geprüft, ob der Benutzer eine bestimmte Option ausgewählt hat, welche dem E-Commerce-Serviceanbieter mitteilt, dass der Benutzer stets einen bestimmten Authentifizierungs-Serviceanbieter nutzen will (Schritt 508). Wenn dies der Fall ist, erzeugt der E-Commerce- Serviceanbieter ein AIDC, welches den vom Benutzer ausgewählten Authentifizierungs-Serviceanbieter anzeigt (Schritt 510), der an anderer Stelle in der vom Dialogfenster des Benutzers empfangenen Benutzereingabe angezeigt wird. Bei dieser möglichen Ausführungsart kann durch Setzen eines Cookies im Browser des Benutzers ein AIDC erzeugt werden.
In beiden Fällen wird geprüft, ob der Benutzer eine Option zum Abrufen von Bestätigungsdaten von einem Authentifizierungs-Serviceanbieter ausgewählt hat (Schritt 512), dessen Identität anderswo in der vom Dialogfenster des Benutzers empfangenen Benutzereingabe angezeigt wird. Mit anderen Worten, der Benutzer hat einen bevorzugten Authentifizierungs-Serviceanbieter ausgewählt, den der E-Commerce-Serviceanbieter zur Authentifizierung des Benutzer verwenden soll, und der Prozess springt zurück zu Schritt 310, wo der E-Commerce-Serviceanbieter eine Bestätigungsanforderung für den ausgewählten Authentifizierungs-Serviceanbieter erzeugt.
Wenn der Benutzer die Option zum Abrufen von Bestätigungsdaten von einem Authentifizierungs-Serviceanbieter nicht ausgewählt hat, wird geprüft, ob der Benutzer eine Option zum Herstellen einer Beziehung zu einem Authentifizierungs-Serviceanbieter ausgewählt hat (Schritt 514). Wenn dies der Fall ist, sendet der E-Commerce-Serviceanbieter in einer bestimmten Form eine Anforderung zum Herstellen einer Beziehung an den ausgewählten Authentifizierungs-Serviceanbieter (Schritt 516), z. B. durch Umleiten des Browsers des Benutzers auf eine bestimmte Seite, die durch den vom Benutzer ausgewählten Authentifizierungs-Serviceanbieter unterstützt wird.
Wenn keine der oben genannten Optionen eingetreten ist, zeigt der E-Commerce-Serviceanbieter auf irgendeine Weise einen Verarbeitungsfehler an (Schritt 518) und der Prozess ist abgeschlossen.
Das Fenster einer grafischen Benutzeroberfläche in 6 zeigt die einem Benutzer zur Auswahl angebotenen Optionen für einen Prozess, mit dessen Hilfe ein E-Commerce-Serviceanbieter einem Benutzer die Auswahl eines Authentifizierungs-Serviceanbieters in Verbindung mit einer einmaligen Anmeldeoperation in einer föderierten Umgebung gestattet. Das Dialogfenster 600 zeigt drei runde Optionsfelder 602 bis 606, die mit den Kennungen dreier Authentifizierungs-Serviceanbieter beschriftet sind. Das Dialogfenster 600 kann einem Benutzer angezeigt werden, wenn ein E-Commerce-Serviceanbieter einem Benutzer die Möglichkeit zur Auswahl eines bevorzugten Authentifizierungs-Serviceanbieters gibt. In den meisten Webumgebungen sind die im Dialogfenster 600 gezeigten Steuerelemente zumeist in Form eines in HTML formatierten Dokuments, d. h. in Form einer Webseite, dargestellt.
Die Schaltfläche „Abbrechen" 608 gibt einem Benutzer die Möglichkeit, die anstehende Anforderung für den Zugriff auf eine kontrollierte Ressource abzubrechen, bevor er aufgefordert wird, die Authentifizierungsdaten einzugeben. Das Kontrollkästchen 610 ermöglicht es einem Benutzer, zu fordern, dass der ausgewählte Authentifizierungs-Serviceanbieter vom E-Commerce-Serviceanbieter stets verwendet werden soll, wenn der E-Commerce-Serviceanbieter zur Authentifizierung den Kontakt zu einem Authentifizierungs-Serviceanbieter aufnehmen muss. Die Schaltfläche 612 schließt das Dialogfenster und teilt dem E-Commerce-Serviceanbieter mit, dass der Benutzer wünscht, dass für Bestätigungsanforderungen durch den E-Commerce-Serviceanbieter der durch die runden Optionsfelder angezeigte Authentifizierungs-Serviceanbieter verwendet werden soll. Die Schaltfläche 614 schließt das Dialogfenster und teilt dem E-Commerce-Serviceanbieter mit, dass der Benutzer eine Beziehung zu dem durch die runden Optionsfelder angezeigten Authentifizierungs-Serviceanbieter herstellen möchte.
Der Prozess zur Bestätigung einer Benutzeridentität wird mitunter als „Übertragung von Authentifizierungszusicherungen" quer durch eine föderierte Umgebung oder eine E-Community bezeichnet. Die Ursprungsdomäne des Benutzers bestätigt einer anderen Domäne die Identität des Benutzers. Das bedeutet, dass jede an der föderierten Umgebung beteiligte Organisation für die Verwaltung der Benutzer in der Ursprungsdomäne und für die Bereitstellung eines Regelsatzes zur Zuordnung der bestätigten Identitäten von anderen Domänen zuständig ist.
Unter Bezugnahme auf die in 2 gezeigte föderierte Umgebung kann die vorliegende Erfindung genauer beschrieben werden. Der Bestätigungsprozess kommt zustande, wenn ein Benutzer eine Ressource von einer Domäne anfordert, mit welcher der Benutzer keine aktive, authentifizierte Sitzung hat, zum Beispiel von den durch ECSP 210 oder ECSP 212 unterstützten Domänen.
Angenommen, der Benutzer beim Client 202 versucht, auf eine Ressource von ECSP 210 zuzugreifen, auf dessen Ressourcen der Benutzer noch nie zugegriffen hat. Damit liegt beim Client 202 noch kein von ECSP 210 gesetztes AIDC vor und ECSP 210 fordert den Benutzer auf, die Identität eines bevorzugten Authentifizierungs-Serviceanbieters anzugeben. Ebenso wie bei der obigen Erörterung von 6 können dem Benutzer Optionen vorgelegt werden, zum Beispiel „bei ANSP-X authentifizieren" oder „bei ANSP-X anmelden". Mit der gesamten. Anforderung wäre außerdem auch noch die Option verbunden, immer einen ausgewählten Authentifizierungs-Serviceanbieter zu verwenden. Wenn der Benutzer diese Optionen ausgewählt hat, erzeugt der ECSP 210 ein entsprechendes Token, das an den vom Benutzer ausgewählten Authentifizierungs-Serviceanbieter gesendet wird.
Angenommen, der Benutzer hat eine Option zur Authentifizierung beim ANSP 214 ausgewählt. ECSP 210 erzeugt eine Bestätigungsanforderung für den ANSP 214 und sendet diese Anforderung durch Umleitung über den Browser des Clients 202 an den ANSP 214. Die Bestätigungsanforderung wird vom ANSP 214 empfangen und wenn bei diesem eine gültige laufende Sitzung mit dem Benutzer vorliegt, erzeugt der ANSP 214 eine Bestätigungsantwort und sendet diese durch HTTP-Umleitung über den Browser des Benutzers zurück zum ECSP 210. Wenn beim ANSP 214 gerade keine aktive Sitzung mit dem Benutzer vorliegt, fordert der ANSP 214 den Benutzer zur Eingabe von Authentifizierungsinformationen auf. Je nach dem Ergebnis der Authentifizierung erzeugt der ANSP 214 eine Bestätigungsantwort für den ECSP 210, wobei die Bestätigungsantwort entweder eine erfolgreiche oder eine fehlgeschlagene Authentifizierung anzeigen kann. Diese Bestätigungsantwort wird durch HTTP-Umleitung über den Browser des Benutzers zum ECSP 210 zurück gesendet.
Nach dem Empfangen des Bestätigungs-Tokens mit der Anzeige einer erfolgreichen Authentifizierung vom ANSP 214 aktiviert ECSP 210 eine Sitzung für den Client 202 und fällt anhand der Anforderung des Benutzers eine Entscheidung über die Zugriffskontrolle. Wenn der Benutzer die Option „immer diesen ANSP verwenden" ausgewählt hat, erzeugt ECSP 210 für den Benutzer ein ANSP-ID-Cookie (AIDC). Dieses Cookie kennzeichnet den vom Benutzer bevorzugten Authentifizierungs-Serviceanbieter. Weitere Zugriffe auf Ressourcen beim ECSP 210 erzeugen beim Fehlen einer gerade aktiven Sitzung automatisch eine Anforderung nach einem Bestätigungs-Token vom ANSP 214 über eine HTTP-Umleitung über den Browser des Benutzers.
Auf diese Weise werden Informationen von einer Ursprungsdomäne durch ein Bestätigungs-Token an andere Domänen in der föderierten Umgebung, d. h. der E-Community, weitergegeben. Das Bestätigungs-Token dient der Bestätigung der Authentizität der Benutzeridentität gegenüber anderen Organisationen in der föderierten Umgebung. Das Bestätigungs-Token wird für jede Domäne der E-Community nur auf Anforderung erzeugt und kann von keiner anderen als der gewünschten Domäne der E-Community genutzt werden. Das Bestätigungs-Token ist insofern vorzugsweise vorübergehend, als es nur zum Umleiten verwendet wird und nicht im persistenten oder im nicht persistenten Cookie-Speicher bleibt. Darüber hinaus ist das Bestätigungs-Token vorzugsweise durch Verschlüsselung geschützt. Das Bestätigungs-Token ist Bestandteil der Antwort, die wieder zur „anfordernden" Domäne der E-Community zurückgesendet wird. Wenn die anfordernde Front-End-Einheit bzw. die Domäne die Antwort empfängt, analysiert diese das Bestätigungs-Token, ordnet die Benutzeridentität einer lokalen Identität zu, erzeugt Berechtigungsnachweise für den Benutzer, fällt die Entscheidung über die Zugriffskontrolle und liefert die passende Antwort auf die Anforderung des Benutzers. Diese Front-End-Einheit kann dann die Identität des Benutzers innerhalb der Domäne bestätigen.
Die Vorteile der vorliegenden Erfindung werden aus der obigen detaillierten Beschreibung der Erfindung ersichtlich. Die vorliegende Erfindung gestattet einem Benutzer, Vereinbarungen mit einem oder mehreren Authentifizierungs-Serviceanbietern (ANSPs) zu treffen. Der Benutzer unterhält eine Beziehung zu diesen ANSPs und authentifiziert sich bei einem Authentifizierungs-Serviceanbieter. E-Commerce-Serviceanbieter (ECSPs), zum Beispiel Onlinebanken oder Onlinehändler, unterhalten ebenfalls eine Beziehung zu einem ANSP, sodass der E-Commerce-Serviceanbieter der im Auftrag des Benutzers vom ANSP bereitgestellten authentifizierten Identität eines Benutzers vertrauen kann. Der Benutzer kann einen beliebigen E-Commerce-Serviceanbieter aufsuchen, ohne vorher eine Beziehung zu diesem bestimmten E-Commerce-Serviceanbieter hergestellt haben zu müssen. Solange die Domäne des E-Commerce-Serviceanbieters eine Beziehung zu mindestens einem der Authentifizierungs-Serviceanbieter des Benutzers unterhält, braucht sich der Benutzer lediglich einmal bei diesem E-Commerce-Serviceanbieter anzumelden. Durch die vorliegende Erfindung wird der Benutzer unter bestimmten Bedingungen nicht zur Authentifizierung aufgefordert, wenn er auf eine geschützte Ressource auf einer zweiten Domäne innerhalb einer föderierten Umgebung zuzugreifen versucht. Dadurch wird die freie Beweglichkeit zwischen Domänen, die an einer domänenübergreifenden Föderation oder Anordnung mit einmaliger Anmeldung beteiligt sind, etwas erhöht. Der Benutzer kann seine Leistungsfähigkeit oder Produktivität steigern, da er sich nicht mehrmals authentifizieren lassen muss, was das freie Navigieren zwischen Websites einschränken kann.
Von Bedeutung ist, dass die vorliegende Erfindung zwar im Zusammenhang mit einem voll funktionstüchtigen Datenverarbeitungssystem beschrieben wurde, jedoch dem Fachmann klar sein wird, dass die Prozesse der vorliegenden Erfindung unabhängig von der jeweiligen Art des gerade zur Verteilung als Signalträger verwendeten Mediums in Form von Befehlen auf einem computerlesbaren Medium und in einer Vielfalt von anderen Formen verteilt werden können. Beispiele für computerlesbare Medien sind EPROM, ROM, Magnetband, Papier, Diskette, Festplattenlaufwerk, RAM und CD-ROMs sowie Datenübertragungsmedien wie digitale und analoge Datenübertragungsverbindungen.
Die Beschreibung der vorliegenden Erfindung dient der Veranschaulichung und ist nicht als erschöpfend oder auf die beschriebenen Ausführungsarten beschränkt anzusehen. Dem Fachmann wird klar sein, dass viele Modifikationen oder Variationen möglich sind. Die Ausführungsarten wurden zur Erläuterung der Prinzipien der Erfindung und ihrer praktischen Anwendungen gewählt und um die Erfindung Fachleuten verständlich zu machen, damit diese verschiedene Ausführungsarten mit verschiedenen Modifikationen realisieren können, die für weitere denkbare Anwendungszwecke geeignet sind.

Claims

Verfahren zur benutzerdefinierten Authentifizierung innerhalb einer föderierten Umgebung (200), die einen durch einen Client (202) dargestellten Benutzer, eine Vielzahl von E-Commerce-Serviceanbietern (210, 212) und eine Vielzahl von Authentifizierungs-Serviceanbietern (214, 216) umfasst, wobei das Verfahren die folgenden Schritte umfasst: Empfangen einer Anforderung (302) eines Clients an einem ersten Server für das Zugreifen auf eine durch den ersten Server kontrollierte Ressource; Ermitteln (304), ob der erste Server über einen gültigen Authentifizierungsnachweis für den Client am ersten Server verfügt; A: wenn der erste Server über einen gültigen Authentifizierungsnachweis verfügt: Herbeiführen einer Entscheidung über die Zugriffskontrolle (322) für die Anforderung eines Clients für den Zugriff (326) auf die kontrollierte Ressource ausgehend von dem Authentifizierungsnachweis für den Client am ersten Server; wenn der erste Server über keinen gültigen Authentifizierungsnachweis verfügt: Ermitteln (306), ob der erste Server über eine Identität eines zweiten Servers verfügt, um einen Authentifizierungsservice zu unterstützen, der vorher mit dem Client am ersten Server verbunden war; B: wenn der erste Server über eine Identität eines zweiten Servers verfügt: Senden einer Authentifizierungsanforderung (312) vom ersten Server an den zweiten Server; Empfangen (314, 316) des Authentifizierungsnachweises für den Client vom zweiten Server; und Fortfahren mit Schritt A; wenn der erste Server über keine Identität eines zweiten Servers verfügt: Vorlegen eines Menüs von Authentifizierungs-Serviceanbietern (502) für den Client; Empfangen einer Auswahl (504) einer Identität für den zweiten Server vom Client; und Fortfahren mit Schritt B.
Verfahren nach Anspruch 1, das ferner Folgendes umfasst: Ermitteln auf dem zweiten Server (404), ob der zweite Server über einen gültigen Authentifizierungsnachweis für den Client verfügt; und als Reaktion auf eine Ermittlung, dass der zweite Server über einen gültigen Authentifizierungsnachweis für den Client verfügt, Zurückgeben eines gültigen Authentifizierungsstatus (410) als Reaktion auf eine Authentifizierungsanforderung des ersten Servers.
Verfahren nach Anspruch 1 oder Anspruch 2, das ferner Folgendes umfasst: Zuordnen (510) der Benutzerauswahl der Identität des zweiten Servers zum Client auf dem ersten Server.
Verfahren nach Anspruch 3, das ferner Folgendes umfasst: Speichern (510) der Benutzerauswahl der Identität des zweiten Servers in einem persistenten Cookie beim Client.
Verfahren nach Anspruch 3, das ferner umfasst, dass einem Benutzer gestattet wird, auszuwählen (508, 610), ob die Benutzerauswahl der Identität des zweiten Servers in einem Cookie beim Client gespeichert werden soll.
Verfahren nach Anspruch 3, das ferner umfasst, dass einem Benutzer gestattet wird, auszuwählen (508, 610), ob die Benutzerauswahl der Identität des zweiten Servers dem Benutzer dauerhaft zugeordnet werden soll.
Verfahren nach Anspruch 1, das ferner Folgendes umfasst: Umleiten der Authentifizierungsanforderung per HTTP an den zweiten Server über den Client (312) auf dem ersten Server.
Verfahren nach Anspruch 1, das eine Netzdatennachricht (302) verwendet, die Folgendes umfasst: einen Transportprotokollheader; eine einheitliche Referenz-ID (Uniform Resource Identifier, URI), die einer kontrollierten Ressource zugeordnet ist; und ein Token eines Authentifizierungs-Serviceanbieters, das eine Domänenidentität eines Authentifizierungs-Serviceanbieters angibt, wobei der Authentifizierungs-Serviceanbieter einer aus einer Vielzahl von Authentifizierungs-Serviceanbietern in einer föderierten Umgebung ist, der zum Antworten auf eine Anforderung für den Zugriff auf die kontrollierte Ressource verwendet werden kann.
Computersystem, das Mittel umfasst, welche zum Ausführen der Schritte des Verfahrens nach einem der vorangehenden Ansprüche 1 bis 8 angepasst sind.
Computerprogramm, das auf einem vom Computer verwendbaren Medium gespeichert ist, wobei das Computerprogramm computerlesbare Programmmittel umfasst, mit denen ein Computer zum Ausführen eines Verfahrens nach einem der vorangehenden Ansprüche 1 bis 8 veranlasst wird, wenn das Programm auf dem Computer läuft.