Webmail-Accounts ermöglichen im Internet, auch bei der Kommunikation anonym zu bleiben. In vielen Fällen erfüllen diese Gratis-Mailadressen ihren Zweck, betrachtet man einmal die Versuche von Werbeagenturen, ihre Spam-Mail an Adressaten zu senden, deren Mailadresse man in Internet-Foren finden kann. Wer heute in einer Newsgroup zu einem seriösen Thema mitdiskutieren möchte, ist gut beraten, seine Absender-Adresse zu verschleiern, da ansonsten ein Business-Account sehr schnell zum Mülleimer für Werbemails werden kann.

Anonymität im Internet hat aber auch ihre Schattenseiten. Wenn das Netz jemanden nicht "erkennt", "vertraut" es ihm auch nicht. Anwender müssen sich folglich bei allen Diensten, auf denen man eine Zugangs-Berechtigung erworben hat, neu authentisieren. Außerdem können Services nicht Web-basierend miteinander kooperieren, da „ihr“ Nutzer in einer Web-Session nur ihnen selbst bekannt ist.

In diese Lücke entwickeln sich derzeit die verschiedenen Identity-Management Konzepte wie Microsofts Passport und die vom Herstellerkonsortium Liberty Alliance entwickelten Spezifikationen. Ziel ist es, Vertrauens-Umfelder zu schaffen, in denen sich ein Anwender anmeldet und in denen er sofort und ohne weitere Authentisierung alle Dienstleistungen der verschiedenen Anbieter vorfindet.

Wer informiert mich?

Ein typischer Anwender, der sich im Internet für verschiedene Dienstleistungen angemeldet hat, nutzt z.B. ein Informations-Portal wie Yahoo, das er auf seine Nachrichtenbedürfnisse personalisieren kann. Weiterhin hat er bei einer Fluglinie einen Vielflieger-Account und gleichzeitig eine Bonus-Karte bei einer Autovermietung. Bei jedem dieser Dienstleister werden die Benutzerdaten des Anwenders in einem entsprechenden Profil vorgehalten, sei es in einem Directory oder in einer relationalen Datenbank.

Um auf jeden der beschriebenen Services zugreifen zu können, muss sich der Anwender bei jedem der Dienste authentisieren. Dies kann bei Service A und B bedeuten, dass er jeweils eine individuelle Kombination von Nutzerkennung und Passwort bereitstellt, bei Dienst C hat er ein digitales Zertifikat zu präsentieren und bei Service D genügt die Angabe eines PINs.

Eine solche Situation kann für beide Seiten, Anwender wie Dienstleister, durch eine Kopplung der Services untereinander verbessert werden. Wäre es beispielsweise möglich, dass Dienst A und B technologisch miteinander kooperieren und beide dem Anwender die Möglichkeit geben, beide Accounts zu verknüpfen, so könnten alle Seiten einen Nutzen daraus ziehen: Der Anwender bekommt auf seinem Yahoo-Portal direkt seinen Vielflieger-Status angezeigt, das Portal hat eine höhere Kundenbindung und die Fluglinie kann Spezialangebote direkt auf die Startseite des Anwender-Browsers projizieren.

Um dies umzusetzen, müssen die technologischen Voraussetzungen geschaffen werden (die Nutzerdaten, die bei beiden Dienstleistern vorliegen, werden miteinander korreliert, man spricht hier von „Föderation“ der Account-Daten) und der Anwender hat bei beiden Diensten die Einwilligung für diese Kooperation zu bestätigen.

Folgende Faktoren sind für die technologische Umsetzung zu berücksichtigen:

Die Föderation der Account-Daten muss so gestaltet sein, dass die Datenschutz-Rechte des Anwenders nicht verletzt wird. Das bedeutet, dass kritische Daten wie Nutzerkennung und Passwort nicht an die jeweils anderen Dienste oder Dritte weitergegeben werden.

