DE60308733T2

DE60308733T2 - Dienstanbieteranonymisierung in einem single sign-on system

Info

Publication number: DE60308733T2
Application number: DE60308733T
Authority: DE
Inventors: Axel Busboom
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2003-02-21
Filing date: 2003-02-21
Publication date: 2007-08-09
Anticipated expiration: 2023-02-22
Also published as: DE60308733D1; WO2004075035A1; US20060155993A1; EP1595190B1; EP1595190A1; AU2003212261A1

Description

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

Claims

Verfahren zum Anmelden in einer netzwerkbasierten Datenübertragungsumgebung, wobei Authentifikation einer ersten Entität von einer zweiten Entität angefordert wird, um auf einen Dienst zuzugreifen, der von der zweiten Entität (SP) für die erste Entität bereitgestellt werden soll, wobei die Authentifikation durch eine dritte Entität (IdP) bereitgestellt wird, dadurch gekennzeichnet, dass das Verfahren die folgenden Schritte umfasst: – Kaschieren gegenüber der dritten Entität (IdP) von Daten, welche die zweite Entität (SP) identifizieren, indem die Daten modifiziert werden, welche die zweite Entität (SP) identifizieren, so dass die dritte Entität (IdP) nicht ableiten kann, auf welche Entität sich die kaschierten Daten beziehen, die dritte Entität (IdP) aber erkennen würde, wenn kaschierte Daten, die sich auf die gleiche Entität beziehen, wiederholt empfangen werden; und – Bereitstellen der kaschierten Daten für die dritte Entität (IdP).
Verfahren nach Anspruch 1, das für Einmalanmeldung in der netzwerkbasierten Datenübertragungsumgebung verwendet wird.
Verfahren nach Anspruch 1 oder 2, umfassend den Schritt des: – Übertragens einer Dienstanforderung von der ersten Entität zu der zweiten Entität (SP).
Verfahren nach einem der vorhergehenden Ansprüche, umfassend die Schritte des: – Übertragens von wenigstens einem von einer ersten Authentifikationsanforderung und einer ersten vertrauenswürdigen Gruppenkennung von der zweiten Entität (SP) zu der ersten Entität, wobei die erste Authentifikationsanforderung von der ersten Entität zu der zweiten Entität (SP) zuordenbar ist, und die erste vertrauenswürdige Gruppenkennung eine Gruppe von vertrauenswürdigen Entitäten angibt, zu welcher die zweite Entität (SP) gehört.
Verfahren nach einem der vorhergehenden Ansprüche, wobei Kaschieren der Daten, welche die zweite Entität (SP) charakterisieren, wenigstens einen der folgenden Schritt umfasst: – Kaschieren durch Mittel der ersten Entität, und – Kaschieren unter Verwendung eines Speichers, der mit der ersten Entität verknüpft ist, und – Kaschieren unter Verwendung von kryptografischen Techniken, und – Kaschieren unter Verwendung von Daten, welche die zweite Entität (SP) identifizieren, und – Kaschieren unter Verwendung von Daten, welche die erste Entität gegenüber der dritten Entität (IdP) identifizieren.
Verfahren nach einem der vorhergehenden Ansprüche, umfassend den Schritt des: – Erhaltens von Daten, welche die dritte Entität (IdP) identifizieren, und Übertragen einer zweiten Authentifikationsanforderung von der ersten Entität zu der dritten Entität (IdP), wobei die zweite Authentifikationsanforderung die kaschierten Daten und die Daten, welche die erste Entität gegenüber der dritten Entität (IdP) identifizieren, enthält oder von diesen begleitet wird.
Verfahren nach Anspruch 6, wobei die Daten, welche die erste Entität gegenüber der dritten Entität (IdP) identifizieren, eine zweite vertrauenswürdige Gruppenkennung sind oder von dieser begleitet werden, welche angibt, dass die erste Entität zu einer Gruppe von vertrauenswürdigen Entitäten gehört.
Verfahren nach Anspruch 6 oder 7, soweit es von Anspruch 4 abhängt, wobei die zweite Authentifikationsanforderung die erste vertrauenswürdige Gruppenkennung umfasst oder von dieser begleitet wird.
Verfahren nach einem der Ansprüche 6 bis 8, umfassend den Schritt des: – Authentifizierens der ersten Entität durch die dritte Entität (IdP) unter Verwendung von wenigstens den Daten, welche die erste Entität gegenüber der dritten Entität (IdP) identifizieren.
Verfahren nach einem der Ansprüche 7 oder 9, umfassend den Schritt des: – Authentifizierens der ersten Entität durch die dritte Entität (IdP) unter Verwendung von wenigstens der zweiten vertrauenswürdigen Gruppenkennung.
Verfahren nach einem der Ansprüche 6 bis 10, soweit es von Anspruch 4 abhängt, umfassend den Schritt des: – Authentifizierens der zweiten Entität (SP) durch die dritte Entität (IdP) unter Verwendung der ersten vertrauenswürdigen Gruppenkennung.
Verfahren nach einem der Ansprüche 6 bis 11, umfassend den Schritt des: – Erhaltens durch die dritte Entität (IdP), in Reaktion auf die zweite Authentifikationsanforderung, von Daten, welche die erste Entität gegenüber der zweiten Entität (SP) charakterisieren unter Verwendung der modifizierten Daten und der Daten, welche die erste Entität gegenüber der dritten Entität (IdP) identifizieren.
Verfahren nach einem der vorhergehenden Ansprüche, umfassend den Schritt des: – Übertragens, von der dritten Entität (IdP) zu der ersten Entität, einer ersten Authentifikationsantwort, welche wenigstens die Daten enthält, welche die erste Entität gegenüber der zweiten Entität (SP) charakterisieren, oder von diesen begleitet wird.
Verfahren nach Anspruch 13, umfassend den Schritt des: – Signierens der ersten Authentifikationsantwort durch die dritte Entität (IdP) mit einer Signatur zur Authentifikation der dritten Entität (IdP) gegenüber der zweiten Entität (SP).
Verfahren nach Anspruch 13 oder 14, umfassend den Schritt des: – Übertragens einer zweiten Authentifikationsantwort von der ersten Entität zu der zweiten Entität (SP), wobei die zweite Authentifikationsantwort die Daten enthält oder von diesen begleitet wird, welche die erste Entität gegenüber der zweiten Entität (SP) charakterisieren und von der zweiten Entität (SP) zu der Authentifikation zuordenbar sind, die von der zweiten Entität (SP) angefordert wurde.
Verfahren nach einem der vorhergehenden Ansprüche, umfassend den Schritt des: – wenn die zweite Authentifikationsantwort von der zweiten Entität (SP) akzeptiert wird, Übertragens einer Dienstantwort von der zweiten Entität (SP) zu der ersten Entität, wobei die Dienstantwort angibt, dass es der ersten Entität gestattet ist, auf den Dienst zuzugreifen.
Verfahren nach Anspruch 16, wobei der Akzeptierungsschritt den folgenden Schritt umfasst: – Erhalten durch die zweite Entität (SP) von Daten, welche die erste Entität gegenüber der zweiten Entität (SP) identifizieren, wobei die Daten, welche die erste Entität gegenüber der zweiten Entität (SP) identifizieren, mit den Daten in Beziehung stehen, welche die erste Entität gegenüber der zweiten Entität (SP) charakterisieren.
Computerprogramm-Produkt, umfassend Software-Code-Abschnitte zum Ausführen der Schritte gemäß einem von den Ansprüchen 1 bis 17, wenn das Computerprogramm-Produkt auf einer Rechenvorrichtung ausgeführt wird.
Entität zur Verwendung in einer Anmeldung in einer netzwerkbasierten Datenübertragungsumgebung, wobei die Entität ausgelegt ist zum: – Empfangen einer Authentifikationsanforderung von einer zweiten Entität (SP) zum Zugreifen auf einen Dienst, der für die Entität von der zweiten Entität (SP) bereitgestellt werden soll, wobei die Authentifikationsanforderung zur Authentifizierung der Entität an eine dritte Entität (IdP) gerichtet ist und Daten umfasst, welche die zweite Entität (SP) identifizieren; dadurch gekennzeichnet, dass die Entität des Weiteren ausgelegt ist zum: – Kaschieren gegenüber der dritten Entität (IdP) von Daten, welche die zweite Entität (SP) identifizieren, indem die Daten, welche die zweite Entität (SP) identifizieren, so modifiziert werden, dass die dritte Entität (IdP) nicht ableiten kann, auf welche Entität sich die kaschierten Daten beziehen, die dritte Entität (IdP) aber erkennen würde, wenn kaschierte Daten, die sich auf die gleiche Entität beziehen, wiederholt empfangen werden; und – Senden der kaschierten Daten zu der dritten Entität (IdP).
Entität nach Anspruch 19, die so ausgelegt ist, dass sie als erste Entität betrieben werden kann, von welcher Authentifikation von der zweiten Entität (SP) angefordert wird.
Entität nach Anspruch 19 oder 20, die eine computerbasierte Einheit ist.
Entität nach Anspruch 21, umfassend eine Empfangseinheit zum Empfangen der Authentifikationsanforderung.
Entität nach Anspruch 21 oder 22, umfassend eine Verarbeitungseinheit zum Modifizieren der Daten, welche die zweite Entität (SP) identifizieren.
Entität nach den Ansprüchen 21 bis 23, umfassend eine Sendeeinheit zum Senden der kaschierten Daten zu der dritten Entität (IdP).
Datenübertragungsumgebung, umfassend: – eine erste Entität, – eine zweite Entität (SP), die so ausgelegt ist, dass sie Authentifikation der ersten Entität für das Zugreifen auf einen Dienst anfordert, der von der zweiten Entität (SP) für die erste Entität bereitgestellt werden soll, – eine dritte Entität (IdP), die so ausgelegt ist, dass sie Authentifikation der ersten Entität bereitstellt, und – ein Netzwerk von Datenübertragungen zwischen der ersten, der zweiten und der dritten Entität, dadurch gekennzeichnet, dass – die erste Entität die Entität gemäß einem der Ansprüche 19 bis 24 ist.
Datenübertragungsumgebung nach Anspruch 25, wobei: – die erste, die zweite und die dritte Entität wie in Anspruch 20 dargelegt betrieben werden.