Ein zentrales Identitätsportal für die Benutzer

Eberhardt-Karls-Universität Tübingen
Mathematisch-Naturwissenschaftliche Fakultät
Wilhelm-Schickard-Institut für Informatik
DIPLOMARBEIT
Ein zentrales Identitätsportal für die
Benutzer-Authentizierung im
Internet mit 2D-Barcodes
Kevin Kempfer
Mat-Nr. 2371481
Betreuer: Apl. Prof. Klaus Reinhardt, Dr. Bernd Borchert
Eberhardt-Karls-Universität Tübingen
Wilhelm-Schickard-Institut für Informatik
Tübingen, Juli 2013
ii
Eidesstattliche Erklärung
Hiermit versichere ich, diese Arbeit selbständig verfasst und keine anderen als die
angegebenen Quellen und Hilfsmittel benutzt zu haben.
Tübingen, den 12. Juli 2013
Kevin Kempfer
iii
iv
Inhaltsverzeichnis
1 Einleitung
1
1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Thema und Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2 eKaay
5
2.1
Das eKaay-Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Das eKaay-Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
Registrierungsprozess am eKaay-Portal . . . . . . . . . . . . . . . . . .
7
2.3.1
Benutzerregistrierung . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.2
Portaloberäche . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.3
Registrierung am Smartphone . . . . . . . . . . . . . . . . . . .
7
2.3.4
Verwaltung des Accounts . . . . . . . . . . . . . . . . . . . . . .
15
3 OpenID
17
3.1
Begrie und zusätzliche Protokolle
. . . . . . . . . . . . . . . . . . . .
17
3.2
Konzept
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.3
Technischer Ablauf
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.4
Bewertung OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.5
OpenID am eKaay-Portal
. . . . . . . . . . . . . . . . . . . . . . . . .
24
3.5.1
Server
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.5.2
Client
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4 oAuth
27
4.1
Begrie
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2
Konzept
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.3
Technischer Ablauf
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.4
Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.5
oAuth am eKaay-Portal
. . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.5.1
Server
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.5.2
Client
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
v
Inhaltsverzeichnis
5 Vergleich OpenID vs. oAuth
35
6 Login auf externen Websites
37
6.1
Demo des OpenID Logins
6.2
Demo des oAuth Logins
. . . . . . . . . . . . . . . . . . . . . . . . .
37
. . . . . . . . . . . . . . . . . . . . . . . . . .
40
7 Diskussion
41
8 Ausblick
43
Abkürzungen
45
Abbildungsverzeichnis
47
Literaturverzeichnis
49
vi
1 Einleitung
Internet-Benutzer haben heute die Möglichkeit auf vielfältige, zum Teil sicherheitskritische Dienste zuzugreifen, z.B. Online Banking, eGovernment und Online Shopping.
Von zentraler Bedeutung ist dabei, dass der Zugang zu diesen Diensten und Ressourcen so gesichert ist, dass nur der rechtmäÿige Benutzer darauf zugreifen kann. Dabei
genügt es nicht, dass der Benutzer sich identiziert, also dem Dienst-Anbieter bekannt
gibt, wer er ist. Vielmehr muss der Benutzer dies gegenüber dem Dienst-Anbieter beweisen. Diese Sicherheitsüberprüfung, d.h. den Nachweis darüber, derjenige zu sein,
der man zu sein behauptet, nennt man Authentizierung.
Man unterscheidet im Wesentlichen drei Ansätze zur Authentizierung eines Benutzers gegenüber einem Dienst im Internet:
Wissen
Besitz
z.B. ein Passwort, eine PIN
1
oder die Antwort auf eine Frage
2
ein physikalisches Gerät, z.B. eine SmartCard, ein Security-Token
oder ein
Schlüssel
Eigenschaften
meist Biometrie, z.B. ein Fingerabdruck, die Retina oder ein anderes
fälschungssicheres biometrisches Merkmal
Mit fortschreitender Technik und der Verlagerung von immer mehr Diensten in das
Internet steigt die Gefahr kriminellen Miÿbrauchs der Benutzerkonten von InternetNutzern. Die Schäden durch Betrug mit Zugangsdaten zu Kommunikationsdiensten
lagen im Jahr 2011 in Deutschland bei etwa 21,2 Mio. Euro [Bundeskriminalamt
2012]. Um sich auszuweisen, ist seit dem Beginn des Internetzeitalters die Kombination aus Benutzername und Passwort gängig. Dabei erstellt der Benutzer bei jedem
Dienst-Anbieter ein Benutzer-Konto und gibt den gewünschten Benutzernamen und
das Passwort an. Damit kann der Dienst-Anbieter den Benutzer erkennen und ihm
Zugang zum angebotenen Dienst gewähren. Die Sicherheit dieses Systems beruht allein auf der Sicherheit des angegebenen Passworts und dessen sicherer Übertragung
1 Personal
2 z.B.
Identication Number
in Form eines speziellen USB-Sticks
1
1 Einleitung
zur Website. Ist es leicht zu erraten (Namen, Geburtstage, etc.) oder zu kurz und
so durch einfaches Ausprobieren herauszunden, kann ein Angreifer im Namen des
Opfers agieren und so z.B. auf Kosten des Opfers einkaufen oder beim Online Banking
das Guthaben des Opfers auf vom Angreifer verwaltete Bankkonten umleiten. Aufgrund der Fülle an Benutzer-Konten bei verschiedensten Dienst-Anbietern, die ein
einzelner Benutzer heute besitzt, wird von vielen Benutzern das gleiche Passwort für
mehrere Dienste verwendet [Florencio und Herley 2007]. Damit reicht bereits ein
gehacktes Konto bzw. der Zugri auf ein einzelnes Passwort zu einem bestimmten
Konto, um dem Angreifer Zugri auf verschiedenste Dienste im Namen des Opfers zu
gewähren. Erschwerend kommt hinzu, dass Benutzer zu selten ihre Passwörter ändern
[Florencio und Herley 2007]. Zu kurze Passwörter machen es einem Angreifer
möglich, einfach alle möglichen Zeichenkombinationen auszuprobieren und so auf das
richtige Passwort zu stoÿen. Geht man beispielsweise von einem Passwort aus, das aus
acht Kleinbuchstaben besteht, so benötigt ein handelsüblicher Computer, der ca. vier
Milliarden Rechenoperationen pro Sekunde leistet, nur etwa eine Minute, um die richtige Kombination zu nden. Selbst bei der Wahl eines sicheren Passworts mit derzeit
3
mindestens zwölf alphanumerischen Zeichen sowie Sonderzeichen
bleibt das Risiko,
dass Schadsoftware, die möglicherweise im Betriebssystem des benutzten Computers
läuft, das Passwort mitlesen könnte. Es ist die Aufgabe des Benutzers sich vor derlei
Gefahren aktiv zu schützen, indem Virusscanner und Firewalls auf dem verwendeten Computer installiert und aktuell gehalten werden. In vielen Situationen, z.B. bei
der Benutzung öentlich zugänglicher Computer, hat der Benutzer allerdings keinerlei
Einuss auf die Sicherheitsausstattung und deren Wartung.
Die Authentizierung durch Besitz oder durch Eigenschaften, beispielsweise einer
SmartCard oder des Fingerabdrucks, setzt oft das Vorhandensein spezieller Lesegeräte voraus, was an öentlich zugänglichen Computern meist nicht der Fall ist. Neue
Verfahren wie eKaay
4
setzen daher auf Geräte wie Smartphones, die viele Benutzer
ständig bei sich tragen.
1.1 Motivation
eKaay ist ein Authentizierungssystem, mit dem sich der Benutzer statt mit Benutzername und Passwort mit Hilfe seines Smartphones bei Websites anmelden kann. eKaay
3 Rechendauer
hier: über 100000 Jahre
4 http://www.ekaay.com/
2
1.1 Motivation
ist ein SpinO der Universität Tübingen und wird dort seit 2011 produktiv zur Anmeldung beim Webmail-Service
5
der Universität genutzt. Der Name eKaay ist abgeleitet
von friesisch Kaay = Schlüssel (verwandt mit englisch key). Auÿerdem bedeutet
eKaay - ausgesprochen als
易开 - auf Chinesisch leicht zu önen. [Borchert 2013b]
Das eKaay-System besteht aus einem serverseitigen Teil, der die Anmeldung des
Benutzers koordiniert und mit der eigentlichen Website kommuniziert und einem Programm, das auf dem Smartphone des Benutzers läuft, einer sogenannten App.
6
7
Beim eKaay-Verfahren wird auf dem PC -Bildschirm ein QR -Code angezeigt, der
von der eKaay-App auf dem Smartphone gelesen wird. Die App führt den Anmeldevorgang über die vom PC unabhängige Internet-Verbindung des Smartphones durch und
der Benutzer wird so automatisch am PC eingeloggt. Das eigentliche Passwort bzw. der
Schlüssel für die Anmeldung wird dabei auf dem Smartphone abgelegt. Die Website,
die das eKaay-System nutzen will, muss dafür das eKaay-Verfahren lizenzieren und
8
mit Hilfe des bereitgestellten SDK
implementieren.
Der Benutzer muss sich also weder Benutzername noch Passwort merken. Gleichzeitig kommt für jedes Konto bei jedem Diensteanbieter ein eigener kryptographisch
abgesicherter Schlüssel zum Einsatz. Da der PC, an dem der Benutzer einen Dienst
benutzen möchte, nie mit den Zugangsdaten des Benutzers in Berührung kommt, ist
das eKaay-System auch dafür geeignet, potentiell unsichere Computer, z.B. in Internetcafés und an anderen öentlichen Orten für den Zugri auf sicherheitskritische Dienste
im Internet zu nutzen.
Optional kann die eKaay-App auf dem Smartphone durch eine PIN gesichert werden. Damit realisiert eKaay die Kombination aus Authentizierung durch Wissen der PIN - und Besitz - des Smartphones selbst mit dem darauf gespeicherten Schlüssel zum Online-Account. Diese besonders sichere Kombination nennt man 2-FaktorAuthentizierung.
Ein Manko des eKaay-Systems ist die immernoch vorhandene Notwendigkeit, bei
jedem Dienst-Anbieter ein Konto einrichten, persönliche Daten wie Name, E-MailAdresse usw. angeben und aktuell halten zu müssen.
5 http://www.zdv.uni-tuebingen.de/dienstleistungen/Sonstiges/Anleitungen/
eKaay-Login/
6 Personal
Computer
Response Code, ein 2D-Barcode
8 Software Development Kit
7 Quick
3
1 Einleitung
1.2 Thema und Ziel
Ziel dieser Arbeit ist es, eine zentrale Website, das eKaay-Portal, zu schaen, das
beliebige andere Websites zur Authentizierung ihrer Benutzer unter Nutzung der
oenen Standard-Protokolle OpenID und oAuth nutzen können. Somit wird es für
den Benutzer möglich, sich mit einer zentral am eKaay-Portal gespeicherten Identität
auf verschiedenen Websites anzumelden, ohne dort jeweils ein neues Benutzerkonto
erönen, persönliche Daten angeben und sich jeweils Passwörter merken zu müssen.
Auÿerdem entfällt der Aufwand für den Benutzer, auf den verschiedenen Websites
seine persönlichen Daten pegen zu müssen, da diese zentral vom eKaay-Portal zur
Verfügung gestellt und dort verwaltet werden können. Da es nicht mehr nötig ist, auf
jeder Website zunächst ein Konto anlegen zu müssen, das meist erst per E-Mail rückbestätigt werden muss, ist auch der Zeitaufwand für den Benutzer deutlich geringer.
Für Website-Betreiber besteht die Möglichkeit, die Benutzerverwaltung vollständig dezentral auszulagern, womit auch der Aufwand zur Sicherung der persönlichen Daten
und Passwörter der Benutzer entfällt. Diese Aufgabe käme dann dem eKaay-Portal zu.
Im Folgenden wird die Implementation des Systems beschrieben und auf die Vor- und
Nachteile der eingesetzten Authentizierungsprotokolle eingegangen. Schlieÿlich wird
ein Ausblick auf denkbare zukünftige Entwicklungen gegeben.
4
2 eKaay
2.1 Das eKaay-Verfahren
Hinter eKaay steckt die Idee, die Authentizierung auf Websites gegen mitlauschende
Schadsoftware abzusichern. In Abb. 2.1 wird der Ablauf schematisch dargestellt.
Abb. 2.1:
Ablauf des Login-Vorgangs bei Nutzung von eKaay [Borchert 2013a]
1. Der Benutzer möchte sich auf einer Website anmelden. Neben dem normalen
Benutzername/Passwort-Loginformular wird auch der eKaay QR-Code angezeigt.
2. Mit Hilfe der eKaay-App auf dem Smartphone scannt der Benutzer den QR-Code
3. Nachdem die eKaay-App die Anmeldung durchgeführt hat, ist der Benutzer am
Computerbildschirm bei dem gewünschten Dienst angemeldet.
Damit ein Benutzer den eKaay-Zugang zur Website nutzen kann, muss dort zunächst
ein herkömmliches Konto für den Benutzer existieren. Danach kann der eKaay-Zugang
für das Konto freigeschalten werden. Dazu zeigt der eKaay-Server einen speziellen QRCode, der die benötigten Informationen wie Server-Adressen, Benutzername und die
5
2 eKaay
Session-ID enthält. Die eKaay-App erzeugt daraufhin einen neuen asymetrischen kryp-
9
tographischen RSA -Schlüssel für das Konto. Bei der Verwendung von asymetrischer
Verschlüsselung wird ein Schlüsselpaar erzeugt, das einen öentlichen Teil enthält, der
frei verteilt werden kann sowie einen privaten Teil, der nur dem Besitzer zugänglich
ist. Mit dem öentlichen Teil des Paares kann eine Klartext-Nachricht verschlüsselt
werden, die danach nur mit Hilfe des privaten Teils des Schlüsselpaars wieder entschlüsselt werden kann. Auÿerdem kann der Besitzer des Schlüsselpaares mit seinem
privaten Schlüssel eine Klartext-Nachricht signieren, sodass der Empfänger mit Hilfe
des öentlichen Teils überprüfen kann, ob die Nachricht tatsächlich vom richtigen Absender kommt und nicht verändert wurde. Da das Schlüsselpaar beim eKaay-Verfahren
lokal auf dem Smartphone des Benutzers erzeugt und gespeichert wird, ist sichergestellt, dass ausschlieÿlich der Besitzer an ihn gerichtete, verschlüsselte Nachrichten
dekodieren sowie Klartext-Nachrichten signieren kann. Auch dem eKaay-Server ist
dies nicht möglich. Die eKaay-App registriert den öentlichen Teil beim eKaay-Server.
Beim späteren Login durch das Smartphone kann der eKaay-Server anhand der kryptographischen Signatur des Smartphones erkennen, ob der rechtmäÿige Benutzer sich
anmeldet.
Abb 2.2 zeigt schematisch die Einbindung von eKaay in bestehende Portale. Parallel
zum bestehenden Benutzername/Passwort-Login wird der eKaay-Server eingebunden,
der seinerseits die Anmeldung am Account Server des Portals übernimmt. Dabei müssen Account Server und eKaay-Server nicht zwingend auf dem selben physischen Server
laufen - der eKaay-Server kommuniziert mit dem Portal über HTTP
10
-Aufrufe.
Bei der Aktivierung eines neuen eKaay-Zugangs für ein bestehendes Konto wird vom
Account Server, der die Authentizierung der Nutzer verwaltet, ein zufälliges Token
11
erzeugt und in den Abruf des eKaay-QR-Codes integriert. Dieser Token wird vom
eKaay-Server über einen eigenen HTTP-Aufruf, also ohne dass der Internet-Browser
des Benutzers involviert ist, beim Account-Server auf Gültigkeit überprüft, sodass nur
dem authentizierten Benutzer die Aktivierung ermöglicht wird. Umgekehrt überprüft
der Account-Server bei jedem Login via eKaay anhand eines solchen Tokens, ob der
Loginversuch am eKaay-System tatsächlich authorisiert wurde. In Abb. 2.3 sind beide
Vorgänge dargestellt.
Kryptosystem, benannt nach seinen Erndern Rivest, Shamir und Adleman [Rivest et al. 1978]
Transfer Protocol
11 eine lange Zeichenkette aus Buchstaben und Zahlen
9 ein
10 Hypertext
6
2.2 Das eKaay-Portal
2.2 Das eKaay-Portal
12
Das eKaay-Portal läuft auf dem verbreiteten Apache
13
vollständig in PHP
Webserver unter Linux und ist
realisiert [Netcraft 2013]. Als Datenbank kommt das Open-
14
Source-Datenbankverwaltungssystem MySQL
zum Einsatz. Grundsätzlich ist das
eKaay-System allerdings dank der verwendeten (Skript-)Sprachen plattformunabhän-
15
gig und mit beliebigen SQL
-basierten Datenbanksystemen zu betreiben. Mit Hilfe
der beiden oenen, standardisierten Protokolle OpenID und oAuth können Diensteanbieter die Authentizierung ihrer Benutzer über das eKaay-Portal abwickeln.
2.3 Registrierungsprozess am eKaay-Portal
2.3.1 Benutzerregistrierung
In Abb. 2.4 ist das Registrierungsformular zur Auswahl eines Benutzernamens dargestellt. Sollte der gewünschte Benutzername bereits vergeben sein, ist eine erneute
Registrierung dieses Benutzernamens nicht möglich.
2.3.2 Portaloberäche
In Abb. 2.5 ist die Benutzeroberäche nach der Registrierung eines neues Nutzers
dargestellt. Das System fordert den Benutzer zunächst auf, den eKaay-Zugang auch
am Smartphone mit Hilfe der eKaay-App zu aktivieren.
2.3.3 Registrierung am Smartphone
Um die Account-Daten zum Smartphone zu transportieren, wird ein QR-Code angezeigt, der alle nötigen Daten enthält, um die Registrierung durchzuführen (Abb. 2.6).
Am Smartphone scannt die eKaay-App den Code (Abb. 2.7), extrahiert daraus die
Server-URL und den Benutzernamen und lässt den Benutzer den neuen Account bestätigen (Abb. 2.8). Danach wird lokal auf dem Smartphone ein Schlüsselpaar zur Kommunikation mit dem Server erzeugt. Über die Internetverbindung des Smartphones
wird danach der Account am Server bestätigt und das eKaay-Portal meldet die erfolg-
12 http://httpd.apache.org/
13 PHP:
Hypertext Preprocessor, eine Skriptsprache
14 http://www.mysql.com/
15 Structured
Query Language
7
2 eKaay
reiche Aktivierung des Accounts am PC-Bildschirm (Abb. 2.10). Gleichzeitig werden
die relevanten Informationen auch am Smartphone nochmals angezeigt (Abb. 2.9).
8
2.3 Registrierungsprozess am eKaay-Portal
Abb. 2.2:
Einbindung von eKaay in bestehende Portale [Borchert 2013a]
9
2 eKaay
Abb. 2.3:
10
Verizierung der Login/Registrierungsanfragen durch Token [Borchert 2013a]
2.3 Registrierungsprozess am eKaay-Portal
Abb. 2.4:
Registrierungsformular zur Wahl eines Benutzernamens
Abb. 2.5:
Benutzeroberäche des eKaay-Portals
11
2 eKaay
Abb. 2.6:
12
Initialisierung des neuen Accounts am Smartphone durch QR-Code
2.3 Registrierungsprozess am eKaay-Portal
Abb. 2.7:
Scannen des QR-Codes durch die eKaay-App am Smartphone
Bestätigung durch den Benut- Abb. 2.9: Rückmeldung am Smartphone
zer am Smartphone
nach erfolgreicher Aktivierung des eKaayAccounts
Abb. 2.8:
13
2 eKaay
Rückmeldung am Computer nach erfolgreicher Aktivierung des eKaay-Accounts
am Smartphone
Abb. 2.10:
14
2.3 Registrierungsprozess am eKaay-Portal
2.3.4 Verwaltung des Accounts
Abb. 2.11:
Verwaltungsoberäche des Portals
Sobald der Account vom Smartphone aktiviert wurde, kann der Benutzer seine persönlichen Daten am Portal speichern und bei Bedarf ein Notfall-Passwort setzen, das
bei Verlust des Smartphones verwendet werden kann. Zunächst ist die Liste der vertrauenswürdigen Websites leer (Abb. 2.11).
Damit ist das Benutzer-Konto am eKaay-Portal bereit für die Nutzung auf externen Websites. Diese können frei wählen, welches der beiden unterstützten Protokolle
verwendet werden soll. Im Folgenden wird auf beide Varianten eingegangen.
15
2 eKaay
16
3 OpenID
3.1 Begrie und zusätzliche Protokolle
Benutzer
Der Benutzer ist die reale Person, die das OpenID System nutzen will, um
sich bei webbasierten Diensten zu authentizieren.
Consumer Website oder Relying Party
Die Consumer Website bzw. in der OpenID-
Terminologie auch als Relying Party bezeichnet, ist die Website, auf der sich
Benutzer mittels OpenID anmelden können. Die Website konsumiert also die
persönlichen Daten des Nutzers, die vom Identity Provider zur Verfügung gestellt
werden [Rehman 2008].
Identier
16
Die URL
, die die digitale Identität des Benutzers identiziert, wird auch
Identier genannt.
Identity Provider
Der Identity Provider ist der Server, der die Benutzerdaten verwal-
tet. Im vorliegenden Fall ist dies das eKaay-Portal - beide Bezeichnungen werden
daher synonym verwendet. Der Identier zeigt auf den Identity Provider. Während der Authentizierung tauschen Consumer Website und Identity Provider
diverse Nachrichten aus, um den Identier zu validieren (angelehnt an Rehman
2008).
Yadis Discovery Protocol
Yadis bietet einen Mechanismus um verfügbare Services
an einer bestimmten URL aufzunden. Yadis ist ein einfaches, XML
17
-basiertes
Protokoll, das es der Consumer Website erlaubt, die verfügbaren Authentizierungsmechanismen und -protokolle eines Identity Providers zu identizieren und
die nötigen Metadaten abzufragen [Rehman 2008, Recordon und Reed 2006].
18
Typischerweise wird ein XML-Dokument im XRD
Format zurückgeliefert. Bei-
spielweise liefert das eKaay-Portal:
16 Uniform
Resource Locator
Markup Language, eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten
18 eXtensible Resource Descriptor
17 Extensible
17
3 OpenID
<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"
xmlns:openid="http://openid.net/xmlns/1.0">
<XRD ref="xri://=example">
<Query>*example</Query>
<Status ceid="off" cid="verified" code="100"/>
<Expires>2013-02-17T00:00:00.000Z</Expires>
<ProviderID>xri://=</ProviderID>
<!-- OpenID 2.0 Authentifizierungsdienst -->
<Service xmlns="xri://$xrd*($v*2.0)">
<Type>http://specs.openid.net/auth/2.0/server</Type>
<Type>http://specs.openid.net/extensions/pape/1.0</Type>
<URI>http://ekaay.kkdevs.com/server/server.php</URI>
</Service>
<Service xmlns="xri://$xrd*($v*2.0)">
<Type>http://specs.openid.net/auth/2.0/signon</Type>
<Type>http://specs.openid.net/extensions/pape/1.0</Type>
<URI>http://ekaay.kkdevs.com/server/server.php</URI>
<LocalID>http://specs.openid.net/auth/2.0/identifier_select</LocalID>
</Service>
<!-- OpenID 1.0 Authentifizierungsdienst -->
<Service>
<Type>http://openid.net/server/1.0</Type>
<URI>http://ekaay.kkdevs.com/server/server.php</URI>
<openid:Delegate>http://specs.openid.net/auth/2.0/identifier_select</openid:Delegate>
</Service>
</XRD>
</xrds:XRDS>
Im obigen Beispiel stehen mit OpenID 1.0 und OpenID 2.0 zwei verschiedene
Authentizierungsmechanismen zur Verfügung, sodass die Consumer Website
nach eigenem Ermessen entscheiden kann, welche Version benutzt werden soll.
Die-Hellmann-Protokoll
Das Die-Hellmann-Protokoll ermöglicht es zwei Kom-
munikationspartnern ein gemeinsames Geheimnis auszutauschen, ohne dass dieses Geheimnis jemals übertragen werden müsste. Dafür einigen sich beide Kommunikationspartner auf eine Primzahl und eine Primwurzel und berechnen daraus jeweils mit Hilfe einer Zufallszahl den geheimen Schlüssel. Aus den Nachrichten, die die Partner im Verlaufe der Schlüsselberechnung austauschen, lässt sich
der geheime Schlüssel im Allgemeinen nicht berechnen. [Rescorla 1999]
3.2 Konzept
OpenID setzt das Konzept der URL-basierten Identität um, d.h. ein Benutzer wird
über eine eindeutige URL, den Identier, identiziert. Dabei kommen bei OpenID
18
3.2 Konzept
HTTP-Adressen als URL zum Einsatz. Ein gültiger OpenID-fähiger Identier zur Verwendung mit dem eKaay-Portal wäre also z.B.:
http://ekaay.kkdevs.com/server/server.php/idpage?user=KevinKempfer
Wenn sich ein Benutzer auf einer Website anmelden möchte, die OpenID als LoginVerfahren akzeptiert, genügt es, dort als Benutzername http://ekaay.kkdevs.com anzugeben. Das eKaay-Portal (als Identity Provider) unterstützt dabei sowohl OpenID
1.0 als auch OpenID 2.0. Die Consumer Website wird zunächst selbst eine HTTP-
19
Verbindung zu der angegebenen URL herstellen und aus den dort vorhandenen HTML
Meta-Elementen
20
die korrekte URL des Identity Providers extrahieren. Alternativ
kann das Yadis Discovery Protocol zum Einsatz kommen, das eine feinere Steuerung
erlaubt. In beiden Fällen erhält die Consumer Website Informationen darüber, wie
die URL zum eigentlichen Identity Provider lautet. Dieser, als Delegation bekannte
Mechanismus, ermöglicht es auch, dass Benutzer auf ihrem eigenen, privat gehosteten Webspace diese Informationen hinterlegen und so unabhängig vom eKaay-Portal
eine eigene URL als Identier verwenden können, beispielsweise eine eigene Domain
(siehe dazu auch Kapitel 3.3, Schritt 5) [Recordon und Reed 2006]. Im nächsten
Schritt wird der Browser des Benutzers mit Hilfe eines HTTP Redirects an die URL
des Identity Providers umgeleitet, wobei weitere Informationen wie die RücksprungAdresse der Website und, mit der sogenannten
OpenID Simple Registration
, bis zu neun
gewünschte Benutzerinformationen, wie z.B. die E-Mail-Adresse, Vorname und Nachname, Spitzname oder die Zeitzone des Benutzers übermittelt werden. Der Identity
Provider authentiziert nun den Benutzer über eKaay, indem ein QR-Code angezeigt
wird, den der Benutzer mit der eKaay-App auf seinem Smartphone scannt. Diese
authentiziert sich gegenüber dem eKaay-System, welches schlieÿlich Zugang zum
Identity Provider gewährt. Beim ersten Anmeldeversuch auf einer externen Website
wird der Benutzer nun gefragt, ob der Consumer Website vertraut wird und die gewünschten persönlichen Informationen übermittelt werden sollen. Dabei wird dem
Benutzer auch die URL der Consumer Website angezeigt. Wenn der Benutzer die
Authentizierung bestätigt, speichert der Identity Provider dies in der lokalen Datenbank und leitet den Benutzer zurück zur Consumer Website, wobei die gewünschten
persönlichen Daten, z.B. Benutzername, E-Mail und vollständiger Name sowie die
eindeutige OpenID URL des Benutzers ebenfalls übermittelt werden. Damit ist der
19 Hypertext
Markup Language, eine Auszeichnungssprache zur Strukturierung von Inhalten in
Dokumenten
20 spezielle HTML-Elemente, die Metadaten zum Dokument enthalten
19
3 OpenID
Login-Vorgang abgeschlossen und die Consumer Website kann normal weiterarbeiten.
Sollte die Consumer Website beim Anmelden am Identity Provider bereits bekannt
und bestätigt sein, entfällt die Rückfrage für den Benutzer. Sollte auÿerdem bereits eine aktive Session am Identity Provider bestehen - der Benutzer also bereits via eKaay
angemeldet sein - entfällt auch der eKaay-Login und der Benutzer wird sofort wieder
zurück zur Consumer Website geleitet. Im Optimalfall - der Benutzer ist bereits am
Identity Provider angemeldet, die Session ist noch nicht abgelaufen und die Consumer
Website ist bereits bekannt und bestätigt - verlässt der Benutzer die Consumer Website
also faktisch nie; Sein Internet-Browser wird lediglich zweimal umgeleitet um schlieÿlich wieder auf der Consumer Website zu landen. Damit ist die Anmeldung also mit
Angabe der Portal-URL und einem Klick erledigt.
3.3 Technischer Ablauf
In Abb. 3.1 wird der technische Ablauf der Interaktion zwischen Endbenutzer, Consumer
Website und Identity Provider dargestellt.
1. Aufruf der Consumer Website
Der Benutzer ruft die Login-Seite der Consumer Website auf
2. Die Website liefert ein Login-Formular, in das der Benutzer seinen Identier
eingeben kann.
3. Der Benutzer schickt das Formular ab, der Identier wird zur Consumer Website
übertragen.
4. Die Consumer Website normalisiert den Identier, sodass eine gültige URL inklusive Protokoll-Präx wie http:// entsteht.
5. Mit Hilfe des Yadis-Protokolls wird die korrekte URL des Identity Providers
gesucht. Sollte die Suche fehlschlagen, wird versucht, diese Information durch
einen einfachen HTTP-Request, wobei eventuellen HTTP-Redirects gefolgt wird,
und anschlieÿendem Suchen in den HTML-Meta-Elementen des zurückgegebenen
Dokuments zu ermitteln. Ein Beispiel für solche Meta-Elemente ist:
<link
<link
<link
<link
<link
<meta
20
rel="openid.server" href="http://ekaay.kkdevs.com/server/server.php" />
rel="openid.delegate" href="http://specs.openid.net/auth/2.0/identifier_select"/>
rel="openid2.provider" href="http://ekaay.kkdevs.com/server/server.php" />
rel="openid2.local_id" href="http://specs.openid.net/auth/2.0/identifier_select"/>
rel="openid2.claimed_id" href="http://specs.openid.net/auth/2.0/identifier_select"/>
http-equiv="X-XRDS-Location" content="http://ekaay.kkdevs.com/server.xrds" />
3.3 Technischer Ablauf
Abb. 3.1:
Ablauf des Login-Vorgangs bei Nutzung von OpenID
(angelehnt an Stepka 2007)
Im obigen Beispiel werden beide OpenID Protokollversionen unterstützt.
6. Schlüsselaustausch
Die Consumer Website kontaktiert den Identity Provider um per Die-HellmannSchlüsselaustausch ein Shared Secret auszutauschen, mit dem die nachfolgende
Kommunikation gesichert wird (optional) [Rescorla 1999].
21
3 OpenID
7. Schlüsselaustausch
Der Identity Provider liefert das gewünschte Shared Secret bzw. AssoziationsHandle.
8. checkid_setup oder checkid_immediate Aufruf
Die Consumer Website leitet den Benutzer mittels HTTP Redirect zum Identity
Provider um. Dabei wird dem Identity Provider mit dem OpenID-Parameter
Mode mitgeteilt, ob eine Interaktion des Identity Providers mit dem Benutzer erwünscht ist (checkid_setup) oder ob der Identity Provider ohne direkte Interaktion das Ergebnis der Authentizierung zurückliefern soll (checkid_immediate).
21
Letzteres ist vor allem bei asynchronen Aufrufen mittels JavaScript (AJAX
)
nützlich.
9. Login
Falls der Benutzer noch nicht angemeldet ist, wird die Login-Seite des Identity
Providers dargestellt.
10. Login OpenID Endpoint Server
Der Benutzer meldet sich mit dem eKaay-Login auf seinem Smartphone an. Falls
der Benutzer die Consumer Website noch nicht authorisiert hat, wird er nach
der Erlaubnis gefragt, seine Identität an die Consumer Website liefern zu dürfen.
11. Ergebnislieferung
Das Ergebnis der Authorisierung wird der Consumer Website mitgeteilt, indem
der Browser des Benutzers per HTTP-Redirect zurück zur Consumer Website
umgeleitet wird.
12. check_authentication Request/Response
Wenn die Anmeldung erfolgreich war, veriziert die Consumer Website über
eine eigene Verbindung zum Identity Provider, ob die empfangenen Daten valide
sind. Dies ist optional, falls die Schritte 6 und 7 durchgeführt wurden. In diesem
Fall kann und muss die Consumer Website die empfangenen Daten anhand der
Server-Signatur verizieren.
13. Login Consumer Response
Der Login-Vorgang wird abgeschlossen und der Benutzer hat eine aktive Session
auf der Consumer Website.
21 Asynchronous
22
JavaScript and XML
3.4 Bewertung OpenID
3.4 Bewertung OpenID
Für OpenID spricht die relativ groÿe Verbreitung: Es gab bereits im Jahr 2009 etwa
neun Millionen Websites, die OpenID als Login-Verfahren akzeptieren und die somit
ohne Anpassungen für das eKaay-Verfahren nutzbar sind [Kissel 2009]. Auÿerdem
gibt es Plugins für viele gröÿere Software-Pakete wie Blogs, Content Management Systeme und andere internetbasierte Dienste, die OpenID als Login-Verfahren nachrüsten.
Im Vergleich zu oAuth (siehe Kapitel 4) ist die Komplexität der Implementation deutlich geringer, was ebenfalls zu mehr Akzeptanz bei Website-Betreibern führen dürfte.
Weiterhin treten viele groÿe Dienst-Anbieter wie Google, Yahoo oder AOL für Ihre
Nutzer als Identity Provider auf, womit sehr viele Internet-Nutzer bereits über eine
OpenID-URL verfügen.
Ein Nachteil des OpenID-Verfahrens ist die Notwendigkeit, den Benutzer-Browser
zum Identity Provider umzuleiten. Eine bösartige Website könnte statt zum echten
Identity Provider umzuleiten, auf eine eigene, identisch aussehende Seite umleiten
und so Benutzername und Passwort des Benutzers abgreifen. Dieses Szenario ist beim
eKaay-Portal nicht möglich, da der Benutzer keine Passwörter eingibt und sich die
Smartphone-App nur beim eKaay-Server authentizieren kann. Ein anderes Szenario wurde von Wang et al. (2012) gezeigt: Einige Websites, die OpenID als LoginVerfahren anbieten, prüfen die zurückgegebenen persönlichen Daten des Benutzers
nicht vollständig auf Validität, womit ein Angreifer sich als jemand anderes ausgeben
könnte, indem z.B. eine E-Mail-Adresse zu den zurückgegebenen Daten hinzugefügt
wird, die von der Consumer Website ursprünglich gar nicht angefordert wurde und
damit auch nicht durch die Server-Signatur abgedeckt ist. Es obliegt hierbei natürlich
der Consumer Website, die empfangenen Daten auch zu validieren.
Da die Spezikation von OpenID keinerlei Verschlüsselung vorsieht, ist die Kommunikation zwischen dem Browser des Benutzers und dem Identity Provider genau wie
die Kommunikation zwischen Consumer Website und Identity Provider grundsätzlich
abhörbar und anfällig für Man-In-The-Middle-Angrie, bei denen sich ein Angreifer
in die Kommunikation der beiden Kommunikationspartner einschaltet, die Nachrichten jeweils auf dem Weg vom einen zum anderen Kommunikationspartner abfängt
und möglicherweise ändert. Abhilfe schat hier laut Spezikation die Nutzung von
22
SSL
23
/TLS
22 Secure
zur Sicherung des HTTP-Verkehrs. [OpenID 2007] Aus Betreiber-Sicht
Sockets Layer, heute Transport Layer Security
Layer Security
23 Transport
23
3 OpenID
gibt es zudem weitere bedenkliche Eigenarten. So gibt der Benutzer eine beliebige, für
den Betreiber meist unbekannte URL an, zu der sich der Betreiber-Server im weiteren
Ablauf verbinden muss. Daraus ergeben sich oensichtlich Probleme, z.B. die Rückgabe groÿer Dateien oder sehr langsame Antworten, was bei Denial-of-Service-Angrien
genutzt werden könnte. Bei dieser Art von Angrien wird versucht, das Zielsystem
mit einer Flut von Daten oder einer hohen Anzahl gleichzeitiger Verbindungen zu
überlasten und es ihm so unmöglich zu machen, die Anfragen legitimer Nutzer zu
beantworten. Die Betreiber-Server könnten so auch für Port-Scans fremder Systeme
missbraucht werden, indem URLs so gewählt werden, dass sich aus den Antworten
Rückschlüsse auf die Konguration des Zielsystems ziehen lassen. Nicht zuletzt könnten bei mangelnder Absicherung auch interne Systeme des Service Providers durch
Angabe entsprechender URLs angegrien werden.
Darüber hinaus formuliert Dussa (2010) einige grundsätzliche Sicherheitsprobleme,
die es je nach Einsatzzweck zu bedenken gilt: Die Identität eines Benutzers wird bestätigt von einer dritten Instanz, die vorher nicht bekannt ist, deren Sicherheitsstandards
unklar sind und auf die der Nutzer verweist. Diese Tatsachen machen einen Einsatz
von OpenID als Authentizierungsmechanismus in sicherheitskritischen Bereichen, wie
z.B. Online Banking nur dann sinnvoll, wenn der Identity Provider dem Betreiber der
Consumer Website bekannt ist und dessen Sicherheitsrichtlinien und -standards überprüft wurden und ausreichend sind. Weiterhin muss zwingend gewährleistet sein, dass
die Kommunikation z.B. über SSL/TLS abgesichert und die empfangenen Daten validiert werden.
3.5 OpenID am eKaay-Portal
3.5.1 Server
Das eKaay-Portal wurde auf Basis der frei verfügbaren PHP OpenID library von Jan-
24
Rain
erstellt. Diese stellt einen OpenID Server Endpoint, der das OpenID-Protokoll
implementiert, und ein einfaches Portal-Beispiel bereit, das die Authentizierung via
OpenID ermöglicht und beide derzeit verbreiteten OpenID Protokoll-Versionen (1.0
und 2.0) unterstützt. Das System wurde mit Hilfe des eKaay-SDKs um den eKaayZugang erweitert.
Es wurde eine Benutzerverwaltung mit angeschlossener MySQL-Datenbank imple-
24 http://janrain.com/openid-enabled/
24
3.5 OpenID am eKaay-Portal
mentiert, sodass neue Benutzer sich selbst registrieren und anschlieÿend durch Scannen
des angezeigten QR-Codes den eKaay-Zugang zum eKaay-Portal auf dem Smartphone
freischalten können. Darüber hinaus kann der Benutzer nach dem Login am Portal seine persönlichen Daten bearbeiten und für seinen Account ein herkömmliches Passwort
setzen. Dieses Passwort kann z.B. zum Einsatz kommen, wenn das Smartphone gestohlen wurde oder momentan nicht verfügbar ist. Des Weiteren kann der Benutzer
die Liste der vertrauenswürdigen Websites, die Zugri auf die persönlichen Daten des
Nutzers haben, ansehen und die Einwilligung zur Datenweitergabe zu jedem Zeitpunkt
widerrufen.
Ohne Anpassungen kann somit jede Website, die OpenID als Login-Verfahren unterstützt, direkt das eKaay-Verfahren nutzen, um seine Benutzer authentizieren zu
lassen. Dabei genügt es, als Benutzername http://ekaay.kkdevs.com zu verwenden.
3.5.2 Client
Um externen Websites die Nutzung von eKaay via OpenID möglichst leicht zu machen, wurde ein ebenfalls in PHP geschriebenes Beispiel-Skript entwickelt (siehe auch
Kapitel 6.2), dass die Authentizierung via OpenID durchführt. Dies ist nicht auf das
eKaay-Portal beschränkt, sondern funktioniert mit jedem Dienstanbieter, der OpenID
als Login-Mechanismus unterstützt. Basierend auf der LightOpenID library
25
be-
schränkt sich der Programmieraufwand für die Betreiber einer Website auf weniger als
20 Zeilen PHP-Code:
<?
require('openid.php');
try {
$openid = new LightOpenID('client.ekaay.kkdevs.com'); //your local URL, displayed to the user
if(!$openid->mode) {
if(isset($_POST['login'])) {
$openid->identity = "http://ekaay.kkdevs.com";
$openid->required = array('contact/email');
$openid->optional = array('namePerson', 'namePerson/friendly');
header('Location: ' . $openid->authUrl());
}
} elseif($openid->mode == 'cancel') {
echo 'User has canceled authentication!';
} else {
echo 'User <b>' . ($openid->validate() ? $openid->identity . '</b> has ' :
'</b> has not ') . 'logged in.<br/><br/><pre>';
print_r($openid->getAttributes());
echo "</pre>";
25 http://mewp.s4w.pl/post/17
25
3 OpenID
}
} catch(ErrorException $e) {
echo $e->getMessage();
}?>
Im ersten Schritt wird der Browser des Benutzers zum eKaay-Portal umgeleitet,
um sich dort zu authentizieren. Dabei werden auch die gewünschten Datenfelder
übertragen, z.B. E-Mail-Adresse und Name des Benutzers. Nachdem der Benutzer
vom eKaay-Portal zurückgeleitet wurde, wird die Authentizierung validiert und die
mitgelieferten Datenfelder ausgegeben. Um den gleichen Code zur Authentizierung
gegenüber beliebigen OpenID Providern zu nutzen, genügt es, die Variable
$openid->identity
nicht fest vorzugeben, sondern beispielsweise durch den Benutzer in einem OpenIDLogin-Formular ausfüllen zu lassen.
26
4 oAuth
4.1 Begrie
Abweichend von den Begrien der OpenID-Terminologie verwendet oAuth folgende
Begrie:
Service Provider
Der Service Provider ist der Server, der die zu schützenden Ressour-
cen zur Verfügung stellt. Im vorliegenden Fall ist dies das eKaay-Portal - beide
Bezeichnungen werden daher synonym verwendet. Während der Authentizierung tauschen Consumer Website und Service Provider diverse Nachrichten aus,
um den Zugri auf die gewünschten Daten zu autorisieren.
Token
oAuth unterscheidet zwischen Abfrage-Token (Request Token), Zugangs-Token
(Access Token) und Erneuerungs-Token (Refresh Token). Diese werden anstelle von einer Benutzer-Name/Passwort-Kombination verwendet und können eine
zeitlich limitierte Gültigkeit haben.
Client ID
Jede Consumer Website erhält vom Service Provider eine eindeutige Client
ID, eine Art Benutzername, mit dem sich die Consumer Website gegenüber dem
Service Provider identiziert.
Client Secret
Jede Consumer Website erhält vom Service Provider ein Client Secret,
mit dem sich die Consumer Website bei direkten Anfragen beim Service Provider
authentiziert. Das Client Secret wird nie an den Internet-Browser des Benutzers
übertragen.
4.2 Konzept
Grundsätzlich ist oAuth nicht grundsätzlich dafür entwickelt worden, die Identität
des Benutzers zu bestätigen, sondern es dem Benutzer möglich zu machen, einer dritten Instanz den Zugri auf seine Daten, Dokumente, Bilder oder beliebige andere
Ressourcen beim Service Provider zu gewähren, ohne dass der Benutzer dafür seine
Login-Daten an die dritte Instanz abgeben muss. oAuth ist somit eher als Framework
27
4 oAuth
für API
26
-Zugrie im Namen des Benutzers zu denieren. Daher gestaltet sich die
Implementation des eKaay-Portals über oAuth etwas aufwändiger als bei OpenID.
Zunächst muss die Consumer Website sich grundsätzlich gegenüber dem eKaayPortal, das als Service Provider auftritt, authentizieren und erhält daher vom Service
Provider eine
Client ID
und ein
Client Secret
, die bei jeder direkten Anfrage zwischen
Consumer Website und Service Provider zur Authentizierung der Consumer Website
mitgeschickt wird. Somit kann das eKaay-Portal sicherstellen, dass die Consumer
Website berechtigt ist, die gewünschte Aktion durchzuführen. Da oAuth nicht für Authentizierungsanfragen speziziert ist und es daher keinen vordenierten Protokolluÿ zur Authentizierung gibt, muss die Consumer Website das vom eKaay-Portal bereitgestellte PHP-SDK implementieren, indem über den spezizierten oAuth ProtokollAblauf hinaus auch die nötigen API-Aufrufe zum Abruf der persönlichen Daten des
Benutzers festgelegt sind. Danach ist der grundsätzliche Ablauf aus Sicht des Benutzers
identisch mit dem Ablauf bei OpenID: (1) Anmeldung am eKaay-Portal via eKaayLogin am Smartphone, (2) Bestätigung der Datenfreigabe und (3) Umleitung zurück
zur Consumer Website. Eine Angabe eines Benutzernamens wie bei OpenID ist wegen der fest vorgegebenen Parameter dabei nicht nötig. Der Login-Vorgang auf der
Consumer Website ist also tatsächlich mit einem Mausklick möglich. Als Rückgabe
erhält die Consumer Website wie bei OpenID die freigegebenen persönlichen Daten
des Benutzers.
Die Consumer Website kann den vom Service Provider erhaltenen Access Token
speichern, um nachfolgende Zugrie auf die API des Service Providers - auch ohne
dass der Benutzer involviert ist - durchzuführen. Im Zusammenspiel mit dem eKaayPortal könnte eine Consumer Website also regelmäÿig die persönlichen Daten des
Benutzers aktualisieren, ohne dass der Benutzer dies erneut authorisieren oder auch
nur die Consumer Website nutzen müsste. Da sich Access Tokens nicht widerrufen
lassen, sind diese meist mit einer Verfallszeit versehen. Nach Ablauf dieser Zeit verliert
der Access Token seine Gültigkeit. Es steht der Consumer Website in diesem Fall frei,
mit Hilfe eines Refresh Tokens erneut einen Access Token anzufordern.
4.3 Technischer Ablauf
In Abb. 4.1 wird der technische Ablauf der Interaktion zwischen Endbenutzer, Consumer
Website und Service Provider dargestellt.
26 Application
28
Programming Interface
4.3 Technischer Ablauf
Abb. 4.1:
Ablauf des Login-Vorgangs bei Nutzung von oAuth 1.0a
1. Durch Klick auf den eKaay-Login-Button o.ä. wird der Login-Vorgang durch den
Benutzer gestartet.
2. Die Consumer Website fordert beim Service Provider (hier: das eKaay-Portal)
einen
unauthorized request token
an und übermittelt dabei seine individuelle
Client ID und optional eine Redirect-URL, zu der der Service Provider den
Benutzer umleitet.
29
4 oAuth
3. Der Service Provider überprüft Client ID und die Redirect-URL und liefert den
unauthorized request token
zurück.
4. Die Consumer Website leitet den Benutzer zur Login-Seite des eKaay-Portals
um und liefert dabei den
unauthorized request token
mit.
5. Das eKaay-Portal liefert dem Benutzer die Login-Seite aus. Dabei wird der QRCode zum Login via Smartphone angezeigt.
6. Der Benutzer meldet sich mit seinem Smartphone an und authorisiert die Consumer
Website für den Zugri auf seine persönlichen Daten.
7. Das eKaay-Portal leitet den Endbenutzer zurück zur Consumer Website und
übermittelt dabei auch einen
authorized request token
.
8. Der Browser des Benutzers ruft die angegebene Redirect-URL ab.
9. Die Consumer Website fordert mit dem mitgelieferten
einen
access token
authorized request token
an, wobei Client ID und Client Secret ebenfalls übermittelt
werden.
10. Das eKaay-Portal erzeugt und übermittelt den angeforderten
access token
.
11. Die Consumer Website hat nun Zugri auf eine bestätigte Authentizierung des
Nutzers und kann optional die persönlichen Daten des Benutzers anfordern.
12. Das eKaay-Portal liefert die gewünschten Daten.
13. Der Login-Vorgang ist damit abgeschlossen und die Consumer Website liefert
dem Benutzer die angeforderte Website mit aktiver Login-Session aus.
Davon abweichend ist der Protokoll-Fluÿ von oAuth 2.0 in Abb. 4.2 dargestellt.
Hier entfällt der Abruf des unauthorized request token. Der Benutzer wird direkt zum
eKaay-Portal umgeleitet. Die restlichen Vorgänge sind analog zu oAuth 1.0a, allerdings
gibt es keine Signaturen der Anfragen mehr. Seit Version 2.0 wird ausschlieÿlich auf
SSL/TLS zur Absicherung der Kommunikation gesetzt [oAuth 2012].
30
4.4 Bewertung
Abb. 4.2:
Ablauf des Login-Vorgangs bei Nutzung von oAuth 2.0
4.4 Bewertung
Ein Vorteil des oAuth Verfahrens sind die wiederverwendbaren Access Tokens, die die
Consumer Website speichern kann. Innerhalb der Gültigkeitsdauer des Access Tokens
(meist mehrere Tage oder Wochen) kann die Consumer Website jederzeit erneut eine Authentizierung beim Identity Provider anfragen, ohne dafür den Benutzer zu
involvieren. Ein einmal auf der Consumer Website angemeldeter Benutzer könnte
31
4 oAuth
also z.B. mittels Cookies markiert und so bei jedem Besuch wiedererkannt werden.
Die Consumer Website könnte in diesem Fall im Hintergrund vom Identity Provider
die persönlichen Daten des Benutzers aktualisieren, ohne dass der Benutzer dafür etwas tun muss. Selbst nach Ablauf der Gültigkeitsdauer des Access Tokens kann die
Consumer Website diesen erneuern. Sollte der Benutzer zwischenzeitlich sein Einverständnis zum Zugri auf die Identität oder die persönlichen Daten widerrufen haben,
schlägt der Versuch fehl und die Authentizierung und Bestätigung der Freigabe muss
erneut stattnden. Der Consumer Website steht es aber auch frei, den Access Token
nach erfolgreicher Authentizierung direkt zu verwerfen und ähnlich wie OpenID bei
jedem neuen Besuch des Benutzers erneut die Authentizierung zu starten - wovon
der Benutzer im Optimalfall nichts bemerkt. Negativ fällt auf, dass in der aktuellen
Version 2.0 von oAuth alle Signaturen zur Absicherung der übermittelten Daten entfernt wurden und die gesamte Sicherheit des Protokolls nun auf der Absicherung des
HTTP-Verkehrs beruht, üblicherweise durch TLS
27
. Viele groÿe Service Provider ha-
ben allerdings abweichend vom Standard nach wie vor die Anforderung an ihre Nutzer,
die gesamte Kommunikation mit Signaturen abzusichern.
4.5 oAuth am eKaay-Portal
4.5.1 Server
Der OpenID Server Endpoint wurde um oAuth als weiteres Authentizierungsprotokoll erweitert. Hierzu kam die ebenfalls frei verfügbare oAuth2-server-php library von
28
Brent Shaer
zum Einsatz. Nach erfolgreicher Authentizierung via oAuth wird da-
bei der Benutzer in einem weiteren internen Schritt auch am OpenID Server Endpoint
angemeldet, was die Nutzung beider Protokolle auch parallel je nach Belieben der
Consumer Website möglich macht. Somit wird die gesamte Verwaltung der laufenden
Sitzung vom OpenID Server Endpoint übernommen, auch wenn oAuth zur Authentizierung verwendet wird. Die Einbindung weiterer Authentizierungsprotokolle ist
somit einfach möglich.
27 Transport
Layer Security
28 https://github.com/bshaffer/oauth2-server-php
32
4.5 oAuth am eKaay-Portal
4.5.2 Client
Auch für die oAuth-Variante des eKaay-Logins wurde ein PHP-SDK bereitgestellt,
dass beispielhaft die Einbindung in bestehende Websites demonstriert. Dabei kommt
oAuth 2.0 zum Einsatz:
$endpoint = "http://ekaay.kkdevs.com/oauth/";
if(isset($_GET['code'])){
$code= $_GET['code'];
$query = array(
'grant_type' => 'authorization_code',
'code'
=> $code,
'client_id' => 'test',
'client_secret' => 'testkey',
'redirect_uri' => 'http://client.ekaay.kkdevs.com/client/oauth.php',
);
$curl = new Curl();
$response = $curl->request($endpoint, $query, 'POST');
$arr_response = json_decode($response['response']);
if(isset($arr_response->user_id)){
echo "User <b>".$arr_response->user_id."</b> has successfully logged in.<br/><br/>";
$query = array(
"access_token" => $arr_response->access_token,
"action" => "getUserDetails"
);
$response = $curl->request($endpoint, $query, 'GET');
$arr_response = json_decode($response['response']);
echo "<pre>";
print_r($arr_response);
echo "</pre>";
}
}else{
header("Location: $endpoint/?client_id=test&response_type=code".
"&redirect_uri=http://client.ekaay.kkdevs.com/client/oauth.php&state=".uniqid(null,true));
}
Zunächst wird der Browser der Benutzers zum eKaay-Portal umgeleitet, um den Authentizierungsvorgang zu starten. Nachdem eine Bestätigung in Form eines authorized
request tokens vorliegt, wird dieser mittels einer eigenen HTTP-Verbindung zwischen
Anbieter-Server und eKaay-Portal in einen authorisierten Code getauscht (authorized
access token), mit dem der Zugri auf die persönlichen Daten des Nutzers möglich wird.
Aus Gründen der Übersichtlichkeit wurde hier auf Fehlerbehandlungen etc. verzichtet.
Facebook Login
Websites, die bereits Facebooks serverseitiges Login-Verfahren
29
nutzen, haben bei der
Implementierung von oAuth für eKaay einen besonders geringen Aufwand. Facebook
29 https://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/
33
4 oAuth
benutzt ebenfalls oAuth zur Authentizierung. Grundsätzlich kann daher für die Verwendung von eKaay der gleiche serverseitige Code zum Einsatz kommen, der auch für
den Facebook-Login verwendet wird
30
. Lediglich die URL des oAuth Endpoints muss
auf das eKaay-Portal zeigen und die Client ID bzw. Client Secret müssen entsprechend
angepasst werden. Um die persönlichen Daten des Benutzers abzurufen, kann danach
der obige getUserDetails-Aufruf verwendet werden.
30 genauso
34
wie obiger Code mit wenigen Anpassungen auch mit dem Facebook Login funktioniert
5 Vergleich OpenID vs. oAuth
Zusammenfassend fällt im direkten Vergleich von OpenID und oAuth auf:
•
OpenID
+ OpenID ist für Authentizierung erdacht worden. Es besteht eine hohe
Interoperalität zwischen Websites, die OpenID implementieren und Identity
Providern.
+ Einfache Implementierung für Consumer Websites, daher bereits hohe Verbreitung.
- Identier, die frei vom Benutzer übermittelt werden können, bergen Sicherheitsrisiken (siehe Kapitel 3.4).
- Datenaustausch nur innerhalb der Grenzen des Protokolls.
•
oAuth
+ deutlich höhere Flexibilität gegenüber OpenID für nachfolgende API-Zugrie
+ keine Vorgaben zum Datenaustausch durch das Protokoll
- oAuth ist eher ein API-Framework. Zur Nutzung für Authentizierung sind
enge Absprachen zwischen Consumer Website und Identity Provider nötig.
Daher vergleichsweise wenig Verbreitung.
- Sicherheit ist nur durch TLS- bzw. SSL-Verschlüsselung gegeben, seit oAuth
2.0 gibt es keine Signaturen mehr. Allerdings implementieren viele Service
Provider eigenmächtig Signaturen, die jede Anfrage und Antwort absichern.
Zwischenzeitlich gibt es erste Ansätze, die Vorteile beider Protokolle zu vereinen und
die Nachteile dabei zu beheben. Beispielsweise setzt Google bei seinem Federated
Login for Google Account Users
31
32
das Protokoll step2
ein, ein OpenID+OAuth
Hybrid-Protokoll, das auch bereits als Erweiterung zu oAuth vorgeschlagen
33
wurde.
31 https://developers.google.com/accounts/docs/OpenID
32 https://code.google.com/p/step2/
33 http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_
extension.html
35
5 Vergleich OpenID vs. oAuth
36
6 Login auf externen Websites
6.1 Demo des OpenID Logins
Abb. 6.1:
Login mit OpenID am Beispiel von stackoverow.com
Am Beispiel von stackoverow.com, das auf eigene Benutzerkonten optional verzichtet, zeigt Abb. 6.1 ein Login-Formular mit der Möglichkeit, sich via OpenID anzumelden. Stackoverow.com benötigt dafür keine Kenntnis des eKaay-Portals. Nach
Eingabe des generischen Identiers und der Hintergrund-Abläufe am Server (siehe Kapitel 3.3), wird der Benutzer in Abb. 6.2 zum eKaay-Portal umgeleitet. Nach dem
Scannen des QR-Codes und erfolgreichem Login fragt das Portal in Abb. 6.3 den Benutzer, ob stackoverow.com auf seine Identität zugreifen darf. Wird dies bestätigt,
speichert das eKaay-Portal die Entscheidung in der lokalen Datenbank und leitet den
Benutzer zurück zu stackoverow.com. Damit ist der Login-Vorgang abgeschlossen.
37
6 Login auf externen Websites
Abb. 6.2:
Automatische Weiterleitung zum eKaay-Portal und Login
Abb. 6.3:
38
Bestätigung durch den Benutzer
6.1 Demo des OpenID Logins
Abb. 6.4:
Verwaltungsoberäche des Portals mit bereits bestätigter Consumer Website
In Abb. 6.4 ist nun auch in der Verwaltungsoberäche des eKaay-Portals die eben
bestätigte Website aufgeführt. Der Zugri durch stackoverow.com kann hier jederzeit
widerrufen werden.
39
6 Login auf externen Websites
6.2 Demo des oAuth Logins
Da bei Verwendung von oAuth auch die Consumer Website aktiv das eKaay-PortalSDK implentieren muss, wurde im Zuge dieser Arbeit auch eine Demonstration dieser
Funktionalität entwickelt. Dazu wurde eine vom eKaay-Portal vollständig unabhängige Website
34
erstellt, die zu Demonstrationszwecken neben den beiden eKaay-Login-
Möglichkeiten oAuth und OpenID auch den Facebook-Login zur Verfügung stellt. Da
Facebook intern ebenfalls oAuth einsetzt, sind beide Varianten vergleichbar. Abb. 6.5
zeigt die Demo-Seite nach erfolgreichem Login mittels oAuth.
Abb. 6.5:
Demo-Seite nach Login mit oAuth
34 http://client.ekaay.kkdevs.com/client/
40
7 Diskussion
Auch das eKaay-Verfahren ist nicht der heilige Gral des Datenschutzes. Durch die
Zentralisierung der Benutzer-Identitäten wäre es durchaus möglich, sämtliche LoginVorgänge der Endbenutzer zu protokollieren und zur Erstellung individueller Prole
auszuwerten. Diese Prole könnten ein detailliertes Bild der Vorlieben einzelner Nutzer
ergeben und wären daher insbesondere für die Marketing-Branche ein lohnendes Ziel
- nicht ohne Grund bieten Branchenriesen wie Google oder Yahoo ihren Nutzern an,
den jeweiligen Account als OpenID-Identier auf beliebigen Websites einzusetzen - und
jedes Mal darüber informiert zu werden,
wo der Benutzer sie einsetzt.
Aus Sicht des Nutzers kann es ebenfalls problematisch sein, seine digitale Identität
in die Hände eines zentralen Portals zu legen. Das Portal selbst wäre für Hacker und
Daten- bzw. Identitätsdiebe ein lukratives Ziel. Sollte der Portal-Server kompromittiert
werden, stünden einem Angreifer die persönlichen Daten und - noch schlimmer - direkte
Zugänge zu den von den Benutzern genutzten Accounts zur Verfügung. Dabei spielt
es keine Rolle, dass die eigentlichen Kryptoschlüssel sicher auf den Smartphones der
Benutzer abgelegt sind. Mit der Kontrolle über den Portal-Server könnte ein Angreifer
jede Authentizierungsanfrage positiv beantworten und so Zugang zum gewünschten
Account erhalten.
Es ist also die mit Abstand dringlichste Aufgabe des eKaay-Portal-Betreibers, die
eingesetzte Infrastruktur bestmöglich gegen Angrie zu schützen, um das Vertrauen
der Benutzer zu gewinnen.
Aus Sicht des Betreibers einer Consumer Website ist es eventuell problematisch, sich
an einen externen Authentizierungsanbieter wie eKaay zu binden, ohne die verwendete Technik selbst kontrollieren zu können. Damit begibt sich der Anbieter in eine
(auch kommerzielle) Abhängigkeit - immerhin könnte der Betreiber des eKaay-Portals
jederzeit sein Geschäftsmodell ändern oder dieses ganz aufgeben. Die dezentrale Auslagerung des Authentizierungsmechanismus hat also neben den genannten Vorteilen
auch einige Nachteile. Daher wird es aus Betreiber-Sicht immer abzuwägen sein, ob
die Vorteile der unabhängigen, bilateralen Lösung, das eKaay-Verfahren zu lizensieren
und im eigenen Hause zu betreiben, die Nachteile, die sich aus der Abhängigkeit vom
41
7 Diskussion
eKaay-Portal-Betreiber bei der zentralisierten Lösung ergeben, überwiegen:
•
bilaterale in-house-Lösung
+ keine Abhängigkeit vom Betreiber eines zentralen Portals
+ eigenes Branding möglich
+ direkte Kontrolle über den Authentizierungsmechanismus
- Website-Nutzer müssen weiterhin ihren Account bei der Website anlegen
und pegen
- höherer Implementierungsaufwand
•
zentrale Portal-Lösung
+ minimaler Implementierungsaufwand
+ hoher Komfort für den Benutzer
- Abhängigkeit von Verfügbarkeit und Geschäftsmodell des Portal-Betreibers
42
8 Ausblick
Zusätzlich zur bestehenden Implementation sind in der Praxis verschiedene Erweiterungen denkbar:
Weitere Protokolle
Die Einbindung weiterer Authentizierungsprotokolle für die Be-
35
nutzerauthentizierung am eKaay-Portal, wie CAS
36
, Shibboleth oder LDAP
,
ist analog zur Erweiterung um oAuth einfach und schnell durchführbar.
Mehrere Identitäten
Der Benutzer könnte mehrere unterschiedliche virtuelle Iden-
titäten am eKaay-Portal anlegen und über einen einzigen Account verwalten.
Somit könnten beispielsweise private und geschäftliche Identitäten voneinander
getrennt werden oder unterschiedliche Nicknames zur Benutzung in InternetForen oder sozialen Netzwerken benutzt werden. Damit erhöht sich die Anonymität des Benutzers. Während des Daten-Freigabe-Dialogs bei der Authorisierung
einer Consumer Website könnte der Benutzer dabei die gewünschte Identität
auswählen.
feingranulare Freigabe persönlicher Daten
Der Benutzer könnte selbst und für je-
de Consumer Website einzeln entscheiden, auf welche der angefragten persönlichen Daten die jeweilige Consumer Website Zugri haben darf. Damit wird
die Kontrolle über die persönlichen Daten weitestgehend dem Benutzer selbst
gegeben.
Wegwerf-Identitäten
Das System könnte dem Benutzer anbieten, während einer
Identitätsanfrage selbständig ktive Identitäten zu erzeugen und an die Consumer
Website zu übermitteln, evtl. sogar inklusive einer Wegwerf-E-Mail-Adresse, die
nur eine kurze Lebensdauer hat. Damit ist maximale Anonymität des Benutzers
und Schutz vor Spam-E-Mails gewährleistet, ohne dass sich der Benutzer selbst
um die Erstellung solcher Wegwerf-Identitäten kümmern müsste.
35 Central
Authentication Service
Directory Access Protocol
36 Lightweight
43
8 Ausblick
Sicherheit der eKaay-App
Um auch das Smartphone gegen Lauschangrie zu schüt-
zen, kann die eKaay-App selbst erweitert werden, sodass nicht die App die notwendigen kryptographischen Operationen durchführen muss, sondern diese Auf-
37
gabe z.B. einer SmartCard, die mit der eKaay-App z.B. per NFC
kommuniziert,
zufällt. Damit wird das Smartphone zum Kartenleser degradiert, die Speicherung
der Krypto-Schlüssel und die Verschlüsselung fände auf der SmartCard statt
[Borchert und Gunther 2013].
37 Near
44
Field Communication, ein Nahfunk-Standard
Abkürzungen
AJAX
Asynchronous JavaScript and XML
API
Application Programming Interface
CAS
Central Authentication Service
HTML
Hypertext Markup Language, eine Auszeichnungssprache zur Strukturierung
von Inhalten in Dokumenten
HTTP
Hypertext Transfer Protocol
LDAP
Lightweight Directory Access Protocol
NFC
Near Field Communication, ein Nahfunk-Standard
PC
Personal Computer
PHP
PHP: Hypertext Preprocessor, eine Skriptsprache
PIN
Personal Identication Number
QR
Quick Response Code, ein 2D-Barcode
RSA
ein Kryptosystem, benannt nach seinen Erndern Rivest, Shamir und Adleman
[Rivest et al. 1978]
SDK
Software Development Kit
SQL
Structured Query Language
SSL
Secure Sockets Layer, heute Transport Layer Security
TLS
Transport Layer Security
URL
Uniform Resource Locator
XML
Extensible Markup Language, eine Auszeichnungssprache zur Darstellung
hierarchisch strukturierter Daten
45
8 Ausblick
XRD
46
eXtensible Resource Descriptor
Abbildungsverzeichnis
2.1
Schematischer Ablauf eKaay . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Einbindung von eKaay in bestehende Portale . . . . . . . . . . . . . . .
9
2.3
Verizierung durch Tokens . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.4
Registrierungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.5
eKaay-Portal Oberäche
. . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.6
Account-Initialisierung
. . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.7
Scannen des QR-Codes . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.8
Bestätigung am Smartphone . . . . . . . . . . . . . . . . . . . . . . . .
13
2.9
Rückmeldung am Smartphone . . . . . . . . . . . . . . . . . . . . . . .
13
2.10 Rückmeldung am Computer
. . . . . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1
Schematischer Ablauf OpenID . . . . . . . . . . . . . . . . . . . . . . .
21
4.1
Schematischer Ablauf oAuth 1.0a
. . . . . . . . . . . . . . . . . . . . .
29
4.2
Schematischer Ablauf oAuth 2.0 . . . . . . . . . . . . . . . . . . . . . .
31
6.1
Beispiel stackoverow.com
. . . . . . . . . . . . . . . . . . . . . . . . .
37
6.2
Login am eKaay-Portal . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
6.3
Bestätigung durch den Benutzer . . . . . . . . . . . . . . . . . . . . . .
38
6.4
Verwaltungsoberäche mit bestätigter Consumer Website . . . . . . . .
39
6.5
Demo-Seite mit oAuth-Login . . . . . . . . . . . . . . . . . . . . . . . .
40
2.11 Verwaltungsoberäche
47
Abbildungsverzeichnis
48
Literaturverzeichnis
eKaay
Borchert, Bernd (2013a).
.
http://www.ekaay.com
online.
Abruf am
21.05.2013.
Borchert, Bernd (2013b).
about/
eKaay - Über uns
.
http://www.ekaay.com/
online.
Abruf am 20.05.2013.
Indirect NFC-Login
http://
www-ti.informatik.uni-tuebingen.de/~borchert/papers/NFC-Login.pdf Ab-
Borchert, Bernd und M. Gunther (2013).
. online.
ruf am 02.07.2013.
Bundeskriminalamt
(2012).
CYBERCRIME Bundeslagebild 2011
.
online.
http://www.bka.de/nn_205994/SharedDocs/Downloads/DE/Publikationen/
JahresberichteUndLagebilder/Cybercrime/cybercrime2011,templateId=
raw,property=publicationFile.pdf/cybercrime2011.pdf Abruf am 20.05.2013.
Dussa,
Tobias
(2010).
OpenID-Sicherheit
.
3. DFN-Forum KT
In:
.
https://www.dfn.de/fileadmin/3Beratung/DFN-Forum3/Dussa-OpenID_
unter_Sicherheitsgesichtspunkten.pdf Abruf am 13.05.2013.
A large-scale study of web password
Proceedings of the 16th international conference on World Wide Web
Florencio, Dinei und C. Herley (2007).
habits
.
In:
,
WWW '07, S. 657666, New York, NY, USA. ACM.
Kissel, Brian (2009).
OpenID 2009 Year in Review
2009/12/16/openid-2009-year-in-review/
. online.
http://openid.net/
Abruf am 21.05.2013.
May 2013 Web Server Survey
http://news.
netcraft.com/archives/2013/05/03/may-2013-web-server-survey.html Ab-
Netcraft
(2013).
.
online.
ruf am 20.05.2013.
oAuth (2012).
The OAuth 2.0 Authorization Framework
ietf.org/html/rfc6749
.
online.
http://tools.
Abruf vom 02.07.2013.
49
Literaturverzeichnis
OpenID (2007).
OpenID Authentication 2.0 - Final
specs/openid-authentication-2_0.html
. online.
http://openid.net/
Abruf vom 20.05.2013.
OpenID 2.0: a platform for user-centric
Proceedings of the second ACM workshop on Digital
Recordon, David und D. Reed (2006).
identity management
identity management
.
In:
, DIM '06, S. 1116, New York, NY, USA. ACM.
Get Ready for Openid
Die-Hellman Key Agreement Method
Rehman, Rafeeq Ur (2008).
Rescorla, E. (1999).
. Conformix Technologies Inc.
. RFC 2631 (Proposed
Standard).
Rivest, R. L., A. Shamir und L. Adleman (1978).
signatures and public-key cryptosystems
What is OpenID?
A method for obtaining digital
. Commun. ACM, 21(2):120126.
Stepka, Justen (2007).
.
[https://www.dfn.de/fileadmin/
3Beratung/DFN-Forum3/Dussa-OpenID_unter_Sicherheitsgesichtspunkten.
pdf Abruf vom 13.05.2013].
Signing Me onto Your Accounts through
Facebook and Google: A Trac-Guided Security Study of Commercially Deployed
Single-Sign-On Web Services
Proceedings of the 2012 IEEE Symposium on
Security and Privacy
Wang, Rui, S. Chen und X. Wang (2012).
.
In:
, SP '12, S. 365379, Washington, DC, USA. IEEE Computer
Society.
50