Die Einwahl in einen der Dienste impliziert die gleichzeitige Authentisierung an die jeweils anderen Dienste, mit denen der Nutzer seine Accounts föderiert hat. Es ist weiterhin sicherzustellen, dass das Abmelden aus einem Dienst an alle anderen Dienste verteilt wird. Ein solches Verfahren, bei dem sich er Anwender nur noch ein einziges Mal an einem Dienste-Pool anmeldet, bezeichnet man als Single-sign-on (SSO).

Unterschiedliche Sicherheits-Ansprüche der verschiedenen Dienste müssen berücksichtigt werden. So macht es einen Unterschied, ob man sich auf einem Portal über Nutzerkennung und Passwort einloggt, um an seine Nachrichten zu gelangen, oder ob man ein Digitales Zertifikat benötigt, um seinen Kontostand zu überprüfen. Demnach könnte ein Anwender erwarten, dass er auf seinem Portal neben seinen News auch seinen Kontostand angezeigt bekommt, sofern er sich vorher bei der Bank authentisiert hat. Umgekehrt darf dies hingegen nicht der Fall sein.

Anwendungssicherheit muss im Vordergrund stehen. Dabei ist zu berücksichtigen, dass nicht nur die Anwender unterschiedliche technische Kenntnisse haben, sondern auch, dass die verwendeten Zugriffskomponenten wie Browser, Betriebssystem und Internet-Anschluss die verschiedensten Ausprägungen, Funktionalitäten und Sicherheits-Standards haben. Solche Anforderungen stellen die Service-Anbieter vor vollkommen neue technologische Herausforderungen.

Es stellt sich die Frage, wie man eine solche Architektur umsetzt. Hier kann man zwischen zwei Ansätzen unterscheiden: der verteilten- und der zentralistischen Topologie.

Microsoft hat mit seinem Passport-Engagement den zentralistischen Weg gewählt. Dabei soll sich ein Nutzer am zentralen Passport-Dienst einmal pro Session anmelden, anschließend wird ihm der Zugang zu allen beteiligten Diensten gewährt, die im Passport-Verbund vorhanden sind. Bei der Registrierung werden Name, Adresse und Mail-Kontakt aufgenommen. Geplant ist, dass später weitere Anwenderdaten bei Microsoft hinterlegt werden und die beteiligten Dienste im Passport-Verbund unter Zustimmung des Nutzers einen Teil dieser Daten von diesem Dienst anfordern können.

Eine solche Topologie zielt auf die Installation eines übergeordneten Meta-Directories, in dem die Nutzerdaten zentralisiert gesammelt und von dem betreibenden Dienst vertraulich verwaltet werden. Im Fall von Passport wäre Microsoft diese Instanz.

Der verteilte Ansatz ist der einer Föderation. Dabei behalten die Dienste im Verbund ihre Hoheit über die Nutzerdaten und bauen ihre Brücken zu den anderen Diensten nur über gemeinsam verhandelte Aliasnamen für den Nutzer auf. Ziel ist es, die wahren Anwenderdaten voreinander zu verbergen und nur soviel an Datenaustausch zu betreiben, wie es für den Betrieb der Kooperation notwendig ist.

Beispiel: Ein Nutzer hat einer Föderation seines Accounts zwischen dem Dienst A und B zugestimmt. Bei A ist er unter dem Account „JoeUser“ bekannt, bei B unter „j_user“. Zu Beginn einer Session authentisiert er sich bei Dienst A mit seinem entsprechenden Account. Zu einem späteren Zeitpunkt möchte er zu B wechseln. Dienst A und B haben einen gemeinsamen Aliasnamen für diesen Anwender vereinbart, in unserem Beispiel „xyz123“, und A teilt B nun mit, dass „xyz123“ erfolgreich authentisiert hat. Ein weiterer Austausch von Daten ist nicht mehr notwendig und beide Dienste behalten die volle Hoheit über die Account-Daten ihrer Mitglieder. Die Verwendung von Aliasnamen für den eigentlichen Account wird als „opak“ bezeichnet: Die Identität des Nutzers wird verschleiert.

