blogoscoop
 
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne
3 Bewertung(en)
Loading ... Loading ...
am 23.03.2008 von Oliver Belikan

Es gibt viele -meist sehr oberflächliche- Erklärungen wie OpenID technisch im Detail funktioniert. An einem konkreten Beispiel soll nochmal die Funktionsweise anschaulich erklärt werden.

AboutUs als Service Consumer
Gehen wir von folgender Situation aus:
Sie möchten sich auf der Webseite AboutUs mit ihrere ObenID anmelden. Webseiten bei denen man sich mit der OpenID anmelden kann, werden auch als Service Consumer oder Relying Party bezeichnet (Liste von Relying Partys).
myOpenID als Identity Provider
Ihre OpenID haben Sie z.B. über den Dienst myOpenID registriert. Dienste welche die OpenID ausstellen, speichern und verwalten werden auch als Identity Provider oder Identity Server bezeichnet (Liste von Identity Provider).

In unserem Beispiel kommuniziert die Relying Party AboutUs mit dem Identity Provider myOpenID. Im OpenID-Protokoll stehen dafür vier Nachrichten zur Verfügung:

  • associate Nachricht
    Wird direkt vom Consumer an den Identity Provider gesendet um einen geheimen Schlüssel zu vereinbaren und auszutauschen. Somit müssen folgende Nachrichten zwischen Consumer und Provider nicht ständig über extra Schritte verifiziert werden. Das Protokoll legt nicht fest, ob überhaupt und zu welchem Zeitpunkt die Nachricht associate vom Consumer versendet wird. Es obliegt dem Consumer, wann er diese optionale Nachricht über die HTTP POST Methode versendet.
  • checkid_setup Nachricht
    Wird vom Consumer über indirekte Kommunikation (HTTP Browser-Redirect über GET-Methode) an den Identity Provider versendet. Mit dieser Nachricht prüft der identity Provider, ob der User auch tatsächlich der ist, der er behauptet zu sein (assertion).
  • checkid_immediate Nachricht
    Ist identisch zu der Nachricht checkid_setup mit dem Unterschied, dass die Antwort nicht als HTTP-Browser-Redirect gesendet wird. Somit können asynchron arbeitenden Ajax-Anwendungen die Kontrolle übernehmen und das Ergebnis in einem eigenen IFrame oder Popup-Fenster darstellen.
  • check_authentication Nachricht
    Mit dieser Nachricht verifiziert der Consumer ob die bestätigte Behauptung auch tatsächlich vom Identity Provider stammt. Diese direkte HTTP-POST Kommunikation ist nicht notwendig, wenn über die associate-Nachricht bereits die geheimen Schlüssel ausgetauscht wurden und damit ebenso die Echtheit des Identity Providers festgestellt werden kann. Somit werden die offensichtlichen Hacking- und Phisingversuche unterbunden.

Technischer Ablauf der Authentifizierung am Beispiel AboutUs und myOpenID

Authentifizierung mit OpenID 1. Aufruf Consumer Webseite AboutUs
Der Benutzer in der Mitte des Bildes ruft mit seinem Browser die Webseite AboutUs auf. Er möchte auf dieser Seite etwas schreiben und muss sich dazu anmelden.
Auf dem Login-Screen erhält er ein Feld um seine persönliche OpenID-URL als Benutzername einzugeben.
Authentifizierung mit OpenID 2. Login Consumer Request
Der Benutzer gibt z.B. die OpenID-URL blog.doubleSlash.de als Login ein. Ein Passwortfeld wird nicht angezeigt.
Das Formular wird mit der eingegebenen OpenID-URL an den die Webseite AboutUs gesendet.
Authentifizierung mit OpenID 3. Discovery
Die Webseite AboutUs kontaktiert nun die eingegebene OpenID-URL unter http://blog.doubleSlash.de.
Dort ist die Adresse des OpenID-Servers und der zugehörigen OpenID im Quelltext der HTML-Seite eingetragen. Damit weiß die Webseite AboutUs, an welchen OpenID-Server mit welcher OpenID sie sich wenden soll.
Authentifizierung mit OpenID 4/5. Associate Request (Optional)
Die Webseite AboutUs kann den OpenID-Server kontaktieren um einen geheimen Schlüssel (Shared Secret) auszutauschen bzw. einen vorhandenen Schlüssel zu aktualisieren. Nicht jede Consumer Webseite möchte die ausgetauschten Schlüssel lokal verwalten und verzichtet deshalb auf diesen Schritt. Der Schritt 7 muss dann immer ausgeführt werden. Dies erfordert jedoch zusätzliche Kommunikation.
Authentifizierung mit OpenID 4. checkid_setup oder checkid_immediate Request
Die Webseite AboutUs kontaktiert den OpenID-Server unter der Adresse http://www.myopenid.com/server mit der OpenID http://doubleSlash.myopenid.com.
Der Request geschieht mit einem http-Redirect Aufruf (Code 302) über den Browser des Benutzers.
Authentifizierung mit OpenID 5. Login OpenID-Server Request/Response
Wenn der Benutzer im OpenID-Server noch nicht angemeldet ist, muss er sich einmalig mit seinem Passwort anmelden.
Da der OpenID-Server die Webseite bisher nicht kennt, gibt der Benutzer an ob diese vertrauenswürdig ist. Die Kommunikation mit dem OpenID-Server ist verschlüsselt.
Authentifizierung mit OpenID 6. id_res oder cancel Response
Egal, ob die Anmeldung am OpenID-Server myOpenID erfolgreich war oder nicht, leitet dieser die Antwort per http-redirect oder als XML (Abhängig ob setup oder immediate Nachricht verwendet wurde) an die Webseite AboutUs weiter (Indirekte Kommunikation).
Authentifizierung mit OpenID 7. check_authentication Request/Response
War die Anmeldung erfolgreich, baut die Webseite AboutUs eine direkte (verschlüsselte) Verbindung zum OpenID-Server myOpenID auf. Die Webseite verifiziert, ob die erhaltenen Anmeldedaten valide sind und auch tatsächlich von dem OpenID-Server myOpenID stammen (Anti-Phising).
Dieser Schritt kann entfallen, wenn in Schritt 4/5 ein Schlüssel ausgetauscht wurde.
Authentifizierung mit OpenID 8. Login Consumer Response
Der Loginvorgang zum Consumer wird abgeschlossen, indem der Benutzer auf die Seite von AboutUs weitergeleitet wird, welche nach dem Login-Screen vorgesehen ist.
Dies kann z.B. eine “Herzlichen Willkommen Herr doubleSlash” sein.

Weitere Links und Details zum Protokoll:

Kategorien: Entwicklung & Tools

Eine Antwort zu “ Das Protokoll zur Authentifizierung mit OpenID unter der Lupe ”

  1. Jan Schubert sagt:

    Danke Oli. Im Schritt 7 den Begriff Anmeldedaten bitte nicht falsch verstehen, hier gehen natürlich keinerlei Passwörter oder andere Infos übers Netz. Wie auch – AboutUs kennt das ja gar nicht. Generell finde ich aber auch das sollte entfallen, das ist zum einen bei Public Key Verfahren nicht erforderlich und zum anderen macht es das nur kompliziert.

    KISS – Keep ist Small and Simple

Kommentar verfassen