-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung betrifft das Gebiet von Anmeldungsverfahren
und den Privatsphäre
verbessernde Technologien und Datenübertragungsumgebungen, die
dieselben verwenden. Insbesondere betrifft die vorliegende Erfindung
Anmeldungs- und Einmalanmeldungs-Verfahren, bei denen Daten, die
eine Entität
identifizieren, von der aus ein Dienst angefordert wird, zu einer
Authentifikations-Entität
in einer kaschierten Weise weitergeleitet werden.
-
Allgemeiner
Stand der Technik
-
Zum
besseren Verständnis
der Beschreibung werden Terminologien und Abkürzungen verwendet, die in dem
Glossar am Ende definiert sind.
-
Für Einmalanmeldung
(SSO) erfolgt die Verwaltung und Authentifikation der dienstanfordernden
Entität
durch eine oder mehrere Authentifikations-Entitäten, die als Identitätsanbieter
(IdPs) bezeichnet werden, die von den dienstanbietenden Entitäten getrennt
sind, die als Dienstanbieter (SPs) bezeichnet werden, die z.B. Websites
oder andere Dienste betreiben. Diese Trennung hat eine Reihe von
Vorteilen, von denen der wichtigste derjenige ist, dass ein Benutzer
sich nicht mehr mehrere Benutzernamen und Passwörter merken muss oder noch
schlimmer Passwörter
wiederverwenden muss und damit ihre Sicherheit gefährdet. Als
veranschaulichendes Beispiel einer SSO-anbietenden Technologie wird
auf das Liberty Alliance Project (LAP) verwiesen. Insbesondere wird verwiesen
auf die Spezifikationen der Version 1.0 von LAP (Liberty Alliance
Project: "Liberty
Protocols and Schemas Specification", Version 1.0, 11. Juli 2002; veröffentlicht
am 15. Juli 2002; "Liberty
Bindings and Profiles Specifications, Version 1.0, 11. Juli 2002,
veröffentlicht
am 15. Juli 2002; "Liberty Architecture
Overview", Version
1.0, 11. Juli 2002, veröffentlicht
am 15. Juli 2002).
-
Daher
wird hier keine umfassende Einführung
und kein umfassender allgemeiner Stand der Technik angegeben. Es
wird vielmehr vorausgesetzt, dass die grundlegenden Mechanismen
des SSO sowie die LAP-1.0-Spezifikationen bekannt sind.
-
Es
wird angenommen, dass ein Principal bereits eine Identität IdP-ID
bei seinem Identitätsanbieter
IdP und eine unterschiedliche Identität SP-ID bei jedem Dienstanbieter
eingerichtet hat, mit denen der Principal wenigstens zu kommunizieren
beabsichtigt. Es ist wünschenswert,
dass – wenn
eine Migration zu einem Einmalanmeldungs-System erfolgt, z.B. LAP – der Principal
alle seine bestehenden Accounts bei Dienstanbietern mit einer einzigen "Verbund-Identität" verknüpfen kann,
statt alle Beziehungen zu Dienstanbietern nochmals erneut einrichten
zu müssen.
Diese Prozedur wird allgemein als Account-Verknüpfung bezeichnet und ist bekannt,
weshalb hier von weiteren Erklärungen
abgesehen wird.
-
In
dem Fall, in dem die Accounts des Principal beim Identitätsanbieter
IdP und Dienstanbieter SP bereits verknüpft worden sind, (d.h. dass
ein Pseudonym zwischen dem Identitätsanbieter IdP und dem Dienstanbieter
SP zum Angeben des Principal bereits eingerichtet worden ist), besteht
die Einmalanmeldungs-Prozedur aus den in 1 veranschaulichten
Schritten. Es wird hier angemerkt, dass LAP 1.0 tatsächlich nicht
nur ein einzelnes Pseudonym für
jeden Principal zwischen jedem IdP und jedem SP verwendet, sondern
zwei: eines, (das "IDPProvidedNameIdentifier"), wird von dem IdP
generiert, und das andere, (das "SPProvidedNameIdentifier"), wird von dem SP
generiert. Im Folgenden wird diese Tatsache außer Acht gelassen, weil sie
nur zu mehr Komplexität
führt,
ohne etwas am Konzept zu ändern.
Daher wird der Begriff einer einzelnen ALIAS-ID verwendet, auch
wenn diese tatsächlich
aus zwei verschiedenen Pseudonymen bestehen kann.
-
Ein
Principal sendet über
einen Client, die hier als Benutzer Agent bezeichnet wird, eine
Dienstanforderung, (z.B. eine HTTP-Anforderung), an den Dienstanbieter
SP (Schritt 1).
-
Der
Dienstanbieter SP entscheidet über
bandexterne Einrichtungen, (z.B. durch Abfragen des Benutzers),
welcher Identitätsanbieter
IdP für
diese bestimmte Anmeldungsprozedur zu verwenden ist (Schritt 2).
-
Der
Dienstanbieter SP sendet über
den Client oder Benutzer Agent eine Authentifikationsanforderung an
den Identitätsanbieter
IdP (Schritt 3, 4).
-
Der
Identitätsanbieter
IdP authentifiziert den Principal über bandexterne Einrichtungen,
z.B. durch Fragen nach einem Benutzernamen und Passwort und durch
deren Verifizieren (Schritt 5).
-
Der
Identitätsanbieter
IdP sendet eine Authentifikationsantwort zu dem Dienstanbieter SP,
in welcher er (mittels einer digitalen Signatur) die Identität des Principal
bestätigt
(Schritt 6, 7). Unter der Annahme, dass die zwei
Accounts vorher verknüpft
(im Verbund zusammengefasst) worden sind, verwendet der Identitätsanbieter
IdP die ALIAS-ID, die zwischen dem Identitätsanbieter IdP und dem Dienstanbieter
SP eingerichtet worden ist. Mittels z.B. einer Tabellensuche oder
Datenbankabfrage kann die ALIAS-ID erhalten werden, die für eine vorgegebene
IdP-ID (wie in Schritt 5 bestimmt) und den vorgegebenen
Dienstanbieter SP (unter dem Namen von SP-Name, der in den Anforderungsschritten 3, 4 spezifiziert
worden sein muss), verwendet werden soll.
-
Optional,
z.B. in dem Fall von Einmalanmeldungs-Systemen, die ein SAML-Artefakt
verwenden, können
der Dienstanbieter SP und der Identitätsanbieter IdP HTTP-Anforderungen
austauschen, um Datenabschnitte zu identifizieren, die für die Authentifikation
eigentlich nicht notwendig sind (Schritt 8 und 9).
-
Der
Dienstanbieter SP verarbeitet die Bestätigung (Schritt 10)
und ordnet die ALIAS-ID der SP-ID zu, z.B. mittels einer Tabellensuche
oder Datenbankabfrage.
-
Der
Dienstanbieter SP stellt den angeforderten Dienst für den Principal
bereit (Schritt 11), wenn die Authentifikationsantwort,
die vom Identitätsanbieter
IdP erhalten wurde, den Kriterien des Dienstanbieters SP entspricht.
-
Im
Folgenden wird angenommen, dass keine vorherige Account-Verknüpfung stattgefunden
hat, und dass ein Identitätsverbund
gewünscht
wird, d.h. sobald ein Principal sich beim Dienstanbieter SP über den Identitätsanbieter
IdP zum ersten Mal authentifiziert, sollen bestehende Accounts des
Principal im Verbund zusammengefasst werden. In diesem Fall könnte ein
Flag in der Authentifikationsanforderung (Schritt 3, 4)
verwendet werden, um anzugeben, dass eine Account-Verknüpfung gewünscht wird.
Im Fall von LAP würde
ein sogenanntes "Federate"-Flag in der Authentifikationsanforderung
(Schritt 3, 4) eine Account-Verknüpfung angeben. Bis und einschließlich Schritt 5 ist
dieses Szenario mit dem vorherigen vergleichbar.
-
Vor
dem Senden der Authentifikationsantwort (Schritt 6, 7)
erstellt der Identitätsanbieter
IdP eine neue Namenskennung ALIAS-ID für den Principal, da vorher
keine eingerichtet worden ist.
-
Der
Identitätsanbieter
IdP fügt
einen Eintrag in seine Tabelle oder Datenbank ein, so dass bei künftigen Datenübertragungen
mit dem Dienstanbieter die gleiche ALIAS-ID für den gleichen Principal, (der
durch die IdP-ID identifiziert wird), verwendet wird.
-
In
Schritt 10 empfängt
der Dienstanbieter SP die neu erstellte ALIAS-ID, weiß aber noch
nicht, zu welchem Principal sie gehört. Daher muss er den Principal
lokal identifizieren und wahrscheinlich authentifizieren, um die
Account-Verbundzusammenfassung zu vervollständigen. Wenn eine Authentifikationsbestätigung von dem
Identitätsanbieter
IdP für
einen Principal von dem Dienstanbieter zum ersten Mal für diesen
Principal empfangen wird, kann die lokale Identifizierung und Authentifikation
z.B. auf der Anforderung eines Benutzernamens und Passworts von
dem Principal basieren. Damit kann der Dienstanbieter SP die SP-ID
des Principal bestimmen. Dann fügt
der Dienstanbieter SP die Verknüpfung
zwischen die ALIAS-ID und die SP-ID in seine Tabelle oder Datenbank
ein. Wenn der Dienstanbieter SP das nächste Mal eine Authentifikationsbestätigung von
dem Identitätsanbieter
IdP mit der Identität
ALIAS-ID für
diesen Principal empfängt,
weiß er
(aus einer Datenbanksuche), dass der Principal SP-ID ist, ohne eine
erneute Authentifikation zu benötigen.
-
In
bekannten SSO-Ansätzen,
wie beispielsweise LAP 1.0, hat der Identitätsanbieter IdP eine Tabelle oder
Datenbank, welche die Beziehungen zwischen allen Principals und
SPs beschreibt, d.h. der Identitätsanbieter
IdP weiß,
auf welche Dienste jeder Principal zugreift und wann. Dies ist sowohl
seitens des Benutzers als auch vom Standpunkt der SPs aus problematisch:
Ein
Benutzer kann besorgt sein, dass eine einzelne Entität, d.h.
der Identitätsanbieter
IdP, zu viele Informationen über
den Benutzer sammelt. Die persönlichen
Daten des Benutzers zusammen mit einer erschöpfenden Liste, die zeigt, welche
Websites der Benutzer besucht, und die Schlussfolgerungen über die
Interessen des Benutzers und sein Verbraucherverhalten zulässt, weist
einen wesentlichen wirtschaftlichen Wert auf. Die Versuchung, diese
Informationen zu verkaufen und/oder sie zu anderen Zwecken als dem
beabsichtigen (Einmalanmeldungs-Bereitstellung) zu verwenden, ist
groß.
-
Die
Kundendatenbank des Dienstanbieters SP ist eines seiner Schlüssel-Aktivposten,
und wenige Gesellschaften sind willens, diese mit einer anderen
Entität
zu teilen, z.B. dem Identitätsanbieter.
-
Es
ist des Weiteren wünschenswert,
dass jeder Dienstanbieter aus der Kenntnis einer SP-ID eines Principals
nicht die IdP-ID des gleichen Auftragsgebers beim Identitätsanbieter
IdP oder die SP-ID des gleichen Principal bei anderen Dienstanbietern
ableiten kann. Desgleichen sollte der Identitätsanbieter IdP nicht in der
Lage sein, irgendwelche SP-IDs des Principal aus der Kenntnis der
IdP-ID des Principals abzuleiten.
-
US 6161139 verweist auf
ein Verfahren und eine Vorrichtung zum Kontrollieren des Zugriffs
auf geschützte
Informations-Ressourcen.
Insbesondere wird ein Benutzer, der bisher nicht authentifiziert
ist, aber Zugriff auf eine geschützte
Ressource eines geschützten
Servers anfordert, von dem geschützten
Server zu einer Log-in-Verweisadresse (URL) umgeleitet, die mit
einem Zugangs-Server verknüpft
ist. Zu diesem Zweck wird eine Hypertext-Transfer-Protocol- (HTTP)
Umleitung verwendet.
-
Das
Dokument "Internet
Junkbusters Frequently Asked Questions" vom 23. Oktober 2002 verweist auf ein
Software-Tool, das
identifizierende Header-Informationen löscht, die zwischen Web-Servern
und Browsern ausgetauscht werden. Für HTTP-Header in Anforderungen
an Server kann das Software-Tool
insbesondere einen so genannten "referrer"-Header löschen, der
angibt, wo die aktuell angeforderte URL gefunden wurde. Alternativ
kann ein Schein-Header hinzugefügt
werden, der für
jede HTTP-Anforderung der gleiche ist.
-
Aufgabe der
Erfindung
-
Die
Aufgabe der vorliegenden Erfindung ist es, Lösungen für die oben genannten Privatsphären- und Datenschutzprobleme
bereitzustellen. Insbesondere ist es die Aufgabe der vorliegenden
Erfindung, jeweils ein Verfahren und eine Datenübertragungsumgebung und Komponenten
davon bereitzustellen unter Verwendung des Verfahrens, das eine
sichere Authentifikation einer Entität in Bezug auf eine authentifikationsanfordernde Entität mit wenigstens
reduzierter Datenübertragung
von entitätsidentifizierenden
Daten gestattet.
-
Kurze Beschreibung
der Erfindung
-
Um
die oben genannte Aufgabe zu lösen,
stellt die vorliegende Erfindung ein Verfahren zur Anmeldung in
einer netzwerkbasierten Datenübertragungsumgebung
bereit, in der eine Authentifikation einer ersten Entität von einer
zweiten Entität
angefordert wird, um auf einen Dienst zuzugreifen, der von der zweiten
Entität
für die
erste Entität
bereitgestellt werden soll, wobei die Authentifikation von einer
dritten Entität
bereitgestellt wird, wobei Daten, welche die zweite Entität identifizieren,
der dritten Entität
gegenüber
kaschiert werden. Der Vorteil durch die Kaschierung von Daten, welche
die zweite Entität
identifizieren, gegenüber
der dritten Entität
besteht darin, dass die dritte Entität die Identität der zweiten
Entität
auf der Basis der kaschierten Daten nicht ableiten kann. Die erste
Identität
kann zum Beispiel durch einen Principal und einen Client dargestellt
werden, die zweite Entität
durch einen Dienstanbieter, und die dritte Entität durch einen Identitätsanbieter.
-
Gemäß einer
bevorzugten Ausführungsform
wird das Verfahren gemäß der vorliegenden
Erfindung für eine
Einmalanmeldung verwendet. Unter Bezugnahme auf die oben genannte
Beschreibung einer Einmalanmeldung, z.B. in Übereinstimmung mit den LAP-Spezifikationen,
stellt die vorliegende Erfindung ein Verfahren zum Kaschieren der
Identität
des Dienstanbieters SP gegenüber
dem Identitätsanbieter
IdP bereit.
-
Kaschieren
bedeutet, dass Daten, welche die zweite Entität identifizieren, so modifiziert
werden, dass die kaschierten Daten keine Informationen bereitstellen,
auf deren Basis die zweite Entität
identifiziert werden kann, ausgenommen vorzugsweise für die Entität, die wenigstens
Datenkaschierung initiiert hat, hier die erste Entität. Beispiele
für Kaschieren
umfassen die Verwendung eines Pseudonyms oder Alias für die Daten,
welche die zweite Entität
identifizieren.
-
Daten,
welche die zweite Entität
identifizieren, können
ein Name, eine Identifizierung oder dergleichen der zweiten Entität sein,
die für
die erste Entität
verfügbar
sind, und virtuell für
jede Entität,
die Dienst von der zweiten Entität
anfordert. Beispiel für
Daten, welche die zweite Entität
identifizieren, sind die Domäne
oder der Host-Name der zweiten Entität, insbesondere, wenn die zweite
Entität
ein auf einem Computernetzwerk basierender Dienstanbieter ist.
-
Trotzdem
kann die dritte Entität
die kaschierten Daten als eindeutige Kennung für die zweite Entität verwenden.
Wenn zum Beispiel die dritte Entität die gleichen kaschierten
Daten zweimal empfängt,
kann die dritte Entität
nicht ableiten, auf welche Entität
sich die kaschierten Daten beziehen, aber die dritte Entität ist in der
Lage zu erkennen, dass diese kaschierten Daten sich auf die gleiche
Entität
beziehen.
-
Um
herkömmliche
netzwerkbasierte Dienste zu integrieren, zieht die vorliegende Erfindung
in Erwägung,
dass von der zweiten Entität
bereitgestellte Dienste eine entsprechende Dienstanforderung von
der ersten Entität
anfordern können.
Trotzdem ist es zum Beispiel auf der Basis von Grundeinstellungen
in Bezug auf die erste und die zweite Entität möglich, dass von einem Dienst
der zweiten Entität
angenommen wird, dass er für
die erste Entität "automatisch" bereitgestellt wird,
z.B. bei Einrichten einer Datenübertragungsverbindung.
Diese Optionen sind allgemein jeweils als "Pull-Dienst" und "Push-Dienst" bekannt.
-
Damit
vergleichbar kann die Authentifikation für die erste Entität zum tatsächlichen
Bereitstellen und/oder Zugreifen auf einen Dienst der zweiten Entität eine voreingestellte
oder vordefinierte Anforderung für irgendwelche
dienstbezogenen Datenübertragungen
zwischen der ersten und der zweiten Entität sein. Als eine Alternative
ist es möglich,
dass die zweite Entität,
falls in Reaktion auf die Dienstanforderung anwendbar, eine erste
Authentifikationsanforderung generiert und dieselbe zu der ersten
Entität überträgt, wobei
die erste Authentifikationsanforderung von der ersten Entität zu der zweiten
Entität
zuordenbar ist. Eine solche Authentifikationsanforderung kann eine
so genannte vertrauenswürdige
Gruppenkennung enthalten, die angibt, dass die zweite Entität zu einer
Gruppe von vertrauenswürdigen
Entitäten
gehört.
Eine solche vertrauenswürdige Gruppenkennung
kann eine Gruppensignatur oder irgendeine andere Kennung sein, die
gegenüber
der dritten Entität
nachweist, dass die zweite Entität
zu einem vertrauenswürdigen
Kreis gehört.
In dem Fall, in dem die Authentifikation der ersten Entität keine
Authentifikationsanforderung durch die zweite Entität erfordert,
kann die vertrauenswürdige
Gruppenkennung alleine übertragen
werden. Es ist jedoch beabsichtigt, dass eine vertrauenswürdige Gruppenkennung
die Identität
der zweiten Entität
nicht preisgibt.
-
In
dem Fall, in dem die erste Entität
nicht im Besitz von Daten ist, welche die zweite Entität identifizieren,
können
solche Daten nur von der ersten Entität erhalten werden. Zum Beispiel
kann die erste Entität,
falls anwendbar, die erste Authentifikationsanforderung verwenden,
um Daten zu extrahieren, welche die zweite Entität identifizieren. Des Weiteren
umfassen Beispiele das Erhalten von Daten, welche die zweite Entität identifizieren,
aus Datenübertragungen
zwischen der ersten und der zweiten Entität, wie beispielsweise ein HTTP-Get
oder SOAP-Nachrichten, die von der zweiten Entität empfangen werden.
-
Vorzugsweise
wird das Kaschieren der Daten, welche die zweite Entität identifizieren,
von der ersten Entität
selbst ausgeführt.
Als Alternative kann das Kaschieren der Daten, welche die zweite
Entität
identifizieren, von einer weiteren Entität ausgeführt werden, welche Informationen bereitstellt,
welche die unmodifizierten Daten, welche die zweite Entität identifizieren,
und entsprechende Kaschierungsdaten nur mit der ersten Entität korrelieren.
Zum Kaschieren von Daten, welche die zweite Entität identifizieren,
können
ein Speicher, wie beispielsweise eine Nachschlagetabelle, die mit
der Entität
verknüpft
ist, die das Kaschieren der Daten ausführt, und/oder Verschlüsselungstechniken
verwendet werden. In dem Fall, in dem ein Speicher zum Kaschieren
von Daten verwendet wird, welche die zweite Entität identifizieren,
ruft die erste Entität
in Abhängigkeit
von den unmodifizierten Daten, welche die zweite Entität identifizieren,
entsprechende kaschierte Daten ab. Außerdem ist es möglich, dass
kaschierte Daten für
Daten, welche die zweite Entität
identifizieren, in weiterer Abhängigkeit
von Daten abgerufen werden, die von der dritten Entität verwendet
werden, um die erste Entität
zu identifizieren. Wenn ein Speicher, der von der ersten Entität zur Datenkaschierung
verwendet wird, keine kaschierten Daten für Daten enthält, welche
die zweite Entität
identifizieren, generiert die erste Entität entsprechende kaschierte
Daten. In dem Fall, in dem Verschlüsselungstechniken zur Datenkaschierung
verwendet werden, kann ein dauerhaft gespeicherter Geheimschlüssel zum
Verschlüsseln
von Daten verwendet werden, welche die zweite Entität identifizieren.
-
Um
die dritte Entität
zu informieren, dass eine Authentifikation angefordert wird, kann
die erste Entität eine
Authentifikationsanforderung generieren. Wenn die erste Entität eine Authentifikationsanforderung
von der zweiten Entität
erhalten hat, wie oben dargelegt, wird die Authentifikationsanforderung
von der ersten Entität
als die zweite Authentifikationsanforderung bezeichnet. Hier umfasst
das Verfahren gemäß der vorliegenden
Erfindung vorzugsweise den Schritt zum Erhalten von Daten, welche
die dritte Entität
identifizieren, und zum Übertragen
einer zweiten Authentifikationsanforderung von der ersten Entität zu der
dritten Entität,
wobei die zweite Authentifikationsanforderung die kaschierten Daten
und Daten, welche die erste Entität gegenüber der dritten Entität identifizieren,
enthält
oder von diesen begleitet wird. Zum Generieren dieser Authentifikationsanforderung
verwendet die erste Entität
die kaschierten Daten, die einen Teil der zweiten Authentifikationsanforderung
bilden können,
oder die damit verknüpft
sein können.
Zum Übertragen
der zweiten Authentifikationsanforderung von der ersten Entität zu der
dritten Entität
werden Daten verwendet, welche die dritte Entität charakterisieren. Zum Erhalten
solcher Daten, welche vorzugsweise die dritte Entität in einer
unzweideutigen Weise identifizieren, können geeignete Daten von der
zweiten Entität
zu der ersten Entität übertragen
werden, zum Beispiel mittels der ersten Authentifikationsanforderung.
Zusätzlich
dazu oder als Alternative ist es möglich, Daten, welche die dritte
Entität
charakterisieren, aus einem Speicher zu erhalten, der mit der ersten
Entität verknüpft ist,
oder entsprechende Daten durch einen Benutzer einzugeben, welche
die von einem Benutzer ausgewählte
Entität
als die dritte Entität
darstellen.
-
Vorzugsweise
sind die Daten, welche die erste Entität gegenüber der dritten Entität identifizieren,
eine zweite vertrauenswürdige
Gruppenkennung oder werden von dieser begleitet, welche eine Gruppe
von vertrauenswürdigen
Entitäten
angibt, zu denen die erste Entität
gehört.
-
Vorzugsweise
umfasst die zweite Authentifikationsanforderung die erste vertrauenswürdige Gruppenkennung
oder wird von dieser begleitet.
-
Des
Weiteren wird bevorzugt, dass das Verfahren den Schritt des Authentifizierens
der ersten Entität durch
die dritte Entität
unter Verwendung von wenigstens den Daten umfasst, welche die erste
Entität
gegenüber
der dritten Entität
identifizieren.
-
Des
Weiteren umfasst das Verfahren vorzugsweise den Schritt des Authentifizierens
der ersten Entität durch
die dritte Entität
unter Verwendung von wenigstens der zweiten vertrauenswürdigen Gruppenkennung.
-
Des
Weiteren wird bevorzugt, dass das Verfahren den Schritt des Authentifizierens
der zweiten Entität durch
die dritte Entität
unter Verwendung der ersten vertrauenswürdigen Gruppenkennung umfasst.
-
In
Reaktion auf die zweite Authentifikationsanforderung kann die dritte
Entität
die erste Entität
durch die bereitgestellten Daten identifizieren, welche die erste
Entität
gegenüber
der dritten Entität
identifizieren, z.B. durch Prüfen,
ob ein entsprechender Eintrag in der Datenbank, die für die dritte
Entität
zugänglich
ist, gefunden wird. Wenn kein Eintrag gefunden wird, kann die dritte
Entität
die erste Entität
auffordern, sich über
die dritte Entität
bei dem Authentifikations-Dienstanbieter zu registrieren oder kann
die Prozedur abbrechen. Wenn ein Eintrag gefunden wird oder in Verbindung
mit der Registrierung steht, kann die dritte Entität die erste
Entität authentifizieren,
z.B. durch Anforderung und Verifizieren eines Benutzernamens und
Passworts von der ersten Entität.
-
Wenn
die Daten, welche die erste Entität gegenüber der dritten Entität identifizieren,
eine (zweite) vertrauenswürdige
Gruppenkennung sind oder von dieser begleitet werden, welche angibt,
dass die erste Entität zu
einer Gruppe vertrauenswürdiger
Entitäten
gehört,
kann die dritte Entität
die erste Entität
als zu einer Gruppe von vertrauenswürdigen Entitäten gehörig identifizieren.
Die Verwendung der zweiten vertrauenswürdigen Gruppenkennung ermöglicht es
der dritten Entität,
eine implizite Authentifikation der ersten Entität zu erzielen, d.h. die dritte
Entität
kann verifizieren, dass die erste Entität zu einem vertrauenswürdigen Kreis
gehört
und somit ein mögliches
Kriterium der dritten Entität
für die
Authentifikation erfüllt.
Außerdem
kann sie eine zusätzliche
explizite Authentifikation bereitstellen, (z.B. wie vorher für einen
Benutzernamen/Passwort-Mechanismus beschrieben), wobei eine zusätzlich erforderliche
Datenübertragung
mit der ersten Entität
entfallen kann.
-
In ähnlicher
Weise kann die zweite Entität
authentifiziert werden, wenn die zweite Authentifikationsanforderung
von der ersten vertrauenswürdigen
Gruppenkennung begleitet wird. In diesem Fall ist für die dritte Entität jedoch
keine Identifikation der zweiten Entität möglich.
-
Des
Weiteren wird bevorzugt, dass das Verfahren den Schritt des Erhaltens
von Daten, welche die erste Entität gegenüber der zweiten Entität identifizieren, über die
dritte Entität
in Reaktion auf die zweite Authentifikationsanforderung unter Verwendung
der kaschierten Daten und der Daten, welche die erste Entität gegenüber der
dritten Entität
identifizieren, umfasst.
-
Wenn
die Authentifikation der ersten Entität durch die dritte Entität erfolgreich
ist und, falls anwendbar, die Authentifikation der zweiten Entität durch
die dritte Entität
ebenfalls erfolgreich ist, generiert die dritte Entität eine erste
Authentifikationsantwort. Hier wird bevorzugt, eine erste Authentifikationsantwort
von der dritten Entität
zu der ersten Entität
zu übertragen,
wobei die erste Authentifikationsantwort wenigstens die Daten, welche die
erste Entität
gegenüber
der zweiten Entität
charakterisieren, umfasst oder von diesen begleitet wird.
-
Im
Fall von höheren
Anforderungen an Sicherheit, Datenschutz und Privatsphäre kann
die dritte Entität die
erste Authentifikationsantwort mit einer Signatur für die Authentifikation
der dritten Entität
gegenüber
der zweiten Entität
versehen.
-
Um
die erste Entität
in die Lage zu versetzen, die erste Authentifikationsantwort, die
von der dritten Entität
empfangen wird, mit der Authentifikationsanforderung und damit mit
der zweiten Entität
zu korrelieren, können
geeignete Daten in die erste Authentifikationsanforderung und in
die erste Authentifikationsantwort aufgenommen werden. Ein erstes
Beispiel für
geeignete Daten ist eine Sitzungskennung, auf deren Basis die erste
Entität
die Authentifikationsantwort mit ihrer Authentifikationsanforderung
verknüpfen
kann. Ein weiteres Beispiel sind die kaschierten Daten selbst, die,
wenn sie in Verbindung mit der ersten Authentifikationsantwort bereitgestellt
werden, die erste Entität
in die Lage versetzen können,
eine Aufhebung der Kaschierung der kaschierten Daten auszuführen und
somit die Daten preiszugeben, welche die zweite Entität identifizieren.
Die erste Entität
kann ihre Authentifikation durch Übertragen einer zweiten Authentifikationsantwort
zu der zweiten Entität
weiterleiten. Die zweite Authentifikationsantwort umfasst die Daten,
welche die erste Entität
gegenüber der
zweiten Entität
charakterisieren, oder wird von diesen begleitet. Die charakterisierenden
Daten können
von der zweiten Entität
verwendet werden, um die zweite Authentifikationsantwort mit der
ersten Entität
zu verknüpfen.
-
Die
Authentifikation der ersten Entität ist erfolgreich, wenn die
zweite Entität
die zweite Authentifikationsantwort akzeptiert oder die damit bereitgestellte
Authentifikation die Kriterien der zweiten Entität erfüllt. Dann kann die zweite Entität eine Dienstantwort
zu der ersten Entität übertragen,
die angibt, das der angeforderte Dienst jetzt verfügbar ist
und auf ihn zugegriffen werden kann.
-
Eine
solche Dienstantwort kann weggelassen werden, wenn zum Beispiel
die Bereitstellung des und/oder der Zugriff auf den angeforderten
Dienst wenigstens anfänglich
gestattet ist und nur unterbrochen wird, wenn eine negative Dienstantwort
von der zweiten Entität
zu der ersten Entität
in dem Fall übertragen wird,
dass die Authentifikation der ersten Entität fehlschlägt.
-
Hier
oder vor der Übertragung
der Dienstantwort ist es möglich,
dass die zweite Entität
eine Identifizierung der ersten Entität als zusätzliche Information zu der
Authentifikation der ersten Entität anfordert oder benötigt. Dies
kann von der zweiten Entität
erreicht werden über
das Erhalten von Daten, welche die erste Entität gegenüber der zweiten Entität identifizieren,
z.B. durch entsprechende Datenübertragung
von dieser, wie beispielsweise Passwörter und Benutzernamen.
-
Gemäß einer
bevorzugten Ausführungsform
ist die erste Entität
eine computerbasierte Endbenutzer-Einheit, wie beispielsweise ein
Arbeitsplatzrechner oder ein Mobiltelefon, die zweite Entität ist ein
auf einem Computernetzwerk basierender Dienstanbieter, wie beispielweise
ein Internet-Dienstanbieter, und die dritte Entität ist ein
Identitätsanbieter,
ein Authentifikations-Trust-Center,
ein Internet-Dienstanbieter oder ein Mobilfunknetzwerk-Betreiber.
In einer weiteren Ausführungsform
beruht das Verfahren gemäß der vorliegenden
Erfindung zumindest teilweise auf den LAP-Spezifikationen.
-
Gemäß einer
weiteren bevorzugten Ausführungsform
kann die erste Entität
durch einen Principal dargestellt werden für Identifikations- und/oder
Authentifikationszwecke an den entsprechenden Entitäten, (z.B. SP,
IdP), die Daten empfangen, (z.B. IdP-ID, SP-ID, ALIAS-ID), welche
die erste Entität
gegenüber
den jeweiligen empfangenden Entitäten identifizieren oder charakterisieren,
und durch einen Client für
Datenübertragungs-
und Datenverarbeitungszwecke, (z.B. kaschieren), soweit sie mit
der ersten Entität
in Beziehung stehen.
-
Des
Weiteren, um die oben genannte Aufgabe zu erfüllen, stellt die vorliegende
Erfindung eine Datenübertragungsumgebung,
Entitäten
und ein – vorzugsweise
auf einem computerlesbaren Speichermedium oder in einer computerlesbaren
Speichereinheit gespeichertes – Computerprogramm-Produkt
bereit, wie in den weiteren Ansprüchen definiert.
-
Kurze Beschreibung
der Figuren
-
In
der folgenden Beschreibung von bevorzugten Ausführungsformen wird auf die folgenden
begleitenden Figuren Bezug genommen:
-
1 zeigt
einen Nachrichtenfluss für
eine Einmalanmeldungs-Prozedur gemäß LAP-Spezifikationen,
-
2 zeigt
einen Nachrichtenfluss für
eine Einmalanmeldungs-Prozedur gemäß der vorliegenden Erfindung,
-
3 zeigt
einen weiteren Nachrichtenfluss für eine Einmalanmeldungs-Prozedur
gemäß der vorliegenden
Erfindung,
-
4 zeigt
die Zuordnung von Daten beim Dienstanbieter gemäß der vorliegenden Erfindung,
-
5 zeigt
die Zuordnung von Daten beim Client gemäß der vorliegenden Erfindung,
und
-
6 zeigt
die Zuordnung von Daten beim Identitätsanbieter gemäß der vorliegenden
Erfindung.
-
Beschreibung der bevorzugten
Ausführungsformen
-
Zur
Beschreibung von bevorzugten Ausführungsformen wird ohne Beabsichtigung
einer Einschränkung
der vorliegenden Erfindung Bezug auf die LAP-Spezifikationen genommen,
um die vorliegende Erfindung verständlich zu machen. Daher werden
Abkürzungen,
die im Folgenden verwendet werden, im Vorgenannten definiert oder
sind unter den LAP-Verweisen, die zu Beginn genannt wurden, zu finden.
-
Gemäß dem Verfahren
zur Dienstanbieter-Anonymisierung in Einmalanmeldungs-Verfahren
kaschiert der Client den Namen oder die Kennung SP-Name des Dienstanbieters
SP, indem bei Datenübertragungen mit
dem Identitätsanbieter
IdP ein Pseudonym oder ein Alias SP-PN verwendet wird. Der Client
verwendet vorzugsweise den gleichen SP-PN für den gleichen Dienstanbieter
SP. Der SP-PN sollte so gewählt
werden, dass er keine Verbindung der Identität, z.B. dem wirklichen Namen
(SP-Name) des Dienstanbieters SP, mit dem SP-Alias SP-PN gestattet.
Der Nachrichtenaustausch zur Authentifikation erfolgt so, ("Vorkanal"), dass kein direkter
Nachrichtenaustausch zwischen dem Dienstanbieter SP und dem Identitätsanbieter
IdP stattfindet, damit der Identitätsanbieter IdP den Dienstanbieter
SP nicht identifizieren kann.
-
Vorzugsweise
hängt die
Kaschierung auch von der IdP-ID ab, die der Benutzer wählt, wenn
er sich gegenüber
dem Identitätsanbieter
IdP identifiziert. Dies bietet einige Vorteile. Zum Beispiel kann
ein Benutzer sich dafür
entscheiden, verschiedene Identitäten bei dem gleichen Identitätsanbieter
IdP oder bei verschiedenen IdPs zu verwenden, z.B. für geschäftliche,
private, persönliche
Zwecke usw. Wenn der SP-PN unabhängig von
der IdP-ID wäre,
könnte
der Identitätsanbieter
IdP in der Lage sein, die verschiedenen Authentifikationen – unter
Verwendung verschiedener IdPs – auf
Grund der Tatsache verknüpfen,
dass der gleiche SP-PN verwendet wird. Die IdP-ID-abhängige Kaschierung
vermeidet solche Probleme. Des Weiteren könnte das gleiche Problem auftreten,
wenn sich verschiedene Benutzer die gleiche Endbenutzer-Einheit
teilen, aber verschiedene Identitäten verwenden.
-
Kaschieren
kann in einer der folgenden beispielhaften Weisen ausgeführt werden:
Gemäß einem
ersten Beispiel für
Kaschierung erstellt der Client einen Speicher, (z.B. in Form einer
Tabelle oder Datenbank), wobei jeder Eintrag die drei Felder SP-Name,
IdP-ID und SP-PN enthält.
Immer wenn eine Zuordnung von einem SP-PN und einer IdP-ID zu einem
SP-PN ausgeführt
werden muss, fragt der Client die Tabelle nach einem Eintrag ab,
der den angegebenen SP-Name und die IdP-ID enthält. Wenn ein Eintrag gefunden
wird, wird der entsprechende SP-PN zurückgegeben. Anderenfalls wird
ein neuer SP-PN erstellt, (z.B. pseudozufällig), und ein neuer Eintrag
in der Tabelle oder Datenbank wird erstellt, der den angegebenen SP-Name,
die IdP-ID und den neu erstellten SP-PN enthält.
-
Gemäß einem
zweiten Beispiel für
die Kaschierung erhält
der Client anfänglich
einen geheimen Schlüssel,
(z.B. unter Verwendung eines Pseudozufallsgenerators oder alternativ
eines festen Schlüssels,
der bei der Herstellung auf einer Chipkarte gespeichert wird), und
speichert ihn so, dass er vor unberechtigtem Zugriff geschützt ist.
Für jeden
angegebenen SP-Name wendet der Client einen Verschlüsselungsalgorithmus auf
SP-Name und IdP-ID unter Verwendung des dauerhaften geheimen Schlüssels an,
um den sich daraus ergebenden SP-PN zu erhalten. Der verwendete
Verschlüsselungsalgorithmus
sollte vorzugsweise vor bekannten Klartextangriffen sowie vor bestimmten
Klartextangriffen geschützt
sein.
-
Unter
Bezugnahme auf 2 wird eine Situation beschrieben,
in der eine Account-Verknüpfung,
wie im Fachgebiet z.B. von LAP bekannt, zwischen dem Dienstanbieter
SP und dem Identitätsanbieter
IdP für
den Principal bereits stattgefunden hat.
-
Der
Client fordert vom Dienstanbieter SP Zugriff auf einen Dienst an
(Schritt 1).
-
Der
Dienstanbieter SP fordert die Principal-Authentifikation an, indem eine Authentifikationsanforderung
an den Client gesendet wird. Die Authentifikationsanforderung kann
den SP-Namen angeben (Schritt 2).
-
Der
Client ordnet den echten Namen SP-Name des Dienstanbieters SP, (z.B.
service1.com), und vorzugsweise die IdP-ID einem Alias SP-PN gemäß einem
der im oben genannten Schritt beschriebenen Verfahren zu (Schritt 3).
-
Der
Client fordert den Identitätsanbieter
auf, ihn zu authentifizieren (Schritt 4). Die Authentifikationsanforderung
enthält
das Alias SP-PN des Dienstanbieters SP, für den der Client die Authentifikation
angefordert hat. Die Anforderung enthält auch die IdP-ID, unter welcher
der Principal beim Identitätsanbieter
IdP bekannt ist.
-
Der
Identitätsanbieter
IdP identifiziert und authentifiziert den Principal als IdP-ID (Schritt 5).
Dies umfasst typischerweise die Verifizierung von Berechtigungsnachweisen,
wie beispielsweise ein Passwort, einen geheimen Schlüssel oder
Sonstiges.
-
Dann
ruft der Identitätsanbieter
IdP die ALIAS-ID für
den Principal, die von dem Dienstanbieter SP verwendet werden soll,
der unter dem Alias SP-PN bekannt ist, von einer Datenbank ab (Schritt 6).
Eine geeignete Datenbank enthält
Einträge
von IdP-IDs, SP-PNs und ALIAS-IDs in einer korrelierten Weise, so
dass der Identitätsanbieter
IdP weiß,
welche ALIAS-ID für
welche Kombination von IdP-ID und SP-PN verwendet werden soll oder
damit verknüpft
ist.
-
Die
Identitätsanbieter
IdP sendet eine Authentifikationsantwort, welche die ALIAS-ID umfasst,
an den Client (Schritt 7), z.B. eine digital signierte
Bestätigung
der Authentifikation des Principal.
-
Der
Client leitet die Authentifikationsantwort an den Dienstanbieter
SP weiter (Schritt 8).
-
Der
Dienstanbieter SP verifiziert dann die Authentifikationsantwort
und fragt die SP-ID aus seiner Datenbank ab, die der ALIAS-ID in
der Authentifikationsantwort entspricht (Schritt 9).
-
Schließlich beginnt
der Dienstanbieter SP damit, den angeforderten (und potenziell kundenspezifischen)
Dienst für
den Client bereitzustellen (Schritt 10). Ausgehend von der
Kenntnis der SP-ID kann der Dienst kundenspezifisch sein.
-
3 zeigt
einen Nachrichtenfluss für
den Fall, dass vorher keine Account-Verknüpfung stattgefunden hat, diese
aber erwünscht
ist, (z.B. ein "Federate"-Flag weist den Wert "wahr" in der LAP-1.0-Authentifikationsanforderung
auf).
-
Die
Schritte 1 bis 5 können in dem oben beschriebenen
Fall identisch sein.
-
In
Schritt 6 findet der Identitätsanbieter IdP keinen Eintrag
für die
angegebene IdP-ID und den SP-PN. Er erhält daher z.B. durch Generieren
eine neue ALIAS-ID, (zufällig
oder vorzugsweise unverknüpfbar
mit der IdP-ID oder anderen persönlichen
Benutzerdaten), und fügt
einen Eintrag (IdP-ID,
SP-PN, ALIAS-ID) zu seinem Speicher hinzu (Schritt 7) und
erhält
damit den IdP-bezogenen Teil der Account-Verknüpfung.
-
Der
Identitätsanbieter
IdP sendet die Authentifikationsantwort, welche die ALIAS-ID und
die Bestätigung
enthält,
an den Client (Schritt 8), der die Authentifikationsantwort
an den Dienstanbieter SP weiterleitet (Schritt 9).
-
In
Schritt 10 kann der Dienstanbieter SP keinen Eintrag für die ALIAS-ID,
(die von dem Identitätsanbieter
IdP neu generiert worden ist), in seiner Datenbank finden, d.h.
er kann die empfangene Authentifikation nicht mit irgendeinem bekannten
Principal SP-ID verknüpfen.
Daher bestimmt er die Principal-Identität, z.B. durch Abfragen des
Principal nach einem Benutzernamen (= SP-ID) und einem Passwort.
Wenn der Principal alternativ keinen bestehenden Account bei dem
Dienstanbieter SP hat, könnte
der Principal aufgefordert werden, sich für einen neuen Account zu registrieren.
Der Dienstanbieter SP erstellt einen neuen Eintrag in seiner Datenbank
mit der SP-ID des Principal und der ALIAS-ID, die von dem Identitätsanbieter
IdP empfangen wurde (Schritt 13).
-
Vorzugsweise
würde ein
neuer Eintrag in der Datenbank des Dienstanbieters SP die Form (SP-ID, IdP-Name,
ALIAS-ID) aufweisen, wobei IdP-Name ein eindeutiger Name ist, der
den Identitätsanbieter
IdP identifiziert. Der Grund dafür
ist, dass typischerweise nicht gewährleistet wäre, dass von verschiedenen
IdPs erstellte ALIAS-IDs über
einen gesamten Verbund eines "vertrauenswürdigen Kreises" eindeutig sind.
Wenn sich der IdP-Name daher nicht in dem Datenbankeintrag befindet,
wäre eine
eindeutige Zuordnung von einer ALIAS-ID zu einer SP-ID nicht gewährleistet.
-
Schließlich beginnt
der Dienstanbieter SP wie vorher mit der Bereitstellung der angeforderten
kundenspezifischen Dienste für
den Client (Schritt 14). Wenn sich der Principal das nächste Mal
für diesen
Dienst einloggt, wird der vom Identitätsanbieter IdP bereitgestellte
SSO-Dienst erkannt, und es muss kein Benutzername/Passwort für den Dienstanbieter
SP bereitgestellt werden (siehe 2), d.h.
sobald die Account-Verknüpfung
gemäß 3 ausgeführt ist,
kann die SSO gemäß dem unter
Bezugnahme auf 2 beschriebenen Verfahren ausgeführt werden.
-
Im
Folgenden werden Zuordnungen zwischen verschiedenen Daten, die von
den beteiligten Entitäten und
verwendeten Datenstrukturen (Tabellen) ausgeführt werden müssen, als
Beispiele veranschaulicht.
-
Gemäß
4 ordnet
der Dienstanbieter (SP) eine ALIAS-ID, (die von dem Identitätsanbieter
IdP empfangen wurde, zu einer SP-ID zu.
4 veranschaulicht
eine Zuordnung für
die folgende Tabelle:
-
Wie
oben beschrieben, kann die Tabelle den IdP-Name als ein zusätzliches
Feld, muss ihn aber nicht enthalten.
-
Gemäß
5 erhält der Client
kaschierte Daten, z.B. durch Zuordnung eines SP-Name und einer IdP-ID
zu einem SP-PN. Wie oben beschrieben, kann dies z.B. erreicht werden
unter Verwendung von kryptografischen Techniken, (Verschlüsselung
von SP-Name und IdP-ID) oder durch eine Tabellensuche. Für die folgende
Tabelle stellt
5 eine Veranschaulichung einer
entsprechenden Zuordnung bereit:
-
Der
Identitätsanbieter
(IdP) ordnet ein angegebenes Paar (IdP-ID, SP-PN) zu einer ALIAS-ID
zu, die in
6 für die folgende Tabelle veranschaulicht
wird:
-
Eine
Verarbeitung und entsprechender Datenfluss gemäß der Erfindung kann wie folgt
beschrieben werden:
Der Principal mit der IdP-ID "
[email protected]" fordert Dienst vom
SP mit dem SP-Name "servicel.com" an. Zur Authentifikation
des Principal beim IdP mit dem IdP-Name "mno.com" erhält
der Principal die kaschierten Daten "k6TgF45u23Rp", die z.B. in seiner Datenbank in Korrelation
mit dem SP-Name "servicel.com" und mit der IdP-ID "
[email protected]" gefunden werden
können.
Der SP-PN "k6TgF45u23Rp" und die IdP-ID "
[email protected]" werden zu dem IdP
gesendet. Der IdP identifiziert den Principal basierend auf der IdP-ID "
[email protected]" und erhält die ALIAS-ID "a5Db323425GB", die in Korrelation
zu der entsprechenden IdP-ID "
[email protected]" und dem SP-PN "k6TgF45u23Rp" steht. Die ALIAS-ID "a5Db323425GB" wird zum Client
gesendet, der die ALIAS-ID "a5Db323425GB" zum SP "servicel.com" weiterleitet. Der
SP "servicel.com" kann die Identität des Principal,
d.h. die SP-ID "bobby", basierend auf der
von der Datenbank empfangenen ALIAS-ID "a5Db323425GB" ermitteln.
-
Im
Folgenden wird die Beschreibung von Funktionen/Protokollen der drei
beteiligten Entitäten
(SP. IdP, Client) ausführlicher
dargelegt, wobei auf LAP 1.0 verwiesen wird. Des Weiteren sollte
angemerkt werden, dass im Folgenden die Begriffe Client und Principal
synonym verwendet werden.
-
Dienstanbieter
-
Der
Dienstanbieter SP empfängt
eine Dienstanforderung vom Client, für die eine Authentifikation
notwendig ist, z.B. ein HTTP Get. Danach wird eine Authentifikationsanforderung
an den Client zurückgesendet, ähnlich der
Prozedur in LAP 1.0. Details dieser Prozedur können voneinander abweichen,
was vom Profil in LAP 1.0 abhängt.
Zum Beispiel kann eine HTTP-Umleitung oder eine SOAP-Nachricht an
den Client verwendet werden. Des Weiteren kann die Authentifikationsanforderung
unter Verwendung einer vertrauenswürdigen Gruppenkennung signiert
werden, die angibt, dass der Dienstanbieter zu einer Gruppe vertrauenswürdiger dienstanbietender
Entitäten
gehört.
-
Anschließend wartet
der Dienstanbieter SP darauf, eine Authentifikationsantwort, die
von einem vertrauenswürdigen
Identitätsanbieter
IdP signiert ist, vom Client zu empfangen. Zur Verifizierung der
Bestätigung kann
der Dienstanbieter zum Beispiel die Signatur des Identitätsanbieters
IdP und dergleichen prüfen.
Die Authentifikationsantwort bestätigt dem Client, der unter
der ALIAS-ID bekannt sein soll, auf die er geprüft wird, ob ein entsprechender
Speichereintrag vorhanden ist. Als Option kann ein IdP-Name in die
ALIAS-ID aufgenommen oder mit dieser verknüpft werden, auf die entsprechende
Speichereinträge
geprüft
werden können.
-
Im
Fall eines Speichereintrags ruft der Dienstanbieter SP die entsprechende
SP-ID aus dem Speicher ab. Optional kann der Dienstanbieter SP des
Weiteren spezifische Profilinformationen für den Client abrufen, der gegenwärtig einen
Dienst anfordert, zum Beispiel ein kundenspezifisches Portal, Zugriff
auf ein Bankkonto und dergleichen.
-
Wenn
der mit dem Dienstanbieter SP verknüpfte Speicher keinen Speichereintrag
für die
gegenwärtige
ALIAS-ID bereitstellt, kann der Dienstanbieter SP zum Beispiel ein
HTML-Formular an den Client senden und einen vorhandenen Benutzernamen
und/oder Passwort anfordern. Als Alternative kann der Dienstanbieter SP
den Client auffordern, sich als neuer Client zu registrieren. Nach
dem Abruf entsprechender Informationen, (zum Beispiel Benutzername
und/oder Passwort), erstellt der Dienstanbieter SP einen entsprechenden
Speichereintrag (ALIAS-ID, SP-ID, optional IdP-Name) in seinem Speicher,
wobei die SP-ID dem Benutzernamen oder irgendwelchen ähnlichen
Client-Identifizierungsdaten
entspricht, die zum Beispiel mit einem Benutzernamen verknüpft sind.
-
Dann
antwortet der erste Anbieter SP auf die anfängliche Dienstanforderung von
dem Client, indem der angeforderte Dienst bereitgestellt wird, der
in einer für
den Principal angepassten Weise durchgeführt werden kann.
-
Client
-
Ein
Benutzer, der einen Dienst des Dienstanbieter SP verwenden möchte, sendet
eine Dienstanforderung, zum Beispiel ein HTTP Get unter Verwendung
eines Client. Hier kann der Benutzer des Client zum Beispiel eine
entsprechende Verknüpfung
auswählen
oder eine URL in den Browser eingeben. In Reaktion darauf empfängt der
Client eine Authentifikationsanforderung, zum Beispiel eine SOAP-Nachricht, von dem
Dienstanbieter SP.
-
Der
Client kennt den Namen SP-Name des Dienstanbieters SP typischerweise
als Domäne
oder Host-Namen. Diese Kenntnis des Client kann zum Beispiel aus
dem gesendeten HTTP Get oder aus der empfangenen SOAP-Nachricht
erhalten werden. Es ist möglich,
dass der Client auch die IdP-ID kennt, zum Beispiel aus einer direkten
Abfrage des Clients an seinen Benutzer.
-
Dann
kaschiert der Client den Dienstanbieter-Namen SP-Name, um ein Dienstanbieter-Alias
SP-PN zu erhalten. Zu diesem Zweck kann der Client einen Speicher
verwenden, (z.B. eine Tabelle oder eine Datenbank), die den Dienstanbieter-Namen
SP-Name (und optional die IdP-ID) und einen entsprechenden kaschierten
Dienstanbieter-Namen SP-PN verknüpft.
Der Client kann ein neues Dienstanbieter-Alias SP-PN erstellen, zum
Beispiel unter Verwendung eines Zufallszahlengenerators, für den Fall,
dass der Speicher keinen entsprechenden Eintrag bereitstellt. Als
Alternative kann der Client einen permanent gespeicherten geheimen
Schlüssel
verwenden, um den Dienstanbieter-Namen SP-Name (und optional die
IdP-ID) zu verschlüsseln.
Das Ergebnis dieser Prozedur ist ein Dienstanbieter-Alias SP-PN
in Form eines verschlüsselten
Dienstanbieternamens.
-
Dann
sendet der Client eine Authentifikationsanforderung an den Identitätsanbieter
IdP, zum Beispiel als SOAP-Nachricht,
verwendet aber das Dienstanbieter-Alias SP-PN statt des wirklichen
Dienstanbieter-Namens SP-Name.
-
Anschließend wartet
der Client darauf, von dem Identitätsanbieter IdP einen Authentifikationsantwort zu
empfangen.
-
In
dem Fall, in dem der Client Informationen benötigt, die angeben, zu welchem
Dienstanbieter die Authentifikationsantwort von dem Identitätsanbieter
IdP gesendet werden soll, sind einige Optionen möglich. Die Authentifikationsanforderung
von dem Client kann eine Sitzungskennung, welche in der Authentifikationsantwort
von dem Identitätsanbieter
IdP zurückgegeben
wird, umfassen, auf deren Basis der Client die Authentifikationsantwort
mit der fraglichen Authentifikationsanforderung verknüpfen kann.
Zum Beispiel kann der Client einen Speicher verwenden, um die zurückgegebene
Sitzungskennung mit dem entsprechenden Dienstanbieter zu verknüpfen. Des
Weiteren ist es möglich,
dass die Authentifikationsantwort von dem Identitätsanbieter
IdP den kaschierten Dienstanbieter-Namen SP-PN enthält. Dann
kann der Client die Kaschierung des Dienstanbieter-Alias SP-PN im
Hinblick auf Verfahren aufheben, die zum Erstellen des Dienstanbieter-Alias SP-PN
verwendet werden, zum Beispiel unter Verwendung von Speichereinträgen, welche
den Dienstanbieter-Namen SP-Name und das entsprechende Dienstanbieter-Alias
SP-PN korrelieren, oder durch Entschlüsseln des Dienstanbieter-Alias SP-PN in dem
Fall, in dem Verschlüsselungsverfahren
verwendet worden sind.
-
Dann
leitet der Client die Authentifikationsantwort, welche die ALIAS-ID
des Identitätsanbieters
IdP umfasst, an den Dienstanbieter SP weiter.
-
Identitätsanbieter
-
Der
Identitätsanbieter
IdP empfängt
eine Authentifikationsanforderung vom Client, wie beispielsweise vorher
dargelegt, in Form einer SOAP-Nachricht. Die Authentifikationsanforderung
enthält
den kaschierten Dienstanbieter-Namen SP-PN.
-
In
dem Fall, in dem der Dienstanbieter SP seine oben genannte vertrauenswürdige Gruppenkennung zum
Client überträgt, ist
es möglich,
dass die Authentifikationsanforderung vom Client die vertrauenswürdige Gruppenkennung
enthält.
Dann authentifiziert der Identitätsanbieter
IdP optional auch den Dienstanbieter durch Verifizieren der vertrauenswürdigen Gruppenkennung.
Hier gibt eine erfolgreiche Verifizierung an, dass jeweils die Authentifikationsanforderung
vom Dienstanbieter SP und die Authentifikationsanforderung vom Client
von einem Dienstanbieter stammt, der zu einer Gruppe vertrauenswürdiger Dienstanbieter
gehört.
-
Diese
Prozedur verbessert die Authentifikation, gibt aber die Identität des Dienstanbieters
nicht preis, da der Identitätsanbieter
IdP keinen Zugriff auf irgendwelche Informationen hat, welche den
Dienstanbieter SP identifizieren oder das Dienstanbieter-Alias SP-PN
in Korrelation zum Dienstanbieter SP bringen.
-
Zum
Identifizieren und anschließenden
Authentifizieren des Client fordert der Identitätsanbieter IdP geeignete Informationen
an, die vom Client bereitzustellen sind. Dies kann durch Anfordern
eines Benutzernamens (= IdP-ID) und/oder eines Passworts erfolgen.
-
Wenn
in einem Speicher, (zum Beispiel in Form einer Tabelle oder Datenbank),
die mit dem Identitätsanbieter
IdP verknüpft
sind, ein Eintrag für
das empfangene Dienstanbieter-Alias SP-PN und die Client-Identität IdP-ID
vorhanden ist, erhält
der Identitätsanbieter
IdP ein entsprechendes Client-Alias ALIAS-ID für diesen Client.
-
Wenn
dieser Speicher keinen solchen Eintrag enthält, erstellt der Identitätsanbieter
IdP für
das empfangene Dienstanbieter-Alias SP-PN und die Client-Identität IdP-ID
ein neues Client-Alias ALIAS-ID, zum Beispiel unter Verwendung eines
(Pseudo-)Zufallszahlengenerators. Das neu generierte Client-Alias
ALIAS-ID wird dann als neuer Speichereintrag gespeichert, der das
Dienstanbieter-Alias SP-PN und die Client-Identität IdP-ID
mit einem entsprechenden Client-Alias ALIAS-ID korreliert.
-
Dann
gibt der Identitätsanbieter
IdP eine Authentifikationsantwort, zum Beispiel als SOAP-Nachricht, an
den Client zurück,
um zu bestätigen,
dass der Client als ALIAS-ID authentifiziert worden ist. Vorzugsweise signiert
der Identitätsanbieter
IdP die Authentifikationsantwort aus Gründen einer erhöhten Sicherheit.
-
Die
vorgenannten Ausführungsformen
und das folgende Glossar sind als veranschaulichend und als nicht
einschränkend
für die
Erfindung zu betrachten, und die Modifizierungen, die innerhalb
des Bedeutungs- und Entsprechungsbereichs der Ansprüche liegen,
sind hierin einzuschließen.
-
GLOSSAR
-
-
- SSO:
- Einmalanmeldung (Single
Sign-On)
- LAP:
- Liberty Alliance Project
- Benutzer:
- Person
- Principal:
- Entität, z.B.
in einem SSO-System, die eine oder mehrere Identitäten hat;
typischerweise die Entsprechung zu einem Benutzer, doch kann ein
Benutzer durch einen oder mehrere Principals verkörpert werden,
und einer oder mehrere Benutzer können durch einen Principal
verkörpert
werden. Ein Principal kann verschiedene Identitäten bei verschiedenen Entitäten haben,
z.B. eine erste Identität
SP-ID beim SP und eine zweite Identität IdP-ID beim IdP. Eine oder
mehrere Kennungen können
verwendet werden, um eine Identität des Principal bei der jeweiligen
Entität
zu identifizieren. Der Einfachheit halber wird in der Beschreibung
keine Unterscheidung zwischen der Identität des Principal beim SP und der
Kennung getroffen, welche die Identität des Principal beim SP angibt.
Beide, sowohl die Identität
als auch die korrelierte Kennung werden als SP-ID bezeichnet. Die
Identität des
Principal beim IdP und die korrelierte Kennung werden entsprechend
behandelt, d.h. beide werden als IdP-ID bezeichnet.
- Client:
- Hardware und/oder
Software, typischerweise eine Vorrichtung des Benutzers und/oder
ein Web-Browser
- SP:
- Dienstanbieter, Beispiel
für die
zweite Entität
- IdP:
- Identitätsanbieter,
Beispiel für
die dritte Entität
- IdP-Name:
- Name des IdP, Beispiel
für Daten,
welche die dritte Entität identifizieren
- IdP-ID:
- Identität des Principal
beim IdP, Beispiel für
Daten, welche die erste Entität
gegenüber
der dritten Entität
identifizieren
- SP-Name:
- Name des SP, Beispiel
für Daten,
welche die zweite Entität identifizieren
- SP-ID:
- Identität des Principal
beim SP, Beispiel für
Daten, welche die erste Entität
gegenüber
der zweiten Entität
identifizieren
- SP-PN:
- Kennung, z.B. ein
Pseudonym oder Alias für
einen SP bei einem IdP, Beispiel für Daten, welche die zweite
Entität
gegenüber
der dritten Entität
charakterisieren, ohne die Identität der zweiten Entität (z.B.
den SP-Name) für
wenigstens die dritte Entität
preiszugeben
- ALIAS-ID:
- Kennung, z.B. Pseudonym
oder Alias für
einen Principal beim SP, Beispiel für Daten, welche die erste Entität gegenüber der
zweiten Entität
charakterisieren, vorzugsweise ohne die Identität der ersten Entität preiszugeben
- Vertrauenswürdige Gruppenkennung:
- Daten, die angeben,
dass eine Entität
zu einer Gruppe von vertrauenswürdigen
Entitäten
gehört
- Erste vertrauenswürdige Gruppen-Kennung:
- Daten, die angeben,
dass die zweite Entität
zu einer Gruppe von vertrauenswürdigen
Entitäten
gehört,
die für
wenigstens die dritte Entität
vertrauenswürdig
sind, ohne die Identität
der zweiten Entität
für wenigstens
die dritte Entität preiszugeben
- Zweite vertrauenswürdige Gruppen-Kennung:
- Daten, die angeben,
dass die erste Entität
zu einer Gruppe von vertrauenswürdigen
Entitäten
gehört,
die für
wenigstens die dritte Entität
vertrauenswürdig
sind