Identity Management: Authentifizierungsdienste mit OpenID

Inhaltsverzeichnis

Single-Sign-on (SSO) wartet immer noch auf den Durchbruch im Internet. Wer kennt nicht das komplizierte Hantieren mit der Verwaltung von Benutzernamen und Passwörtern für unterschiedliche Webanwendungen? Folgendes Szenario wäre traumhaft: Man stelle sich vor, man hätte einen Benutzername und ein Passwort und könne sich damit überall in diversen Webanwendungen einloggen. Vielleicht müsste man noch nicht mal ein Passwort besitzen, da die Authentifizierung anders funktioniert – beispielsweise mithilfe von Biometrieverfahren. Was sich attraktiv anhört, bleibt zunächst ein Traum. Was allerdings im Internet mit dem SSO-Protokoll OpenID Realität ist, zeigt dieser Auftaktartikel der Artikelserie "Internet-Identität und Datenaustausch heute – Nutzung und Möglichkeiten von OpenID und OAuth".

Mehr Infos

Internet-Identität und Datenaustausch heute – Nutzung und Möglichkeiten von OpenID und OAuth

+ Identity Management: Authentifizierungsdienste mit OpenID

+ Einführung in die OpenID-Java-Bibliothek openid4java

+ Web-2.0-Datenmanagement: Datenaustausch mit OAuth – Einführung in die Bibliothek OAuth Core for Java

+ OpenID und OAuth: Zusammen für ein besseres Internet?

Was ist OpenID?

OpenID beschreibt eine URL-basierte Identität (Identifier) wie https://mueller.myopenid.com/. Das Protokoll basiert auf einer dezentralisierten Identitätsinformation. Das heißt, es ist nicht zwingend notwendig, dass die Identität einer Person – im OpenID-Jargon der End User (Endbenutzer) – zentral auf einem einzigen OpenID-Provider (im Folgenden: Provider) vorhanden sein muss beziehungsweise zu speichern ist. Im Idealfall existiert eine Menge an Providern. Die URL-Identität lässt sich beim Einloggen in unterschiedlichen Websites oder Webanwendungen, auch Relying Parties genannt (im Folgenden: Konsument), eingeben, um die Authentifizierung anschließend beim Provider durchführen zu können.

Bei einer erfolgreichen Authentifizierung akzeptiert der Konsument den Endbenutzer. Er kann nun wie gewohnt in der Webanwendung Aktionen durchführen. Je mehr Websites und Webanwendungen das Protokoll unterstützt, desto weniger Benutzernamen und Passwörter muss der Endbenutzer erstellen, verwalten und eingeben. Abbildung 1 stellt die Rollen im OpenID-Umfeld dar.

Seit 2007 kontrolliert die OpenID Foundation die Entwicklung des OpenID-Protokolls. Ihr gehören Unternehmen wie Microsoft, Google, IBM, Yahoo und VeriSign an.

OpenID-Authentifizierung aus Endbenutzer-Sicht

Im Prinzip geht es um die Umleitung des Benutzer-Logins auf einem ausgewählten Provider. Im ersten Schritt ist der Identifier (zum Beispiel https://mueller.myopenid.com/) auf einer Konsumenten-Webanwendung einzugeben. Zunächst ist der Identifier zu normalisieren beziehungsweise passend zu formatisieren. Aus der gewonnenen Information lässt sich der Provider suchen und finden (Discovery). Danach kann man den Provider kontaktieren (bei OpenID heißt das direkte Kommunikation zwischen Konsument und Provider), um – soweit möglich – eine Beziehung zwischen Konsument und Provider (eine sogenannte Assoziation) in Form eines Geheimschlüssels herzustellen. Der Schlüssel ermöglicht die Beibehaltung des Zustandes, sodass bei späterer Kommunikation kein direkter Informationsaustausch stattfinden muss.

Anschließend ist der Endbenutzer über den Browser an den Provider weiterzuleiten (bei OpenID bezeichnet man das indirekte Kommunikation zwischen Konsumenten und Providern) und eine Login-Maske des Providers zu erstellen, sodass er Benutzername und Passwort eingeben kann. Der Konsument erhält das Ergebnis der Authentifizierung ausschließlich durch eine Weiterleitung (Redirect). Dadurch kann er überprüfen, ob der Endbenutzer eine korrekte Authentifizierung durchgeführt hat. Der Konsument führt in der einfachen Form des Protokolls zusätzlich eine direkte Kommunikation mit dem Provider, um sich das Ergebnis der Authentifizierung noch mal bestätigen zu lassen. Die intelligente Form des Protokolls hingegen verwendet den oben erwähnten Geheimschlüssel, um das Authentifizierungsergebnis zu verifizieren. Danach kann die Webanwendung des Konsumenten wie gewohnt mit ihrer eigenen Applikation weiterarbeiten. Die Abbildung 2 stellt den intelligenten Authentifizierungsmechanismus grafisch dar. Für eine detaillierte Protokollausführung sei auf das OpenID-Online-Buch "Get Ready for OpenID" verwiesen.

Um die Unabhängigkeit eines Identifiers zum Provider zu gewährleisten, muss man seine eigene URL-Adresse als Identifier nutzen. Im Fall, dass ein neuer Provider eingesetzt werden sollte, ist dort die Provideradresse zu verändern. In der OpenID-Welt bezeichnet man das Verfahren als Delegation. In der angegebenen URL-Adresse genügt ein einfacher Eintrag, wie das folgende Beispiel für OpenID 1.x zeigt. Sobald man die Adresse als Identifier eingibt, leitet das OpenID-Protokoll die Seite des Konsumenten an den richtigen Provider um [6]:

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