© Elnur, Fotolia.com

Die steigende Anzahl von Webanwendungen fordert vom Anwender immer bessere Gedächtnisleistungen beim Merken von Passwörtern. Eine zentrale Verwaltung und Anmeldung wie bei Microsofts Passport finden Sicherheitsbewusste unbehaglich. Open ID tritt an, eine Alternative mit Open-Source-Mitteln zu liefern.

Das Web 2.0 ist nicht jedermanns Sache. Kritiker prangern die mangelnde technische Präzision des Begriffs an, sehen ihn als Buzzword und Synonym für unnötige Augenwischerei mittels Javascript und Konsorten. Nicht ganz so öffentlich diskutiert, aber nicht weniger kontrovers bewertet, steht das Thema Identity Management auf der Agenda vieler Kenner der IT-Landschaft. Es bietet sich an, die beiden Themen zu verbinden.

Passwort vergessen

Visionäre entwerfen eine Zukunft mit immer neuen Webapplikationen, in der die konkrete Funktionalität des Betriebssystems und seiner nativen Applikationen weiter in den Hintergrund gerät. Die Vorteile liegen auf der Hand: Webbrowser sind kinderleicht von jedermann zu bedienen, sie laufen auf Telefonen und PDAs, praktisch auf jedem Betriebssystem. Manche sehen darin die perfekte Schnittstelle für jedermann zur Informationstechnik. Einige Unternehmen wie Google bauen ein Milliardenimperium auf diesem Glauben auf.

Aus der Allgegenwart ergibt sich ein erstes Problem, das die Web-Enthusiasten anfangs gar nicht wahrgenommen haben: Wie soll das Web 2.0 mit persönlichen Daten und Informationen umgehen, wenn gar nichts vorhanden ist, um diese zu speichern? Selbst wenn die Daten zentral auf einem Server verwahrt bleiben, benötigen Anwender dennoch einen personalisierten Zugang zu ihnen. Solange Benutzer nur einen Webmailer, einen Zugang zur eigenen Homepage und zum Onlinebanking hatten, war die Welt mit drei Benutzeraccounts und den zugehörigen Passwörtern noch in Ordnung.

Überblick verloren

Seit aber auch noch persönliche Blogs, der virtuelle Freundeskreis von Xing bis Facebook und im Büro Zeiterfassung, Reisekostenabrechnung und Urlaubsvertretungsregelung sich alle Web-basiert präsentieren, erscheint die Situation dem hilflosen Anwender zunehmend unübersichtlich. Solange User noch vor einem lokalen, physischen Gerät sitzen (oder einen Server in unmittelbarer Reichweite haben), mögen Werkzeuge wie der in den meisten Browsern eingebaute Passwortmanager oder das KDE-Wallet noch nützliche Helfer sein. Nach dem Paradigma des reinen Web 2.0 gibt es aber nur noch einen Browser ohne lokale Speichermöglichkeit. Wer hilft dann beim Verwalten von Benutzeraccounts und Passwörtern?

Identitätsverwaltungen treten an, dafür Lösungen zu bieten. Das Prinzip einer vertrauenswürdigen dritten Instanz neben dem Anwender und dem Dienstanbieter ist schon alt: Kerberos beispielsweise implementiert dieses Verfahren seit über 20 Jahren (siehe auch Artikel zu PAM und Kerberos in dieser Ausgabe). Bei Kerberos ist diese vertrauenswürdige Instanz, das Key Distribution Center, noch in relativer Nähe des Anwenders angesiedelt, zumeist beitreibt es die IT-Abteilung der eigenen Firma. Sie gelten gemeinhin als vertrauenswürdig.

Unbewegliche Dinosaurier

“Fein”, dachten sich einige bekannte Player der Branche, “wir sind groß, also sind wir vertrauenswürdig.” Aus diesem Gedanken ist beispielsweise das Passport-System von Microsoft entstanden, das der Hersteller heute unter dem Namen “Windows Live ID” vermarktet [1]. Kritiker bemängeln allerdings neben dem starken Zuschnitt auf proprietäre Anwendungen, dass solch ein zentrales System erheblichen Einfluss auf die Privatsphäre der Benutzer habe. Als zentrale Instanz ist der Passport-Server stets darüber informiert, welche Angebote Anwender nutzen. Benutzerprofile sind da nur die erste Stufe, später könnten sich solche Systeme weigern, mit unliebsamen Konkurrenten zusammenzuarbeiten.

Als Gegenentwurf dazu haben Sun, IBM, Intel und andere namhafte Anbieter 2001 das Liberty Alliance Project gestartet [2]. Es arbeitet zwar dezentral, aber gilt als überspezifizierter Dinosaurier, denn selbst nach sieben Jahren umfangreicher Gremienarbeit hat das Verfahren unter Anwendern noch keine weite Verbreitung erfahren. Das möchte das Open-ID-Projekt unter der Ägide der Open ID Foundation anders machen [3] und setzt dabei auf eine vereinfachte Funktionalität, die sich leicht und ohne den großen Aufwand der vorgenannten Systeme in eigene Anwendungen integrieren lässt.