In einem solchen Umfeld positioniert sich die Liberty Alliance, eine Kooperation von rund 150 Unternehmen (unter anderem Hewlett Packard, AOL, Nokia, Sony, Mastercard), die unter der Federführung von Sun Microsystems ins Leben gerufen wurde.

Ziel der Entwicklung ist es, eine Architektur zu definieren, die auf offenen Standards basiert. Es sollen Kommunikations-Protokolle und Identity-Services entwickelt werden, die den beschriebenen Anforderungen genügen. So tauschen die Dienste in einem Liberty-Umfeld die Authentisierungs-Daten untereinander über das XML-basierende Beschreibungsformat SAML (Secure Assertion Markup Language), aus. Die Version 1.0 der Spezifikation verteilt die Daten über die allgemein verwendeten Protokolle HTTP und HTTPS. Weitere Protokolle sollen in späteren Versionen unterstützt werden.

Wichtig ist dabei, dass die Services sich zwar zu einer Kooperation untereinander verabreden, die Datenhaltung der Nutzerinformationen aber in der jeweiligen eigenen Verantwortung der Services verbleibt. Das heißt, es werden keine Meta-Directory-Stukturen erzeugt, in der die verschiedenen Account-Daten konsolidiert werden, vielmehr verbleibt die Administration der individuellen Daten bei den Services selbst. Bei Liberty ist zwar ebenfalls geplant, dass die Dienste nach Absprache mit dem Anwender konkrete Benutzerdaten untereinander austauschen können, das Konzept sieht allerdings für diese Daten keine zentrale, sondern eine verteilte Informationshoheit vor. Dadurch soll verhindert werden, dass ein einziger Service alle Benutzerdaten verwaltet.

Sowohl in der zentralistischen als auch in der verteilten Architektur muss der Anwender die Zustimmung zur Zusammenarbeit zwischen mehreren Diensten erteilen. Es ist allerdings die Frage zu stellen, ob eine zentrale Instanz in der Lage sein darf, alle Nutzerdaten selbst zu verwalten. Diese hat einen Überblick darüber, bei welchen Diensten ein Anwender angemeldet ist. Dadurch wäre es möglich, detaillierte Nutzerprofile zu erstellen. Offen bleib, wie die jeweilige Zentralinstanz mit diesen Daten umgeht.

Der Kritikpunkt der Polarisierung von Nutzerdaten in einem zentralisierten Ansatz hat Microsoft zum Anlass genommen, um den Passport-Ansatz zu verteilen. So ist es möglich, kleinere Passport-Verbunde zu erzeugen, die miteinander kooperieren können. So ein Diensteverbund basiert jedoch wiederum auf einer Zentrale, in der letztlich alle Benutzerdaten landen.

Fazit

Architekturen, die das Bilden eines Dienstverbundes unterstützen, müssen in erster Linie gewährleisten, dass die Ansprüche an den Datenschutz des Kunden nicht verletzt werden. Dazu müssen Standards implementiert werden, die auf sicherem Weg verlässliche Authentisierungsdaten übermitteln können. Die Topologie darf einzelne Unternehmen nicht in die Lage versetzen, Daten einzusehen, die ein Anwender für dritte Dienste verwenden. Eine verteilte Topologie des Identitäts-Managements kommt diesem Anspruch mehr entgegen als eine zentralisierte.

Die technologische Entwicklung von Netz-basierenden Diensten unterliegt den Gesetzmäßigkeiten des Marktes. Diese werden gleichermaßen von den Bedürfnissen der Anwender im Hinblick auf Bequemlichkeit und Entfaltungsmöglichkeiten beeinflusst, wie auch durch Einsparpotentiale und Wettbewerbsvorteile der Unternehmen. Man hat erkannt, dass die Kopplung verschiedener Service-Angebote sowohl dem Kunden einen Mehrwert bietet, als auch Unternehmen in die Lage versetzt, Angebote zu optimieren, Einsparpotentiale zu nutzen und eine stärkere Kundenbindung zu erzeugen. (lex)