Seite 2: Spezifikationen

Inhaltsverzeichnis

SSO- und OpenID-Spezifikationen

Neben OpenID gibt es eine Reihe anderer Protokolle für SSO mit der gleichen Intention, beispielsweise das Liberty Alliance Project mit SAML (Security Assertion Markup Language), Microsoft Passport, CAS (Central Authentication Service), Shibboleth und Kerberos (siehe Glossar). OpenID ist für die Authentifizierung in Webanwendungen eine einfache und pragmatische Lösung. Hinzu kommt, dass sowohl die Anzahl der Konsumenten als auch der Provider stetig steigt, was die Akzeptanz der Endbenutzer definitiv erhöht [3].

OpenID ist durch Erweiterungsspezifikationen wie OpenID Attribute Exchange (OpenID AX) offen, um unterschiedliche Aspekte des Identitätsmanagements abzudecken. Durch OpenID AX lassen sich Attribute eines Endbenutzers – oft innerhalb einer Identitäts-Card beziehungsweise einer Persona zusammengefasst – zwischen einem Konsumenten und einem Provider austauschen. Es ist beispielsweise möglich, E-Mail-Adresse, Nickname und/oder Alter des Endbenutzers von Providern an den Konsumenten und umgekehrt zu übergeben. Beim Implementieren solcher Funktionen ist es jedoch wichtig, dass die informationelle Selbstbestimmung des Endbenutzers stets im Vordergrund steht. Ein Konsument und ein Provider dürfen keine Attribute ohne Zusage des Endbenutzers austauschen. Das gehört jedoch nicht zu den OpenID-Spezifikationen und ist beim Implementieren des Providers genau zu beachten. Die folgende Tabelle beschreibt kurz die wichtigsten Spezifikationen. Ausführliche Informationen zu ihnen gibt es unter openid.net. Konzeptuell setzt das OpenID-Protokoll auf der "Name-Value-Pair"-Beschreibung auf. Bei Java ist dies mit der Verwendung von Map vergleichbar. Im Webservices-Jargon nutzt das OpenID-Protokoll das REST-Modell.

OpenID-Spezifikationen
Name	Sinn und Zweck
OpenID Authentication 1.1 – Draft 1 und 2.0	Authentifizierungsspezifikation, Hauptteil im OpenID-Protokoll
OpenID Simple Registration Extension 1.0 und 1.1 – Draft 1 (SReg)	Austausch von Identitätsattributen mit einer festen Anzahl von acht vorgegebenen Attributen
OpenID Attribute Exchange 1.0 (AX)	Austausch von Identitätsattributen, unbegrenzt und selbst definierbar, erweiterbar, zukünftig wichtiger als SReg
OpenID Provider Authentication Policy Extension 1.0 (PAPE)	Überprüfung bestimmter Verifizierungsmethoden: Wurden ausschließlich Benutzername und Passwort oder zusätzlich Token-Generator verwendet? Hinzu kommt die Überprüfung der Verifizierungszeit des Providers bei dem angegebenen Benutzer. Unter verify.sxip.com kann man eine Demo-Seite für PAPE aufrufen
OpenID Assertion Quality Extension 1.0 – Draft 3	Überprüfung der Attributsqualität: Wurde die angegebene E-Mail-Adresse tatsächlich auf ihre Richtigkeit überprüft? Gehört die E-Mail wirklich der angegebenen Person?

Das folgende Beispiel zeigt, wie eine OpenID-Anfrage innerhalb des Protokolls aussieht:

openid.ns = "http://specs.openid.net/auth/2.0"
openid.mode = "checkid_setup"

OpenID-Provider und -Konsument

Inzwischen gibt es zahlreiche Provider, die mit unterschiedlichen Eigenschaften aufwarten. Unter "Beispiele von OpenID-Providern" sind sie übersichtlich zusammengefasst. Die Liste der Konsumenten ist ebenfalls lang. Für in Deutschland zur Verfügung stehende Konsumenten gibt es eine geringere Anzahl. Bei zahlreichen Konsumenten finden oft White- und Black-Listing-Verfahren Verwendung, um ausschließlich bestimmte Provider zuzulassen. In vielen Fällen ist das sinnvoll, sodass anonyme beziehungsweise Wegwerf-Provider nicht zu verwenden sind. Die bekanntesten OpenID-Konsumenten findet man unter "Beispiele von OpenID-Konsumenten" aufgelistet.

Integration von OpenID aus Sicht des OpenID-Konsumenten

Um die Verbreitung und Akzeptanz von OpenID zu gewährleisten, müssen genügend Konsumenten das Protokoll unterstützen. Daher steht die Einfachheit bei der Anbindung von OpenID in eine Webanwendung im Vordergrund. Im Prinzip ist der Anbindungsprozess zu befolgen, wie er in Abbildung 4 dargestellt ist. Der Registrierungsprozess ist genauer zu beachten, da mehrere Szenarien für die Existenz eines Konsumenten- beziehungsweise Providerkontos möglich sind. Für jedes Kästchen gibt es eine Lösung.

Folgende Vorgehensweise ist bei der Anbindung denkbar: Die Endbenutzer-Datenbank ist zunächst zu erweitern. Hier sind zusätzliche Informationen über den OpenID-Identifier und das OpenID-Konto zu speichern. Bei jedem Endbenutzer-Konto kann man mehrere Identifier verwenden. Im einfachsten Fall beziehungsweise bei einer neuen Anwendung ohne vorhandene Endbenutzer könnte man ausschließlich den OpenID-Identifier speichern, sodass eine separate Endbenutzer-Kontoverwaltung wegfallen würde. Anschließend sind folgende Webseiten des Konsumenten zu überarbeiten:

• Endbenutzerkontoverwaltungsseite: Bei vorhandenen Endbenutzer-Konten auf der Konsumentenanwendung müssen Endbenutzer die vorhandenen Open-ID-Konten eintragen und sie anschließend verwenden können.
• Registrierungsseite des Endbenutzers: Statt des normalen durchläuft die Registrierung mit OpenID-Providern einen kürzeren Prozess. Schließlich will der Endbenutzer die Registrierungsdaten nicht noch einmal eintippen müssen. Spezifikationen wie SReg oder AX übertragen diese Information aus dem Provider.
• Login-Seite des Endbenutzers: Zum Einloggen muss die Eingabe eines OpenID-Identifiers möglich sein. Hierfür ist ein Textfeld mit einem OpenID-Symbol auf der Login-Seite einzufügen.