Community-Ansatz

Open ID konzentriert sich auf Webanwendungen. Das verdeutlicht bereits die Form der verwalteten Identitäten: Benutzer weisen sich nicht durch Benutzernamen aus, sondern durch URIs (Uniform Ressource Identificators), die sich im Webbrowser darstellen lassen. Das kann eine Webadresse sein, die ein Open-ID-Dienst anbietet, etwa [http://nilsmagnus.myopenid.com] beim Anbieter Myopenid [4]. Die Form dieser Identität spielt keine Rolle, solange ein Browser die Seite aufrufen darf. In dieser Seite muss der Webentwickler nämlich ein Tag als Verweis auf den eigentlichen Dienstleister einbauen:

<link rel="openid.server" href="http://www.myopenid.com/server" /> 
<link rel="openid.delegate" href="http://nilsmagnus.myopenid.com/" /> 

Die erste Relation legt den Server des Anbieters fest, die zweite nennt noch einmal den Namen der Identität. Die Zeilen müssen nicht unbedingt beim Dienstleister liegen, auch wenn dieser zumeist eine solche Seite anlegt. Anwender könnten sie beispielsweise auch in die persönliche Homepage oder in den eigenen Blog einbauen. Dann dient die eigene Adresse als Open ID. Der Vorteil ist, dass sich der Anbieter auf diese Weise später einfach wechseln lässt.

Anmeldung

Unterstützt eine Anwendung Open ID, bietet sie zusätzlich zum klassischen Login auch ein URI-Feld an, über das der Benutzer die Open-ID-Identität eingeben kann. Das Amarok-Team von KDE nutzt den Dienst, um Nutzer ihres Wiki zu authentifizieren (siehe Abbildung 1). Ist die Identität eingegeben, untersucht die im Open-ID-Jargon Consumer genannte Webapplikation – hier das Wiki von Amarok – den eingegebenen URI und fischt dort den beschriebenen Server-Eintrag heraus. Diesen Server nennt Open ID auch Identity Provider.

Abbildung 1: Das Amarok-Wiki erlaubt dem Benutzer ein Login mittels Open ID. Anschließend gibt der Nutzer seine Open-ID-Identität als vollständigen URI ein.

Anschließend fragt das Wiki den Provider nach dem ebenfalls übermittelten Identitätsnamen. Dazu sendet es einen Redirekt auf die Webseiten des Providers, der seinerseits nun anzeigt, wer die Anfrage stellt. Stimmt der Anwender der Anfrage zu, gibt er sein Passwort an. Der Provider lenkt den Browser auf das Wiki zurück und der Benutzer ist angemeldet.

Praktisch ist, dass die Anwender beim Provider mehrere Angaben, so genannte Attribute, zur Identität hinterlegen dürfen. So können sie ihre vollständigen Namen, die bevorzugte Sprache oder ihre Geburtsdaten speichern (siehe Abbildung 2). Der Anwender wählt bei jeder Anfrage eines Consumers aus, welche Angaben der Provider dem Consumer mitteilt und welche nicht.

Abbildung 2: Der Provider kündigt an, welche Angaben er an den Consumer übermitteln will. Der Anwender kann dieses Verhalten steuern und vorkonfigurieren.

Das ist wichtig, damit nicht eine böswillige Webanwendung eine Bank-PIN abfragt, die sich ja ebenfalls in der Identität ablegen ließe. Einige Provider bieten dazu unterschiedliche Personae an, die jeweils einen Satz von Attributen zusammenfassen (Abbildung 3).

Abbildung 3: Von der Präsentation der Open ID durch den Anwender bis zum Zugang zur Webapplikation (Consumer) ist es ein weiter Weg: Vorher fragt die Webapplikation erst die Identitätsseite und schließlich den Provider, der eine erfolgreiche Authentifizierung an die Applikation zurückmeldet.

Das Verfahren nennt sich auch User-Centric Identity Management, da jeder Anwender einzeln festlegt, welche Informationen sein Provider einem anfragenden Consumer mitteilt. Eine Reihe populärer Webapplikationen kennt bereits Unterstützung für Open ID, beispielsweise Mediawiki [5] oder Drupal [6].

Es gibt Identity-Provider, die damit werben, kostenlose Identitäten herauszugeben. Jedem Anwender obliegt die Entscheidung, welchen er für vertrauenswürdig und zuverlässig hält. Anders als beim zentralen Ansatz von Passport gibt es also viele dezentrale Anbieter, die im Wettbewerb zueinander stehen. Diese Situation erinnert an Unternehmen, die SSL-Zertifikate ausgeben. Auch hier herrscht Konkurrenz.

Zudem steht es jedem Anwender frei, seinen eigenen Provider aufzusetzen. Interessierte Entwickler finden entsprechende Pakete als Open Source in fast jeder aktuellen Programmiersprache von Perl, PHP, Ruby, Python bis hin zu Java [7].

Bestehendes nutzen

Überraschenderweise gibt es noch einen dritten Weg, um an eine Open ID zu kommen. Viele Anwender besitzen nämlich schon eine, ohne es zu wissen. Wer ohnehin einen Benutzeraccount bei einer großen Webanwendung wie Blogger, Technorati oder einem Portal wie AOL oder Yahoo hat, darf die dort vorhandenen Authentifizierungsmechanismen nämlich auch über das Open-ID-Protokoll nutzen. Tabelle 1 listet eine Reihe von großen Anbietern auf. Wer diese Provider bei einer Open-ID-fähigen Webanwendung nutzt – etwa dem Wiki aus dem Beispiel -, den fragt der hinterlegte Provider dann in bekannter Weise nach seinem Passwort, das in der Blog-Verwaltung ja bereits hinterlegt ist.

Sicherheitsbedenken

Aufmerksame Anwender fragen sich, wie es mit der Sicherheit von Open ID bestellt ist, wenn jeder als Provider auftreten darf. Kann ein Angreifer eine Identität fälschen oder entführen? Die erste Frage verweist auf klassische Sicherheitsfragen: Wer eine fremde Webseite manipulieren kann, ist auch in der Lage, zu einem eigenen Identity-Provider umzulenken oder einen solchen zu schreiben. Insofern liegt die Sicherheit der Identität in den Händen des Betreibers der hostenden Site. Dies ist mit Blick auf die Codequalität vieler in populären Skriptsprachen verfasster Sites zwar etwas bedenklich, aber kein grundsätzliches Argument gegen Open ID.

Die zweite Frage ist kniffliger: Lässt sich die Kommunikation zwischen Consumer und Identity Provider abhören und speichern? Schließlich meldet der Provider die Bestätigung, wenn die Authentifizierung Erfolg hatte. Ein Angreifer könnte versucht sein, bei einer eigenen Anmeldung unter falschem Namen solch einen Mitschnitt als Legitimationsnachweis vorzulegen. Doch dagegen nutzt Open ID SSL/TLS, um die Verbindung abzusichern, und fügt jeder Abfrage zusätzlich einen Challenge bei. Damit ist eine Antwort jeweils nur einmal gültig und lässt sich nicht einfach recyceln.

Trotzdem sollte niemand die Komplexität eines zustandsbehafteten Sitzungsmanagements über ein zustandsloses Protokoll wie HTTP, auf dem ja auch Open ID aufsetzt, unterschätzen. Diverse Einbrüche in Webapplikationen sprechen eine deutlich Sprache, jedenfalls wenn man einschlägigen Studien und Whitepapers glaubt [8].

Praktisch und offen

Der Ansatz von Open ID geht grundsätzlich in die richtige Richtung, was Identitätsmanagement im Web angeht, auch wenn es durchaus noch einige Ergänzungen und Alternativen gibt, siehe etwa den Kasten “Identity Management und Federation”. Das implementierte Single-Sign-on bedeutet für Anwender ein deutliches Mehr an Komfort, da sie sich nur noch ein Passwort pro Identität merken müssen statt je eines pro Anwendung. Die Möglichkeit, Attribute zu verwalten, ist mächtiger als sie anfangs erscheint. Die Zahl der Anwendungen, die Open ID benutzen, steigt rasant an. Aber dennoch müssen einige richtig große Anwendungen erst noch zeigen, ob sie allen operativen und konzeptionellen Anforderungen an Vertraulichkeit und auch Verfügbarkeit gewachsen sind.

Open ID ist ein Rahmenwerk, das die komplexen Abläufe beim Identity Management auf das Web abbildet. Die Mechanismen, die das Protokoll dabei zwischen Anwender, Consumer und Provider anbietet, sind flexibel und weitsichtig. Damit einher geht aber die Frage, ob Anwender und Anbieter die Auswirkungen des Gesamtsystems noch überblicken. Wenn es etwa um Privatsphäre geht, sind Anwender mit Einfachheit oft gut beraten. Grundsätzliche Fragen über das Identitätsmanagement im Web gehen zwar über Open ID hinaus, sind aber dennoch essenziell.

Mit Blick auf Privatsphäre bleibt Raum für Kontroversen (siehe den folgenden Artikel zum Thema). Am Ende muss jeder Anwender selbst den Überblick behalten – auch ein Identitätsmanagement kann ihn dabei nur unterstützen.