-
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 BluetoothTM-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.