Technische Universität München Fachgebiet Verteilte Multimodale Informationsverarbeitung. Prof. Dr. Matthias Kranz. Diplomarbeit

Größe: px
Ab Seite anzeigen:

Download "Technische Universität München Fachgebiet Verteilte Multimodale Informationsverarbeitung. Prof. Dr. Matthias Kranz. Diplomarbeit"

Transkript

1 Technische Universität München Fachgebiet Verteilte Multimodale Informationsverarbeitung Prof. Dr. Matthias Kranz Diplomarbeit Einbindung des Smartphones in eine Single Sign-On (SSO) Architektur mittels QR-Codes Autor: Christian Beck Betreuer: Dipl.-Ing. Luis Roalter Beginn: Abgabe:

2 Kurzfassung Single Sign-On (SSO) erlaubt es einem Benutzer zwar sich zentral für die Verwendung mehrerer Internetdienste zu authentifizieren, es gibt bisher jedoch kaum Ansätze die die Verwendung eines Smartphones in solch einem Verfahren vorsehen. Diese Arbeit umfasst die Ausarbeitung eines Konzeptes zur Integration eines Smartphones in eine Single Sign- On Architektur und die Erstellung einer Implementierung zur Demonstration der Validität dieses Konzeptes. Die vorgeschlagene Lösung basiert auf der Verwendung von Quick Response Codes für die Herstellung einer Verbindung zwischen dem Mobilgerät und dem Rechner des Benutzers. Es wird detailliert erklärt wie diese Verbindung realisiert werden kann und gezeigt welche Vorteile sich daraus ergeben. Vor allem die Sicherheit des Verfahrens profitiert direkt von der Integration eines zweiten Kanals und dem Entfallen der wiederholten Übermittlung von Passwörtern. Die Implementierung eines testfähigen Prototyps, der neben einer Anwendung für die Android-Plattform auch den neuen Bedürfnissen angepasste Lösungen für den SSO-Server und die abhängigen Dienste umfasst, erlaubte die Ausarbeitung neuer Verfahren. Hierbei wird das Smartphone nicht nur eingesetzt um die Authentifizierung des Benutzers zu unterstützen. Durch die Möglichkeit eine aktive Sitzung an das Smartphone zu übertragen, oder direkt im Browser zu authentifizieren, wird das Mobilgerät aktiv als Endgerät für den Zugriff auf geschützte Inhalte eingebunden. Darüber hinaus wurden Lösungen für zahlreiche Probleme vorgeschlagen, die sich aus dem veränderten Verfahren ergeben. So wird etwa dargestellt wie sich die Einbindung der abhängigen Dienste einfach realisieren lässt, Sitzungs- und Benutzerinformationen verwaltet werden können und wie das Verfahren für die Verwendung mit OpenID angepasst werden kann. 2

3 Abstract Although single sign-on (SSO) mechanisms adept many different approaches to enhance ease of use and security in login procedures, none of them seem to fully support the use of smartphones. This thesis describes a concept for integrating smartphones in a SSO procedure and the implementation of a proof-of-concept prototype. The proposed solution relies on the use of Quick Response codes (QR codes) to create a connection between the client-computer and the users mobile device. The concept includes a detailed explanation of the realization of this link and of the advantages which it implies. Especially the security of the procedure is directly enhanced by the use of a second channel and the omission of redundant password transmissions. The implementation of a testable prototype which includes an application for the Android platform and adapted solutions for the SSO-Server and the relying services, allowed exploring new possibilities. These possibilities extend the role of the smartphone beyond the support of the authentication method. Implemented features, such as transferring sessions to the smartphone or directly authenticating sessions in the mobile browser, also establish the smartphone as viable client device for accessing protected content. Moreover this thesis addresses a multitude of problems in the scope of the new procedure. Amongst others, proposed solutions include an easy integration of relying parties, the management of session and user information and the association with OpenID. 3

4 Inhaltsverzeichnis Inhaltsverzeichnis 4 1 Einleitung Motivation Überblick Stand der Technik Single Sign-On Aufbau und Ablauf OpenID Der Einsatz von Cookies im Rahmen einer SSO-Architektur Quick Response Codes QR-Codes als Träger für Einmalkennwörter QR-Codes für die Authentifizierung beim Online-Banking Android Smartphones Aufbau einer Applikation Sicherheit Zebra Crossing Konzept Grundlagen Anforderungen Anforderungen an das Mobilgerät Anforderungen an das Kommunikationsprotokoll Anforderungen an die Architektur Authentifizierung mit Hilfe eines Smartphones Architektur Protokoll und Ablauf Sitzungscookies QR-Token am Dienst einbetten Das Smartphone als Endgerät für den Zugriff auf geschützten Inhalt Übertragung aktiver Sitzungen an das Smartphone Authentifizieren einer Sitzung im Browser des Smartphones Mobile Verwaltung des SSO-Prozesses Mobiles Profil

5 INHALTSVERZEICHNIS Mobiler Single Log-Out Sicherheit Aushorchen eines Cookies Malware auf dem Rechner Malware auf dem Smartphone Phishing-Attacken Angriff auf den Token-Transfer Man-in-the-middle Implementierung Eingesetzte Entwicklungsumgebung Smartphone-Applikation Registrierung eines Benutzer Auswertung eines QR-Codes Abrufen des Benutzerprofils Authentifizierung im Browser des Mobilgerätes Generierung von QR-Token Generieren von Token für die eingebettete Darstellung am Dienst Angepasste Darstellung für mobile Browser SSO-Server Zusätzliche Schnittstellen Datenbank Server-Management Integration der Dienste Direktes Einbetten der Token Single Sign-On Handler Einbindung von OpenID Zusammenfassung Die wichtigsten Vor- und Nachteile des vorgeschlagenen Verfahrens Einsatzmöglichkeiten Ausblick und Erweiterungsmöglichkeiten Benutzerzertifikate Security Assertion Markup Language Security Policies und Trustlevel A Java-Code für die Integration eines Dienstes 74 B Java-Code für die Integration eines Dienstes mit eingebetteten Token 75 Abbildungsverzeichnis 77 Abkürzungsverzeichnis 78

6 INHALTSVERZEICHNIS 6 Literaturverzeichnis 80

7 Kapitel 1 Einleitung Heutzutage wird der Zugriff auf Dienste und Inhalte im Internet immer allgegenwärtiger. Damit einher gehen allzu häufige Authentifizierungsprozesse und lästige Anmelde- Verfahren, die nicht nur Zeit in Anspruch nehmen, sondern auch, durch die Vielzahl an nötigen Pseudonymen und Passwörtern, einen gewissen Verwaltungsaufwand für den Benutzer darstellen. Eine Verbesserung der Situation wird durch den Einsatz eines Single Sign-On (SSO) Verfahrens erreicht. Hierbei wird der Zugriff auf verschiedene, verteilte Dienste über ein zentrales System verwaltet. 1.1 Motivation Neben der steigenden Anzahl an Internetdiensten bei denen sich ein Benutzer jeden Tag anmelden muss, steigt auch die Verbreitung von internetfähigen Mobilgeräten. Entsprechend bietet es sich an, Smartphones einzusetzen um die Sicherheit und die Benutzerfreundlichkeit von SSO-Verfahren am Rechner zu erhöhen. Ähnliche Anwendungsszenarien, wie zum Beispiel bargeldlose Bezahlprozesse oder Mobile TAN -Verfahren zeigen erfolgreich wie das Mobiltelefon sinnvoll in einem sicherheitskritischen Umfeld eingesetzt werden kann. Darüber hinaus haben Besitzer eines Smartphones das Problem, dass sie sich neben dem Rechner auch noch an ihrem Telefon für die Verwendung von Internetdiensten authentifizieren müssen. Die Problematik häufiger Login-Prozeduren ist auf dem Smartphone besonders kritisch. Zum einen werden aufgrund der beschränkten Ressourcen der Geräte, verstärkt Funktionalitäten ins Internet ausgelagert. Zum anderen wird die häufige Eingabe von Benutzernamen und Passwörtern durch die spärlichen Eingabemöglichkeiten erschwert. Es besteht also gerade im Bereich der mobilen Geräte ein dringender Bedarf die Anzahl der Authentifizierungsprozesse durch SSO-Verfahren zu reduzieren. Leider gibt es nach heutigem Stand der Technik kaum Applikationen, die internetfähige Telefone im Rahmen eines SSO-Verfahrens berücksichtigen. Dabei ermöglicht eine konsequente Anbindung des Smartphones an die SSO-Architektur nicht nur den Einsatz neuer Authentifizierungsmethoden, sondern erleichtert auch die Authentifizierung direkt am Smartphone. 7

8 Kapitel 1 Einleitung Überblick Im Rahmen der im Folgenden vorgeschlagenen Lösung übernimmt das Smartphone gleich drei verschiedene Aufgaben: Die Unterstützung von Authentifizierungsprozessen an einem Rechner Den mobilen Zugriff auf geschützte Netzinhalte Die Verwaltung von Authentifizierungsdaten und Zugriffsrechten durch den Benutzer Um diese Aufgabenbereiche abdecken zu können, muss das Mobilgerät entsprechend in das SSO-Verfahren eingebunden werden. Die Verbindung zwischen dem Smartphone und dem zu authentifizierenden Rechner wird durch das Einlesen eines QR-Codes realisiert. In den folgenden Kapiteln werden erst die Prinzipien eines SSO-Verfahren und die Möglichkeiten beim Einsatz von QR-Codes erläutert. Anschließend wird ein Konzept für eine Architektur vorgestellt, die es dem Benutzer erlaubt sich mit Hilfe seines Smartphones für den Zugang zu verschiedenen Diensten in einem SSO-Netzwerk zu authentifizieren. Hierbei werden die Anforderungen an eine solche Architektur, insbesondere im Hinblick auf die Sicherheitsaspekte untersucht. Abschließend wird im Detail auf die Implementierung eines Prototyps eingegangen, der die Validität des Konzeptes beweist.

9 Kapitel 2 Stand der Technik Dieses Kapitel beschreibt die Grundlagen von Single Sign-On Verfahren, Quick Response Codes und dem Android-Betriebssystem. Darüber hinaus werden wissenschaftliche Arbeiten und relevante Standards analysiert um einen aktuellen Stand der Technik zu etablieren. 2.1 Single Sign-On Spätestens seit dem Aufkommen von Cloud-Computing ist Single Sign-On (SSO) unverzichtbar geworden. Durch den Paradigmenwechsel von klassischen Desktop-Applikationen zu web-basierten Diensten, ist der Benutzer immer öfter gezwungen sich zu authentifizieren. Hierdurch entstehen mehrere Probleme im Bezug auf Sicherheit und Verwaltungsaufwand: Der Aufwand für den Benutzer führt dazu, dass Passwörter häufig mehrfach verwendet werden Der Benutzer neigt dazu seine zahlreichen Passwörter aufzuschreiben oder in seinem Browser abzuspeichern Durch die Vielzahl an verschiedenen Login-Prozeduren ist der Benutzer anfälliger für Phishing-Attacken durch gefälschte Abfragen Der Aufwand für die Verwaltung von Benutzerdaten wie Login-Name und Passwort bei jedem einzelnen Dienst ist entsprechend hoch Jeder Dienstanbieter muss sich selbst mit den Sicherheitsaspekten einer Authentifizierung befassen und garantieren, dass die privaten Ressourcen des Benutzers gesichert sind Der Einsatz eines SSO-Verfahrens bietet eine Lösung für diese Probleme durch die Integration eines zentralen Authentifizierungs-Mechanismus. Indem eine Mehrzahl von Diensten (Service Provider, Relying Party) auf eine gemeinsame Lösung für die Authentifizierung zugreifen, lässt sich die Anzahl der zu verwaltenden Name/Passwort-Kombinationen drastisch reduzieren, wodurch sowohl der Benutzer als auch der Dienstanbieter profitiert. Durch 9

10 Kapitel 2 Stand der Technik 10 das Wegfallen des redundanten Aufwandes auf beiden Seiten, entfallen die oben angesprochenen Probleme und damit wird auch die Sicherheit aller beteiligten Dienste erhöht. Typischerweise werden im Rahmen einer solchen Lösung, wie in Abb. 2.1 gezeigt, Benutzeranfragen an einen SSO-Server (Identity Provider) umgeleitet. Dieser Server überprüft ob der Benutzer bereits authentifiziert wurde und verifiziert bei Bedarf dessen Identität. Außerdem wird überprüft ob der Benutzer berechtigt ist auf die angeforderte Ressource zuzugreifen. Im Falle einer gelungenen Authentifizierung wird ein sogenanntes Ticket erstellt und an den Benutzer übermittelt. Ein Ticket, auch manchmal Token genannt, ist ein Datenpaket, das in einem bestimmten Rahmen eine Identifizierung des Benutzers erlaubt. Der Benutzer kann anschließend sein Ticket vorzeigen um sich gegenüber dem Dienst eindeutig zu identifizieren und Zugriff auf den gewünschten Inhalt zu erlangen. Grundsätzlich existieren eine ganze Reihe verschiedener Architekturen und Implementierungen, die unter den Begriff der SSO-Verfahren fallen. Wie in [1] beschrieben, variieren hierbei die eingesetzten Kommunikationsprotokolle, die Authentifizierungsmethoden sowie die Art der Tickets. Im folgenden Unterabschnitt wird vereinfacht der Aufbau und der Ablauf einer SSO-Authentifizierung gezeigt ohne dabei auf die Besonderheiten einer speziellen Lösung oder Implementierung einzugehen. Anschließend wird im Detail auf die Funktionsweise und die Eigenheiten von OpenID [2] eingegangen Aufbau und Ablauf Die Abb. 2.1 zeigt wie ein Client sich mit Hilfe eines Identity Providers bei einem abhängigen Dienst authentifiziert. Im Folgenden wird beschrieben welche Rolle die involvierten Komponenten spielen. Benutzer (Client) Der Benutzer initiiert den Prozess durch eine Anfrage auf geschützten Inhalt eines Dienstes. Typischerweise erfolgt diese Anfrage in Form eines HTTP- Zugriffs auf eine URL im Browser des Benutzers, möglich ist aber auch das Abfragen eines Dienstes über ein anderes Protokoll, wie etwa SOAP [4]. Im Laufe des SSO- Prozesses gilt es die Identität des Benutzers zu verifizieren und zu entscheiden ob dessen Anfrage genehmigt oder abgelehnt werden soll. Dienst (Relying Party) Der Dienst entspricht dem Anbieter eines beliebigen Inhalts, der durch die Überprüfung der Identität des zugreifenden Benutzers geschützt werden soll. Hierbei verlagert der Dienst die Kontrolle der Daten des Benutzers nach außen und muss sich, wie das viel gebrauchte Synonym Relying-Party schon sagt, auf das Resultat der Identitätsprüfung durch eine dritte Partei verlassen. In einer typischen SSO-Architektur nutzen sinngemäß eine Mehrzahl verschiedener Dienste einen gemeinsamen Authentifizierungs-Mechanismus. In der Praxis bieten die Dienste allerdings in der Regel neben einer ausgelagerten Authentifizierung auch die Option an, sich über einen eigenen, selbst verwalteten Dialog auszuweisen.

11 Kapitel 2 Stand der Technik 11 Abbildung 2.1: Schema eines Authentifizierungsvorgangs mit Hilfe eines typischen SSO- Verfahrens aus [3] SSO-Server(Identity Provider) Der Identity-Provider kümmert sich stellvertretend für die eingehängten Dienste um die Kontrolle der Identität des Benutzers. Hierzu gehören sowohl die Abfrage der entsprechenden Benutzerinformationen als auch deren Überprüfung durch den Abgleich mit einer Datenbank, sowie die Generierung eines Tickets, das den Benutzer dienst-übergreifend identifiziert. Bevor ein Benutzer mit Hilfe eines SSO-Verfahrens identifiziert werden kann, muss er sich einmalig beim SSO-Server bekanntmachen. Hierbei wird üblicherweise ein Profil mit persönlichen Daten angelegt und der Benutzer erhält Authentifizierungsmerkmale mit denen er sich später ausweisen kann. Die folgende Aufzählung beschreibt die typischen Schritte im Ablauf einer SSO-Authentifizierung analog zur Abb Der Benutzer greift von seinem Client-System aus auf einen geschützten Dienst zu. 2. Der Dienst antwortet auf die Anfrage indem er den Benutzer an den SSO-Server verweist. 3. Der Benutzer authentifiziert sich gegenüber dem SSO-Server. Gewöhnlich geschieht dies durch die Eingabe einer Kombination von Benutzername und Passwort. 4. Der SSO-Server stellt ein Ticket für den validierten Benutzer aus und leitet ihn zurück zum abhängigen Dienst.

12 Kapitel 2 Stand der Technik Der Dienst baut eine Kommunikation zum SSO-Server auf um die Gültigkeit, des vom Benutzer erhaltenen Tickets, zu überprüfen. 6. Wenn das Ticket erfolgreich überprüft werden kann, übermittelt der SSO-Server die passenden Benutzerinformationen an den Dienst. Nach erfolgreichem Abschluss dieses Vorgangs, gilt der Benutzer als authentifiziert und kann auf den gewünschten Inhalt zugreifen OpenID OpenID [2] ist das wohl populärste Single Sign-On Verfahren und wird unter anderem von Unternehmen wie Google, PayPal und Facebook unterstützt. Bei OpenID handelt es sich um einen offenen Standard der eine dezentralisierte Struktur vorsieht. Dies bedeutet, dass die Verwaltung der Identitäten nicht durch eine zentrale Autorität kontrolliert wird, sondern prinzipiell durch eine beliebige Anzahl von Anbietern, zwischen denen der Benutzer sich frei entscheiden kann. Wegen dieser Eigenschaft gilt OpenID auch als benutzerzentriert: der Benutzer hat die volle Kontrolle gegenüber von wem er sich durch welche Instanz mit welchen Attributen identifiziert. In einer OpenID-Architektur sind prinzipiell die selben Komponenten involviert wie im letzten Abschnitt beschrieben. Die Identität des Benutzers wird durch eine eindeutige URL dargestellt, die von einem entsprechenden Identity-Provider verwaltet wird. Dafür muss der Benutzer sich einmalig beim Identity Provider registrieren und ein Profil mit allen Daten anlegen, die abhängigen Diensten verfügbar gemacht werden sollen. Danach muss der Benutzer bei Zugriffen auf die abhängigen Dienste nur noch seine zentrale Identität angeben und wird dann an seinen ID-Provider weitergeleitet. Im Allgemeinen muss der Benutzer an dieser Stelle der Übermittlung seiner Daten zustimmen und sich auf irgendeine Weise identifizieren. OpenID schreibt allerdings keine Authentifizierungsmethode vor sondern behandelt lediglich die Identifizierung des Benutzers gegenüber dem abhängigen Dienst. Die konsequente Weiterentwicklung und Ergänzung des Verfahrens hat dazu geführt, dass OpenID in seiner aktuellen Version 2.0 zahlreiche Standards vereinigt und durch eine Vielzahl verschiedener Erweiterungen angepasst werden kann. Die wichtigsten darunter sind Attribute Exchange [5] für das gezielte Abfragen von Identitäts-Merkmalen und Yadis [6] für den Discovery-Vorgang. Yadis beschreibt ein Protokoll für die Feststellung des Endpunktes eines Identity Providers und der von ihm unterstützten Erweiterungen. Dieser als Discovery bezeichneter Vorgang, wird eingeleitet sobald der Benutzer seine OpenID-Identität an den abhängigen Dienst übermittelt hat. Die Beschreibung eines Identity-Providers

13 Kapitel 2 Stand der Technik 13 erfolgt durch Extensible Resource Description Sequence (XRDS). XRDS ist ein XML- Format mit dem sich Inhalte im Internet beschreiben lassen. Insbesondere können die nötigen Metadaten für die Benutzung eines Webservices dargestellt werden. Ein XRDS-Dokument für die Beschreibung eines OpenID-Providers beinhaltet typischerweise eine URL und eine Auflistung der Erweiterungen auf die eine Relying Party zugreifen kann. Attribute Exchange ist ein Verfahren mit dem ein abhängiger Dienst individuell bestimmen kann welche Attribute des Benutzers bei der Authentifizierung übertragen werden. Hierbei ist auch die beliebige Definition neuer Merkmale am Identity-Provider möglich Der Einsatz von Cookies im Rahmen einer SSO-Architektur Die durch RFC2965 [7] beschriebenen Cookies, werden im Rahmen einer HTTP-Antwort von einem Webserver an den Browser des Benutzers übermittelt und dort abgespeichert. Bei allen folgenden Anfragen an den Server, werden die im Cookie enthaltenen Informationen mitgesendet. Da es sich bei HTTP um ein zustandsloses Protokoll handelt, stellen Cookies für Webseiten eine hervorragende Möglichkeit dar, die Identitäten und Sitzungen von Benutzern zu verfolgen. Die wichtigsten Information die ein Cookie enthält sind: Name Dieser Parameter dient dazu den Cookie zu identifizieren, von anderen zu unterscheiden und gezielt auszulesen. Value Enthält die Informationen die bei Anfragen an den Server übermittelt werden sollen. Typischerweise handelt es sich bei dem Wert eines Cookies, um eine Identifizierungsnummer für den entsprechenden Benutzer oder die Sitzung beim Server. Prinzipiell können aber beliebige Daten in Form einer Zeichenkette übermittelt werden. Domain Der Parameter für die Domäne an die der Browser die Informationen des Cookies in Anfragen übermitteln soll. Im Normalfall darf diese Domäne nur jener des Servers entsprechen von dem der Cookie stammt. Path Durch den Pfad kann innerhalb einer Domäne beschränkt werden bei welchen Anfragen die Informationen übermittelt werden. Im Allgemeinen wird der Cookie nur beim Zugriff auf Unterpfade des Path -Parameters mitgesendet. Max-Age Gibt die maximale Zeitspanne an, für die der Cookie seine Gültigkeit behält und vom Benutzer in Anfragen eingebettet werden soll. Nach Ablauf dieser Zeit ist der Browser verpflichtet den Cookie zu verwerfen. Secure Dieser Wert gibt an ob der entsprechende Cookie nur über eine sichere Verbindung versandt werden darf. Durch das Einschränken des Cookies für die Benutzung

14 Kapitel 2 Stand der Technik 14 einer SSL-gesicherten Verbindung, wird die Authentizität und die Vertraulichkeit des Inhaltes geschützt. Neben den Attributen für die Spezifikation eines Cookies werden in [7] auch die Anforderungen an die Benutzerseite definiert. Demnach sollte es möglich sein mindestens 20 Cookies pro Domäne speichern zu können, deren Größe auf minimal 4 Kilobyte beschränkt ist. Das von Oracle veröffentlichte Paper Single Sign-On Using Cookies for Web Applications [8] schlägt eine SSO-Struktur basierend auf Cookies vor. In der vorgeschlagenen Lösung werden Cookies von einem zentralen Server ausgestellt um die SSO-Sitzungs-ID zu übermitteln. Eingebundene Webserver können mit Hilfe dieser ID die entsprechenden Sitzungs- und Benutzerdaten vom Server erfragen. Der Einsatz von Cookies in dieser Architektur bringt laut dem Autor vor allem den Vorteil mit sich, dass auf der Benutzerseite keinerlei zusätzliche Software installiert werden muss. Durch die automatische Verwaltung der Cookies im Browser, ist der Ablauf des Verfahrens für den Benutzer völlig unsichtbar und die Benutzererfahrung wird nicht negativ beeinträchtigt. Die rein serverseitige Verwaltung von Cookies hat darüber hinaus den Vorteil, dass bei nachträglichen Änderungen am Inhalt der Cookies keine Rücksicht auf die Benutzerseite genommen werden muss. Diese Eigenschaften machen Cookies sehr interessant für den Einsatz in einer sicherheitsrelevanten Anwendung, wie dem Single Sign-On. 2.2 Quick Response Codes Der Quick Response Code (QR-Code), wie er durch den Industrie-Standard ISO/IEC 18004:2006 [9] beschrieben wird, ist eine grafische, maschinen-lesbare Darstellungsform für digitale Informationen. Anders als der klassische Barcode, mit dem immer noch quasi jedes Produkt gekennzeichnet wird, nutzt der QR Code eine zweite Dimension und erzielt damit eine wesentlich höhere Datendichte. Die zugrunde liegende Technologie wurde bereits 1994 von der japanischen Firma Denso Wave [10] entwickelt und öffentlich zur Verfügung gestellt. QR-Codes zeichnen sich vor allem durch vier Eigenschaften aus, die sie von anderen zweidimensionalen Codes abheben: Große Datenmenge Eine quadratische Datenmatrix mit einer Kantenlänge von 177 Elementen, kann rund 3 Kilobyte an Daten enthalten und ist dabei (abhängig von der Auflösung) nicht größer als ein Strichcode, der nur einige Byte zur Verfügung stellt. Schnelles Scannen Wie in Abb. 2.2 gezeigt, enthalten die QR-Codes Markierungen, die einem Lesegerät die Feststellung der Position, Ausrichtung und Ausdehnung des Bildes erleichtern und die Performance beim Scannen erhöhen. Fehlertoleranz Durch den Einsatz von Reed-Solomon-Codierung können Daten, die durch

15 Kapitel 2 Stand der Technik 15 Verschmutzungen und Beschädigungen des Bildes beeinträchtigt wurden, bis zu einem gewissen Grad wiederhergestellt werden. Offener Standard Während andere, vergleichbar performante, zweidimensionale Barcodes wie z.b. Aztec oder Somacodes proprietär sind, ist die Funktionsweise des QR-Codes öffentlich zugänglich und frei verfügbar. Abbildung 2.2: QR-Code mit hervorgehobenen Markierungen Klassisch wurden QR-Codes in der Industrie für die Verfolgung von Bauteilen bei der Produktion benutzt, doch sie erfreuen sich seit kurzem auch in anderen Bereichen einer immer größer werdenden Beliebtheit. Grund hierfür ist vor allem die steigende Verbreitung von Smartphones. Mit der richtigen Applikation, ist jeder Benutzer eines Smartphones mit eingebauter Kamera, Besitzer eines Barcode-Scanners. Durch die, sich daraus ergebende, entsprechend hohe Anzahl an Lesegeräten in der Bevölkerung, werden QR-Codes in vielfältigen Anwendungen gebraucht, die ein breites Publikum ansprechen. Vor allem im Internet und zunehmend auch in gedruckten Medien, werden QR-Codes eingesetzt, um dem Benutzer zusätzliche Inhalte zur Verfügung zu stellen. Einige Beispiele für populäre Anwendungsszenarien sind: QR-Codes mit der URL zu einer Internetseite, die zusätzliche Informationen zu einem Zeitungsartikel bietet QR-Codes mit der nötigen Referenz für den Download einer Smartphone-Applikation Die Übermittlung einer digitalen Visitenkarte in Form eines QR-Codes Neben diesen Anwendungen gibt es in der wissenschaftlichen Literatur einzelne Ansätze für den Einsatz von QR-Codes in sicherheitsrelevanten Szenarien, die in den folgenden Abschnitten näher untersucht werden.

16 Kapitel 2 Stand der Technik QR-Codes als Träger für Einmalkennwörter Viele herkömmliche Protokolle für den Einsatz von Einmalkennwörtern basieren auf einem vertrauenswürdigen Hardware-Token, der die Manipulation sicherheitsrelevanter Daten erschweren soll. Hierbei kommen gewöhnlich Smartcard-Leser oder zeit-synchrone Token für die Passwortgenerierung zum Einsatz. Nicht unüblich ist auch das Einbeziehen eines Telefons über SMS-Nachrichten. Nach Meinung von Liao et al. [11] besteht das Problem dieser Lösungen in der mangelhaften Verbreitung der zu Grunde liegenden Geräte bzw. in der mangelnden Verlässlichkeit der SMS-Übertragung. Deshalb schlagen die Autoren den Einsatz von QR-Codes in Kombination mit Smartphones als Token für die Einmalkennwörter vor. Durch die weite Verbreitung, bieten Smartphones eine gute Alternative zu Smartcard-Lesern und anderen spezialisierten Hardware-Token. Der vorgeschlagene Ablauf umfasst folgende Schritte für die Registrierung und die Authentifizierung eines Benutzers: 1. Der Benutzer übermittelt seine ID an den Service Provider (SP), der einen Hash über die ID und ein servereigenes Geheimnis bildet. 2. Der SP sendet diesen Hash über einen sicheren Kanal an das Mobilgerät des Benutzers, wo er für die spätere Authentifizierung gespeichert wird. Damit gilt der Benutzer als registriert. 3. Für die Authentifizierung selbst, übermittelt der Benutzer wieder seine ID an den SP. Es wird der gleiche Hash wie im Laufe der Registrierung gebildet und binär mit einer Zufallszahl addiert. Diese Daten werden dann zusammen mit einem Zeitstempel als QR-Code kodiert und sichtbar für das Mobiltelefon des Benutzers dargestellt. 4. Der Benutzer scannt den QR-Code mit seinem Smartphone und kann die Zufallszahl des Servers berechnen indem er die enthaltenen Daten mit dem am Gerät gespeicherten Hash binär addiert. Anschließend wird die Zufallszahl zusammen mit einem Zeitstempel an den Server übermittelt, wodurch der Benutzer als validiert gilt QR-Codes für die Authentifizierung beim Online-Banking Lee et al. [12] schlagen ein ähnliches Verfahren wie in Abschnitt gezeigt, vor um Benutzer beim Online Banking zu authentifizieren. Durch die Einbindung eines vertrauenswürdigen Mobilgerätes soll das Verfahren resistenter gegenüber Angriffen gemacht werden. Der Einsatz eines Smartphones und QR-Codes anstatt eines spezialisierten Gerätes soll die Benutzbarkeit und damit auch die Sicherheit des Verfahrens erhöhen. In dem beschriebenen Szenario beruht die Sicherheit der Authentifizierung nicht alleine auf dem eingesetzten Einmalkennwort, sondern auch auf einem Benutzerzertifikat. Die Bindung des Mobilgerätes wird über die Seriennummer des Smartphones hergestellt, die dem Server bereits vor der Authentifizierung bekannt sein muss. Durch den QR-

17 Kapitel 2 Stand der Technik 17 Code wird ein Hash-Wert der Transaktionsdaten und eine Zufallszahl an den Benutzer übermittelt. Mit Hilfe des Smartphones wird der QR-Code ausgelesen, die Zufallszahl überprüft und ein Einmalkennwort basierend auf den Transaktionsdaten und der erwähnten Seriennummer des Mobilgerätes generiert. Dieses Kennwort wird dann an den Server übermittelt und durch eine Certification Authority (CA) validiert. Starnberger et al. [13] von der TU Wien schlagen ein Konzept vor, mit dem ein Smartphone über QR-Codes einen potentiell unsicheren Computer bei der Durchführung von Banking- Transaktionen zu unterstützt. Das Mobilgerät des Benutzers und der Server, hier Remote Trusted Computer (RTC) genannt, sind bereits vorab im Besitz eines gemeinsamen Geheimnisses. Der QR-Code wird für die Übermittlung der Transaktionsdaten und einer Zufallszahl an das Smartphone eingesetzt. Die Mobile Anwendung liest die Daten aus und zeigt ihren Inhalt an, so dass sie durch den Benutzer überprüft werden können. Außerdem wird aus den Daten aus dem QR-Code durch den Einsatz eines kryptographischen Hash- Verfahrens ein kurzer Code gebildet, der dem Benutzer als Transaktionsnummer (TAN) für seine Überweisung dient. Ein ähnliches Verfahren wird von Google angeboten um mit der Hilfe eines Smartphones die Sicherheit des Logins bei Google-Konten zu erhöhen. Hierbei kommt die mobile Anwendung Google Authenticator [14] zum Einsatz. Genau wie bei dem oben beschriebenen TAN-Verfahren, führt das Einscannen eines QR-Codes zur Generierung einer Zeichenkette, die als zusätzliches Passwort in einer 2-Schritt-Verifikation benutzt werden kann. 2.3 Android Smartphones Android [15] ist ein freies und quelloffenes Betriebssystem für Smartphones und Tablet- PCs. Seit Google 2005 durch die Übernahme von Android in den Markt der mobilen Betriebssysteme eingestiegen ist, erfreuen sich Smartphones mit dem Linux-basierten Betriebssystem großer Beliebtheit. Neben den von Google selbst vertriebenen Nexus- Telefonen, bieten auch die meisten Branchengrößen, wie z.b. Samsung, HTC und LG, eigene Geräte im Android-Segment an. Laut aktuellen Statistiken der Firma Canalys [16] hat Android mit einem Marktanteil von fast 50 Prozent der weltweiten Smartphones, das Apple Betriebssystem ios als Marktführer abgelöst. Wie in Abb. 2.3 gezeigt, basiert Android auf einem Linux-Kernel, der die Interaktion mit der Hardware über entsprechende Gerätetreiber verwaltet. Auf diesem Kernel setzt eine Laufzeit-Umgebung (Runtime Environment) auf, die im Kern aus der Dalvik Virtual Machine (DVM) besteht. Die DVM ist eine, eigens von Google entwickelte, für die Bedürfnisse einer mobilen Umgebung angepasste, Java Virtual Machine (JVM). Diese Verwandschaft führt dazu, dass alle Anwendungen für Android in der objektorientierten Programmiersprache Java [17] geschrieben werden und anschließend für die DVM übersetzt werden können. Neben der vertrauten Sprache und Entwicklungsumgebung, macht vor allem die große Auswahl an Standard-Bibliotheken (vgl. Abb 2.3) die Android-Plattform attraktiv

18 Kapitel 2 Stand der Technik 18 Abbildung 2.3: Aufbau des Android-Betriebssystems analog zu [15] für Entwickler von mobilen Applikationen Aufbau einer Applikation An dieser Stelle werden kurz die grundlegenden Komponenten einer Android-Applikation vorgestellt, wie sie in der Android Entwickler-Referenz [15] beschrieben werden. Diese Einleitung soll die Beschreibung der, in Abschnitt 4.2 vorgestellten, Implementierung einer mobilen Anwendung vereinfachen. Hierbei ist vor allem die Einführung der folgenden Begriffe wichtig: Activities Eine Android-Anwendung besteht typischerweise aus einer logischen Verbindung mehrerer Activity-Klassen, von denen eine beim Start der Applikation gestartet wird (Main-Activity). Eine Activity bietet dem Benutzer eine Oberfläche für die Interaktion mit der Anwendung. Dieses Interface wird dann mit interaktiven Elementen wie etwa Buttons oder Eingabefeldern befüllt. Hierfür kann einer Activity ein Layout, in Form einer XML-

19 Kapitel 2 Stand der Technik 19 Datei zugeteilt werden, in der die gewünschten Inhalte definiert sind. Um eine Verbindung zwischen den einzelnen Klassen herzustellen, kann jede Activity weitere Activities durch sogenannte Intents einleiten. Intents Mit Hilfe eines Intents kann gezielt eine gewünschte Activity, ein Hintergrundprozess oder eine andere Anwendung gestartet werden. Somit dienen Intents zur Verbindung der einzelnen Komponenten einer Android-Umgebung. Prinzipiell werden auch alle Zugriffe auf die Android-Plattform durch Intents eingeleitet. Um zu definieren welche Aktion von welcher Klasse beim Aufruf eines Intents abgerufen wird, muss jede Applikation einen oder mehrere Intent-Filter im Android-Manifest definieren. Das Android-Manifest Jede Anwendung muss zwingend über ein eigenes Manifest in Form einer XML-Datei verfügen. Sie befindet sich im Wurzelverzeichnis des Projektes und kann den Bedürfnissen des Entwicklers angepasst werden. Im Manifest werden wichtige Parameter definiert, die das Betriebssystem über die entsprechende Anwendung informieren. So können hier etwa Berechtigungen gesetzt werden, die einer Anwendung erlauben auf Systemressourcen zuzugreifen. Im nächsten Abschnitt wird genauer darauf eingegangen welche Rolle Berechtigungen im Rahmen einer Android-Anwendung einnehmen. Außerdem werden im Manifest alle Activities eingetragen, die im Rahmen einer Applikation aufgerufen werden. Für jede aufgeführte Activity können verschiedene Eigenschaften definiert werden, wie etwa ein Intent-Filter. Dieser Filter definiert genau für welche Arten von Aufrufen eine Activity verfügbar ist und wie sie darauf reagiert Sicherheit Das Sicherheitsmodell von Android beruht auf dem Sandbox-Prinzip. Jede installierte Applikation verfügt über ihren eigenen Bereich (Sandbox) im System, auf den sich ihre Lese- und Schreibrechte limitieren. Im Gegenzug sind die eigenen Daten durch die Sandbox vor dem Einfluss von außen geschützt. Ausnahmen werden explizit durch Berechtigungen definiert, die vom Benutzer bei der Installation einer Anwendung einsehbar sind. Für den Zugriff auf jegliche Systemfunktionen, wie etwa das Aufbauen einer Internetverbindung oder das Benutzen der eingebauten Kamera eines Gerätes, sind entsprechende Berechtigungen nötig. Alle von einer Anwendung benötigten Berechtigungen müssen vom Entwickler im Manifest der Applikation definiert werden. Die Android-Plattform appliziert, was die einer Anwendung zugestandenen Rechte betrifft, ein Alles-oder-nichts- Prinzip. Der Benutzer hat zwar jederzeit die Möglichkeit die nötigen Berechtigungen, wie sie vom Entwickler bestimmt wurden, einzusehen, kann sie jedoch nicht selektiv ablehnen oder blockieren. Konsequent hat der Benutzer im Fall einer unerwünschten Berechtigung nur die Möglichkeit auf die Installation der berechtigten Applikation zu verzichten.

20 Kapitel 2 Stand der Technik Zebra Crossing Für Android gibt es eine ganze Reihe von Anwendungen, die es erlauben Barcodes mit Hilfe der Kamera des Smartphones einzuscannen und deren Inhalt anzuzeigen oder weiterzuverarbeiten. Besonders populär ist der, auf der Zebra Crossing (ZXing) Bibliothek [18] basierende, BarcodeScanner. Die zugrunde liegende Bibliothek wird aktiv weiterentwickelt und bietet eine Reihe Vorteile für Entwickler: Offener Quellcode Die ZXing Bibliothek ist komplett quelloffen und frei verfügbar. Unterstützte Formate ZXing unterstützt alle relevanten Formate von ein- und zweidimensionalen Barcodes, darunter die unter Abschnitt 2.2 beschriebenen QR-Codes. Generator Neben dem Auslesen von Barcodes, bietet die Bibliothek auch die nötigen Klassen um Barcodes aller unterstützten Formate zu erstellen und als Bilddateien zur Verfügung zu stellen. Unterstützte Plattformen Die ZXing Bibliothek ist nicht nur in der für Android relevanten Sprache Java verfügbar sondern auch in Ausführungen für andere mobile Betriebssysteme wie ios und Windows Phone 7. Damit eignet sich die ZXing-Bibliothek und die enstprechende Android-Anwendung bestens für die Entwicklung neuer Verfahren die auf QR-Codes basieren.

21 Kapitel 3 Konzept Im Folgenden soll ein Konzept für einen Aufbau vorgestellt werden, der es erlaubt ein Smartphone in ein SSO-Verfahren einzubinden. Ziel dieses Konzeptes ist es, sowohl die Sicherheit als auch die Benutzerfreundlichkeit eines solchen Prozesses zu verbessern. Ausgehend von der Funktionsweise einer herkömmlichen SSO-Architektur, wie sie in Abschnitt 2.1 beschrieben wird, werden der Aufbau und der Ablauf entsprechend angepasst, um den Einsatz eines Mobilgerätes für die Authentifizierung zu unterstützen. 3.1 Grundlagen Im Rahmen des Entwurfes musste eine Lösung für die Realisierung einer Verbindung zwischen dem Smartphone und der entsprechenden Authentifizierungs-Architektur gefunden werden. Eine gute Möglichkeit für die schnelle Übertragung kleiner Datenmengen von einem Rechner auf ein Smartphone bietet das Generieren und anschließende Auslesen eines QR-Codes. Wie in Abschnitt 2.2 beschrieben, werden QR-Codes zunehmenst in verschiedensten Anwendungsszenarien eingesetzt. Unter anderem wurde ihr Einsatz auch bereits in ähnlichen, sicherheitskritischen Applikationen vorgeschlagen. Wie in [11] und [12] gezeigt, existieren bereits verschiedene Ansätze für die Übermittlung von Authentifizierungsdaten per QR-Code. Analog hierzu, setzt das folgend beschriebene Konzept auf die Kapazität des Smartphones, QR-Codes auszulesen, um eine Authentifizierung des Benutzers durchzuführen. Für die Interaktion des Smartphones mit der SSO-Architektur muss eine spezialisierte mobile Anwendung eingesetzt werden, deren genaue Funktionsweise in Abschnitt 4.2 erläutert wird. Die Funktionalität der vorgeschlagenen Lösung soll nicht nur die Identifizierung eines Benutzer erlauben, wie das etwa bei OpenID [2] der Fall ist, sondern auch prüfen ob der authentifizierte Benutzer für den Zugriff auf die angeforderte Ressource autorisiert ist. Entsprechend müssen alle Dienste die das Verfahren einsetzen auch beim SSO-Server bekannt sein. Außerdem werden dem Benutzer Zugriffsrechte erteilt, die sich auf die URLs der abhängigen Dienste beziehen. Basierend auf diesen Zugriffsrechten und der URL des 21

22 Kapitel 3 Konzept 22 anfragenden Dienstes, wird dann individuell eine Entscheidung für die Autorisierung getroffen. Bevor eine Authentifizierung mit Hilfe eines Smartphones durchgeführt werden kann, muss der Benutzer sich über die mobile Anwendung mit dem SSO-Server bekannt machen. Im Laufe dieser Registrierung übermittelt der Benutzer einmalig seine Benutzerkennung und sein Passwort an den Server und erhält die nötigen Daten um im Rahmen des SSO- Verfahrens identifiziert werden zu können. Hat der Benutzer sich einmal registriert, ist er in der Lage sich mit Hilfe seines Smartphones zu authentifizieren. Die Authentifizierung eines Benutzers und somit dessen Zugriff auf die angeforderten Ressourcen ist auf den Kontext einer Sitzung beschränkt. Ein solcher Kontext wird durch eine Zeichenfolge definiert, die eine eindeutige Identifizierung der Sitzung erlaubt: die Session- ID (SID). Wie in Bild 3.1 gezeigt, beginnt der Lebenszyklus einer Sitzung mit der Anfrage des Benutzers an einen Dienst, bzw. mit der Erstellung eines QR-Tokens. Durch die erfolgreiche Authentifizierung eines Benutzers über das Einscannen eines QR-Codes, wird die Sitzung validiert und an den entsprechenden Benutzer gebunden. Abbildung 3.1: Lebenszyklus einer SSO-Sitzung Die Sitzungsdaten die im Rahmen der Generierung eines QR-Tokens codiert werden, enthalten folgende Informationen: Die URL der angeforderten Ressource bzw. des Dienstes auf den der Benutzer zugreift. Die SID die eine eindeutige Identifizierung der Sitzung erlaubt. Ein Zeitstempel der den Zeitpunkt der Erstellung des QR-Tokens markiert. Zusätzlich zu den, im QR-Token enthaltenen Daten, werden bei der Authentifizierung einer Sitzung auch Informationen übermittelt die den entsprechenden Benutzer identifizieren. Aus der Kombination dieser Informationen kann der SSO-Server in der Folge die für eine

23 Kapitel 3 Konzept 23 Authentifizierung nötige Verbindung zwischen einer Sitzung und einem registrierten Benutzer herstellen. Nach Ablauf einer festgelegten Lebensdauer, wird die Sitzung invalidiert und die Zugriffsrechte des zugehörigen Benutzers verfallen für den definierten Kontext. Das Ablaufen einer Sitzung ist eine wichtige Sicherheitsmaßnahme um die unerlaubte Verwendung durch Außenstehende zu vermeiden. Falls der Benutzer seine Sitzung nicht explizit beendet, könnte ein nicht berechtigter Anwender des gleichen Browsers später auf dessen Daten zugreifen. Darüber hinaus, hat jede erfolgreiche Überprüfung einer Sitzung beim SSO-Server zur Folge, dass die Gültigkeit der Sitzung zeitlich verlängert wird. Durch diesen Mechanismus wird verhindert, dass eine aktive Sitzung abläuft während der Benutzer noch Aktionen in ihrem Kontext durchführt. Für die Übertragung von Sitzungsdaten zwischen dem Identity-Provider und dem Benutzer bzw. zwischen dem Benutzer und dem Service-Provider werden Cookies eingesetzt. Die allgemeine Struktur und Funktionsweise von Cookies wurde bereits in Abschnitt beschrieben. In der vorgeschlagenen Lösung werden sowohl vom SSO-Server, wie auch von den eingehängten Diensten, Cookies an den Benutzer verteilt um dessen Sitzungen verfolgen zu können. Eine genauere Beschreibung der Abläufe im Rahmen des Erstellen und Auslesens von Cookies wird in Abschnitt gegeben. Zusammenfassend, basiert das entworfene Konzept also auf folgenden Lösungsansätzen: Die Authentifizierung/Autorisierung eines Benutzers wird durch den Einsatz eines Smartphones realisiert. Die Verbindung zwischen dem Smartphone und dem Rechner des Benutzers wird durch das Einscannen eines QR-Tokens hergestellt. Der Benutzer wird immer nur für den zeitlich begrenzten Kontext einer Sitzung authentifiziert. Die ID einer Sitzung wird mit Hilfe eines Cookies vom SSO-Server zum Benutzer und zum angeforderten Dienst übertragen. Bevor eine Authentifizierung durchgeführt werden kann, muss der Benutzer sich mit Hilfe seines Smartphones beim SSO-Server registrieren. In den folgenden Abschnitten wird zuerst beschrieben, was nötig ist um die genannten Prozesse umzusetzen. Anschließend wird ein entsprechender Aufbau vorgestellt und die einzelnen Komponenten und deren Zusammenspiel detailliert erörtert. Außerdem wird ausführlich auf den Ablauf der Kommunikation eingegangen, die im Rahmen einer Authentifizierung stattfindet.

24 Kapitel 3 Konzept Anforderungen An dieser Stelle soll analysiert werden welche Anforderungen eine SSO-Architektur erfüllen muss, um die Authentifizierung und die Autorisierung eines Benutzer durch den Einsatz eines Smartphones zu realisieren. Hierbei wird sowohl auf grundlegende Eigenschaften eingegangen, die für eine verteilte Single Sign-On Lösung wichtig sind, wie auch auf Besonderheiten, die speziell die Integration eines Mobilgerätes betreffen Anforderungen an das Mobilgerät Da die Übertragung von Sitzungsdaten vom Bildschirm des Client-Rechners zum Smartphone über QR-Codes geschehen soll, muss das entsprechende Mobilgerät über eine eingebaute Kamera und eine Software für die Dekodierung verfügen. Außerdem muss das Smartphone zwingend internetfähig sein und zum Zeitpunkt einer Registrierung oder Authentifizierung Zugriff auf eine offene Internetverbindung haben Anforderungen an das Kommunikationsprotokoll Da es sich bei den im Rahmen einer Authentifizierung/Autorisierung übertragenen Informationen, zum größten Teil um sicherheitssensible Daten handelt, müssen sämtliche Verbindungen entsprechend abgesichert sein. Die durchgeführten Übertragungen müssen folgenden Ansprüchen genügen: Vertraulichkeit Es muss sichergestellt werden, dass außer den Kommunikationspartnern niemand die übermittelten Daten einsehen kann. Integrität Der Empfänger muss Sicherheit haben, dass die empfangenen Daten bei der Übermittlung nicht manipuliert wurden. Authentizität Ein Kommunikationspartner muss die Herkunft einer Datenübertragung mit Sicherheit bestimmen können Anforderungen an die Architektur Es ist wichtig für die Struktur, dass verschiedene Verteilungs-Szenarien für die eingehängten Dienste unterstützt werden können. Hierbei spielt vor allem die Verteilung der Dienste auf eine oder mehrere Internet-Domänen eine Rolle. Die Einbindung der Dienste in folgenden Konstellationen sollte möglich sein: Mehrere Domänen die jeweils einen Dienst beherbergen. Mehrere Dienste (Service Provider) die sich eine einzelne Internet-Domäne teilen.

25 Kapitel 3 Konzept 25 Eine beliebige Verteilung mehrerer Dienste über verschiedene Internet-Domänen. Neben einer flexiblen Lösung für die Verteilung der Dienste, ist ein Ziel der Architektur möglichst leichtgewichtig und modular zu sein. Hierdurch soll sichergestellt werden, dass die Lösung möglichst einfach zu erweitern und zu modifizieren ist. Durch einen stark modularen Aufbau wird außerdem das Integrieren von bestehenden und neuen Standards erleichtert. Eine weitere Anforderung an alle Komponenten ist eine gute Skalierbarkeit. Da je nach Einsatzgebiet eine sehr hohe Anzahl an Diensten und Benutzern verwaltet wird, muss darauf geachtet werden, dass die Lösung entsprechend angepasst werden kann. 3.3 Authentifizierung mit Hilfe eines Smartphones Im Folgenden werden eine Architektur und ein Ablauf vorgeschlagen mit denen eine SSO- Authentifizierung, basierend auf den Grundlagen aus Abschnitt 3.1, durchgeführt werden kann Architektur Analog zu einer klassischen SSO-Struktur, wie sie unter Abschnitt beschrieben wird, besteht die Architektur der vorgeschlagenen Lösung aus einem zentralen Server für die Verwaltung von Benutzerdaten und einer beliebigen Anzahl abhängiger Internet-Dienste. Im Gegensatz zu einer Architektur für einen herkömmlichen Single Sign-On Prozess besteht die Client-Seite jedoch aus zwei Endgeräten: einem Rechner und einem Smartphone. Bei dem Rechner kann es sich prinzipiell um ein beliebiges Terminal (PC, Laptop, Tablet u.ä.) handeln, das über einen Bildschirm verfügt, der in der Lage ist einen QR Code mit zumutbarer Auflösung und genügend Kontrast darzustellen. Abgesehen von einem Standard-Browser mit Cookie-Unterstützung wird keine zusätzliche Software vorausgesetzt. Auf der Serverseite unterscheidet sich die vorgeschlagene Architektur vor allem durch eine Komponente, die für die Generierung der QR-Token zuständig ist. Die Rolle dieser Komponente ist es, die umgeleiteten Browser-Aufrufe des Benutzers zu verarbeiten und einen QR-Token mit den Sitzungsdaten zu erstellen, der benutzt werden kann um den Benutzer zu authentifizieren. Aus Gründen der Modularität, ist die Token-Generierung als eigenständig und logisch vom Rest des SSO-Servers getrennt konzipiert. Diese Trennung vereinfacht das Austauschen des eingesetzten Verfahrens für die Authentifizierung genauso wie das Anbinden eines anderen SSO-Servers. Die Kommunikation mit dem Server wird über HTTP bzw. HTTPS realisiert, um eine physikalische Trennung der beiden Server- Komponenten zu erlauben. In der Regel findet die Generierung der QR-Token jedoch auf dem gleichen Server statt, wie der Rest der Benutzerverwaltung.

26 Kapitel 3 Konzept 26 Abbildung 3.2: Architektur für die Integration eines Smartphones in ein SSO-Verfahren Protokoll und Ablauf In diesem Abschnitt wird detailliert beschrieben welche Abläufe nötig sind, um einen Benutzer im Rahmen der vorgeschlagenen Lösung für einen Single Sign-On Prozess zu authentifizieren. Vor allem die Kommunikation zwischen den involvierten Komponenten wird im Folgenden genauer betrachtet. Bevor die eigentliche Authentifizierung mit Hilfe eines Smartphones durchgeführt werden kann, muss der Benutzer sich beim SSO-Server registrieren. Wie in Abb. 3.3 gezeigt, wird hierbei eine Anfrage vom Smartphone des Benutzers an den SSO-Server gesendet. Im Zuge der Registrierung übermittelt der Benutzer einmalig seine Benutzerkennung und sein Passwort. Außerdem werden für spätere Überprüfungen einige charakteristische Daten des Mobilgerätes ausgelesen und in die Registrierungsanfrage eingebunden. Diese Informationen umfassen neben Typ und Modell des Gerätes auch eine zusammengesetzte ID, mit deren Hilfe das Gerät eindeutig identifiziert werden kann. Genauere Informationen zur Zusammensetzung und Erstellung dieser ID finden sich in Abschnitt 4.2. Bei einer erfolgreichen Überprüfung der Benutzerdaten, übermittelt der Server in seiner Antwort eine Unique User ID (UUID), eine Zeichenkette die den Benutzer eindeutig identifiziert. Die UUID wird bei späteren Kommunikationsprozessen mit

27 Kapitel 3 Konzept 27 der SSO-Architektur benutzt um redundante Übertragungen der Login-Daten des Benutzers zu vermeiden. Außerdem bekommt die mobile Anwendung durch die Server-Antwort einen kryptographischen Schlüssel zugeordnet, der eingesetzt wird um die Sicherheit beim Datenaustausch im Rahmen der Authentifizierung zu erhöhen. Abbildung 3.3: Registrierung eines Benutzers durch das Smartphone Nach einer erfolgreichen Registrierung kann der Benutzer sein Smartphone verwenden um Zugriff auf die abhängigen Dienste zu erhalten. Der hierfür nötige Authentifizierungs- Prozess wird durch den Aufruf eines eingehängten Dienstes im Browser des Rechners eingeleitet. In Abb. 3.4 ist der komplette Ablauf einer Authentifizierung leicht vereinfacht dargestellt. Das gezeigte Kommunikationsprotokoll entspricht dem Szenario einer erfolgreichen Autorisierung eines Benutzers, der im Vorfeld noch über keine aktive Sitzung verfügt.

28 Kapitel 3 Konzept 28 Abbildung 3.4: Ablauf eines SSO-Prozesses basierend auf dem Einscannen eines QR-Token durch ein Smartphone Analog zu den Markierungen in Abb. 3.4 sind folgende Schritte nötig um einen Benutzer mit Hilfe seines Smartphones zu authentifizieren: 1. Die Anfrage des Benutzers wird auf die Präsenz eines Sitzungs-Cookies untersucht. Wenn ein Cookie vorhanden ist, wird die enthaltene SID ausgelesen und durch eine Abfrage des SSO-Servers auf ihre Gültigkeit geprüft. Andernfalls, wird eine leere Abfrage durchgeführt, die der Anforderung einer neuen SID gleichkommt. 2. Der SSO-Server prüft die Sitzungs-Anfrage des abhängigen Dienstes. Falls die zu prüfende SID einer aktiven Sitzung entspricht, wird eine positive Rückmeldung an den Dienst gesendet. In diese Auskunft wird außerdem die UUID des Benutzers eingebunden, der die Sitzung validiert hat. Darüber hinaus, wird an dieser Stelle die, in Abb. 3.1 beschriebene, Verlängerung der Sitzung durchgeführt. Wenn keine passende Sitzung gefunden wird, oder die Abfrage keine SID enthält, wird eine neue zufällige Zeichenfolge für die Identifizierung der Sitzung erstellt und im Rahmen der Antwort an den Dienst geschickt. Diese Alternative entspricht dem in Abb. 3.4 dargestellten, weiteren Verlaufes der Authentifizierung. 3. Im Szenario einer noch nicht validierten Sitzung, entnimmt der Dienst der Auskunft des Servers die neu generierte SID und erstellt einen entsprechenden Session-Cookie. Dieser wird zusammen mit einer Redirect-Anweisung an den Rechner des Benutzers übermittelt. Dieser Response-Typ veranlasst, wie in [19] beschrieben, den Browser die Anfrage an eine andere URL umzuleiten. Währenddessen wird der Sitzungs- Cookie auf dem Client-Rechner verwahrt und bei jeder zukünftigen Anfrage an den Dienst mitgeschickt. Der Browser wird durch die Antwort des Dienstes an die QR- Token-Generierung umgeleitet. Hierbei werden außerdem die SID und die URL des

29 Kapitel 3 Konzept 29 Dienstes als URL-Parameter übermittelt. 4. Zu diesem Zeitpunkt werden die genannten URL-Parameter ausgelesen und es wird ein QR-Token für die Übermittlung der Sitzungsdaten an das Smartphone erstellt. Bevor das Token im Rahmen der HTTP-Antwort für die Darstellung auf dem Bildschirm des Benutzers übermittelt wird, muss die Sitzung durch eine Anfrage an den SSO-Server registriert werden. Außerdem wird ein weiterer Sitzungs-Cookie für die Internet-Domain des SSO-Servers erstellt. Dieser Cookie erlaubt bei Verlust des Sitzungs-Cookies eine sofortige Rückleitung des Benutzers an den Dienst ohne, dass eine erneute, unnötige Authentifizierung durchgeführt werden muss. Außerdem wird der Server-Cookie verwendet um dem Benutzer den Zugriff auf Dienste in verschiedenen Domains zu erlauben. 5. Über den Bildschirm des Rechners wird der generierte QR-Token dargestellt und kann mit Hilfe des Smartphones ausgelesen werden. Um den Benutzer nach einer erfolgten Authentifizierung automatisch wieder an den Dienst zu verweisen, wird der dargestellte Inhalt regelmäßig aktualisiert. Bei jedem Neuladen des Tokens, wird überprüft ob die entsprechende Sitzung bereits validiert wurde. 6. Im Rahmen der Authentifizierung werden sowohl die im QR-Token enthaltenen Daten der Sitzung, wie auch die am Mobilgerät gespeicherten Benutzerdaten übermittelt. Der SSO-Server überprüft die Validität der Sitzungsdaten und die Berechtigung des Benutzers die genannte Sitzung zu authentifizieren. Welche Kriterien hierbei beachtet werden, wird genauer in Kapitel 4, bei der Beschreibung der Implementierung erörtert. Nach einer erfolgreichen Überprüfung der erhaltenen Anfrage, wird die Sitzung durch den Server als gültig markiert. 7. Im Rahmen der, unter 5. beschriebenen, kontinuierlichen Aktualisierung der Seite, wird ständig die Gültigkeit der kodierten Sitzung überprüft. Sobald die Sitzung durch die Authentifizierung am SSO-Server validiert wird, wird der Benutzer durch einen erneuten Redirect zurück an den Dienst verwiesen.

30 Kapitel 3 Konzept Sitzungscookies Das vorgeschlagene SSO-Verfahren setzt zwei verschiedene Cookies für die Verfolgung einer Authentifizierungs-Sitzung ein. Diese unterscheiden sich lediglich durch die Domäne für die sie, über den Eintrag im Domain -Feld des Cookies (siehe 2.1.3), spezifiziert werden. Entsprechend wird ein Cookie durch den abhängigen Dienst für die eigene Domäne gesetzt (Dienst-Cookie) und der andere bei der Darstellung des QR-Tokens für die Server-Domäne definiert (Server-Cookie). Die Rolle des Dienst-Cookies besteht darin dem Dienst bei allen Anfragen durch den Benutzer dessen Sitzungs-ID mitzuteilen. Falls der Benutzer auf einen anderen abhängigen Dienst zugreift, der sich unter der selben Internet-Domäne befindet, muss dieser keine neue Sitzung anfordern. Bei Diensten einer Domäne kann ein gemeinsamer Sitzungscookie verwendet werden. Der zweite Dienst kann einfach die Sitzungs-ID auslesen und durch eine Serveranfrage überprüfen ob die entsprechende Sitzung auch für die eigene URL gültig ist. Durch dieses Vorgehen wird ein unnötiges Umleiten des Benutzers zum Server vermieden. Der Server-Cookie wird bei allen Umleitungen des Benutzers zur Authentifizierungs-Seite ausgelesen und geprüft. Falls die enthaltene SID zu einer bereits authentifizierten Sitzung passt, wird der Benutzer gleich wieder an den Dienst zurück geleitet. Hierdurch erspart der Benutzer sich ein erneutes Anmelden in Szenarien, bei denen die abhängigen Dienste auf verschiedene Domänen verteilt sind. Durch den Umstand, dass zwei Dienste verschiedene Domänen haben, kann der eine nicht auf den Dienst-Cookie des anderen zugreifen, obwohl der Benutzer eventuell bereits eine gültige Sitzung hat. Der Server-Cookie ermöglicht es also, sich auch bei verteilten Diensten nur ein einziges Mal anmelden zu müssen.

31 Kapitel 3 Konzept 31 Abbildung 3.5: Übertragung von Sitzungs-Cookies bei einer Verteilung der abhängigen Dienste auf mehrere Hosts In Abbildung 3.5 wird anhand von zwei Schritten verdeutlicht wie durch das Verfahren eine Verbindung zwischen zwei Sitzungen hergestellt werden kann. In Schritt 1 greift der Benutzer auf den ersten Dienst zu. Ihm werden sowohl vom Dienst selbst wie auch vom Server nach dem Redirect Cookies mit der Sitzungs-ID 1 zugewiesen. Anschließend, durch Schritt 2 veranschaulicht, schickt der Benutzer eine Anfrage an den Dienst 2, der sich in einer anderen Domäne befindet. Bei der Umleitung zum SSO-Server, übermittelt der Browser des Benutzers neben der neuen SID2 auch den zuvor gespeicherten Server-Cookie mit der SID1. Entsprechend kann der Server eine Verbindung zwischen den beiden Sitzungen herstellen und die Rechte der ersten Sitzung auf die zweite übertragen. Diese Vererbung von Rechten wird genauer unter Abschnitt 4.4 beschrieben.

32 Kapitel 3 Konzept 32 Abgesehen von seiner Rolle in einem Szenario mit mehreren Dienst-Domänen, dient der Server-Cookie als Backup für den Dienst-Cookie. Falls aus irgendeinem Grund der Dienst- Cookie verloren geht oder fehlerhaft ist, wird der Benutzer dennoch am Server erkannt. Denkbar sind auch Lösungen, die auf der Seite des Dienstes komplett auf einen Cookie verzichten und bei jeder Überprüfung des Benutzers eine Umleitung zum Server fordern QR-Token am Dienst einbetten Neben der Möglichkeit einen Browser an eine externe Webseite weiterzuleiten, die für die Darstellung eines Tokens in Form eines QR-Codes zuständig ist, sollen abhängige Dienste die QR-Token direkt in ihren eigenen Webinhalt einbetten können. Hierfür muss das eingesetzte Verfahren leicht modifiziert werden. Die für die Generierung der QR-Token zuständige Komponente muss die nötige Funktionalität vorsehen um unter einer sitzungsspezifischen URL den entsprechenden QR-Code als Bilddatei bereitzustellen. Darüber hinaus muss ein Teil der Funktionalität an den Dienst ausgelagert werden. In diesem Szenario obliegt es dem Dienst einen geeigneten Ablauf zu implementieren um dem Benutzer den Token zu präsentieren und die Gültigkeit der Sitzung wiederholt zu überprüfen. In Abschnitt 4.5 wird genauer darauf eingegangen wie die Funktionalität am Dienst integriert werden kann. Diese Alternative erscheint vor allem im Hinblick auf die Benutzerfreundlichkeit vorteilhaft. Durch den Verzicht auf eine Umleitung des Browsers auf eine externe Seite für die Authentifizierung, erschafft der Dienst ein einheitlicheres Benutzererlebnis. Dies wird noch dadurch verstärkt, dass der Dienstbetreiber die Möglichkeit hat, den Token kreativ in sein Design zu integrieren und nicht auf die optische Kompatibilität zur Darstellung des Identity-Providers angewiesen ist. 3.4 Das Smartphone als Endgerät für den Zugriff auf geschützten Inhalt Neben der beschriebenen Möglichkeit, Sitzungen am Rechner zu authentifizieren, soll der Benutzer auch direkt von seinem Mobilgerät auf geschützte Inhalte zugreifen können. Im folgenden werden zwei Verfahren vorgeschlagen, wie das Smartphone als Endgerät in den Single Sign-On-Prozess eingebunden werden kann Übertragung aktiver Sitzungen an das Smartphone Nachdem ein Benutzer für den Zugriff auf einen abhängigen Dienst authentifiziert wurde, ist es möglich die aktive Sitzung auf das Smartphone auszudehnen, bzw. zu übertragen. Hierzu kann der entsprechende Dienst dem Benutzer einen QR-Code zur Verfügung stellen. Um

33 Kapitel 3 Konzept 33 dies Umzusetzen, muss ein entsprechender Sitzungscookie im Standard-Browser des Smartphones gesetzt werden. Leider lässt sich dies nicht direkt aus der mobilen Anwendung lösen. Genau wie alle anderen Android-Applikationen ist auch der Standard-Browser, wie in Abschnitt beschrieben, durch eine Sandbox geschützt. Dies verhindert das Einschleusen oder Manipulieren der Cookies von außen. Durch das Einscannen des TransferCodes werden die Sitzungsinformationen an das Gerät übermittelt. Die mobile Anwendung startet im Anschluss den Browser und ruft eine geeignete Schnittstelle des SSO-Servers auf. Bei diesem Aufruf werden die Sitzungsinformationen in Form von URL-Parametern übertragen, sodass ein Cookie für die Domain des Servers erstellt werden kann. Anschließend wird der Benutzer an den Dienst weitergeleitet, bei dem die übertragene Sitzung angelegt wurde. Wenn diese Lösung auch umständlich wirkt, ist sie doch nicht störend, da das wiederholte Weiterleiten des Browsers im Hintergrund abläuft. Ein Alternative wäre das Abrufen der Sitzungsinformation über eine direkte Verbindung zwischen dem Dienst und dem Server. Da sich die Einbindung des Systems auf der Dienst-Seite jedoch möglichst einfach gestalten soll, ist eine Lösung mittels Cookies vorzuziehen. Aus Sicht des Dienstes ändert sich entsprechend nichts an der Authentifizierungs-Logik Authentifizieren einer Sitzung im Browser des Smartphones Um eine vollständige Einbindung des Smartphones in das SSO-Verfahren zu realisieren, wurde auch eine Möglichkeit entwickelt eine Sitzung direkt im Browser des Mobilgerätes zu authentifizieren. Hierfür muss bei der Authentifizierung am Server unterschieden werden ob die Anfrage vom Browser eines Mobilgerätes oder eines Rechners stammt. Entsprechend kann für die Authentifizierung am Smartphone auf die Darstellung eines QR-Codes verzichtet werden. Stattdessen wird der angezeigte Inhalt für die speziellen Bedürfnisse eines mobilen Browsers angepasst. In diesem Kontext wurde eine Lösung entwickelt, um die mobile Anwendung für die Authentifizierung direkt aus dem Browser zu starten. Hierbei werden zugleich die aktuellen Sitzungsinformationen an die mobile Anwendung übermittelt. Somit kann der Benutzer ohne weitere Eingaben eine Sitzung authentifizieren und zum gewünschten Inhalt geleitet werden. Dieses Verfahren wird in Abschnitt 4.2 genauer beschrieben. 3.5 Mobile Verwaltung des SSO-Prozesses Die für die Authentifizierung eingesetzte mobile Applikation kann erweitert werden um die Übersicht und Kontrolle des Benutzers über seine Authentifizierungsprozesse zu verbessern. Hierbei kommt eine Profilfunktion zum Einsatz, die den gezielten Zugang zu eingebundenen Inhalten vereinfacht. Darüber hinaus hat der Benutzer die Möglichkeit seine authentifizierten Sitzungen auch von unterwegs zu beenden.

34 Kapitel 3 Konzept Mobiles Profil Der Benutzer soll die Möglichkeit haben sich mit Hilfe seines Smartphones über den Zustand seiner persönlichen Daten im Rahmen der SSO-Architektur zu informieren. Hierzu gehört neben den persönlichen Informationen, die den Benutzer selbst betreffen, auch eine Zusammenfassung seiner aktiven Sitzungen. Darüber hinaus kann der Benutzer sich einen Überblick verschaffen, bei welchen Diensten er sich mit Hilfe seines Smartphones anmelden kann. In Abschnitt 4.2 wird genauer erläutert welche Informationen dieses Profil enthält und wie es vom Server abgerufen wird. Über die reine Darstellung von Informationen hinaus, bietet ein solches Profil die Grundlage für verschiedene Interaktionen: Der Benutzer kann ausgehend von der Liste der verfügbaren Dienste, direkt aus der Applikation auf die entsprechenden Inhalte zugreifen. Aktive Sitzungen können, wie in Unterabschnitt beschrieben, auf das Mobilgerät übertragen und im Browser dargestellt werden. Sitzungen können gezielt durch den Benutzer beendet werden. (vgl ) Diese Optionen erlauben es dem Benutzer direkt aus der mobilen Applikation heraus Einfluss auf den SSO-Prozess zu nehmen. Im Folgenden wird genauer beschrieben welche Rolle die Möglichkeit, Sitzungen zu beenden, hierbei einnimmt Mobiler Single Log-Out Eine wichtige Funktionalität im Rahmen einer SSO-Architektur, ist die Möglichkeit des Benutzers eine Sitzung explizit zu beenden. Gewöhnlich wird durch den Dienst bei dem die Sitzung läuft hierfür eine geeignete Schaltfläche zu Verfügung gestellt. Das gezielte Beenden einer Sitzung erfolgt also direkt im Browser des Rechners. Durch die Einbindung eines Smartphones in diesen Prozess, kann sich der Benutzer auch von unterwegs ausloggen. Durch das Integrieren der geeigneten Funktionalität in die mobile Applikation, können durch einen einzelnen Tastendruck alle aktiven Sitzungen eines Benutzers invalidiert werden. Diese Funktion fügt sich nahtlos in die zuvor beschriebene Realisierung eines Benutzerprofils ein. Da es möglich ist, sich im Rahmen dieser Profilfunktion einen Überblick über aktuell aktive Sitzungen zu verschaffen, ist es sinnvoll an gleicher Stelle auch ungewollte Sitzungen beenden zu können. Neben dem zusätzlichen Komfort für den Benutzer, wird durch die Realisierung eines Profils in Kombination mit der Möglichkeit Sitzungen immer und überall zu beenden, auch die Transparenz des gesamten Prozesses erhöht.

35 Kapitel 3 Konzept Sicherheit In diesem Abschnnitt wird die Sicherheit des Konzeptes analysiert und festgestellt an welchen Stellen eventuell Verwundbarkeit gegenüber Angreifern besteht Aushorchen eines Cookies Durch das Abhören einer ungesicherten Verbindung kann ein Angreifer Zugriff auf den Inhalt eines Cookies erlangen. Falls es sich dabei um den Sitzungs-Cookie einer aktiven Sitzung handelt, kann er sich theoretisch durch klonen des Cookies für den Benutzer ausgeben. Um dies zu unterbinden dürfen Cookies im Rahmen des Single Sign-On Prozesses ausschließlich über Verbindungen übertragen werden, die durch Transport Layer Security (SSL/TLS) [20] gesichert sind. Im Rahmen einer derartig geschützten Kommunikation, wird die in Abschnitt 3.2 geforderte Vertraulichkeit, durch eine symmetrische Verschlüsselung der übermittelten Daten erreicht. Die Beschränkung des Cookies auf die Verwendung mit sicheren Verbindungen, kann wie in Abschnitt gezeigt, über das Setzen des Parameters Secure durchgesetzt werden. Eine weitere Möglichkeit den Angreifer davon abzuhalten unerlaubt eine Sitzung zu übernehmen, ist die direkte Bindung der Sitzungen an die IP-Adresse des Rechners von dem aus sie angefragt wurde Malware auf dem Rechner Durch das Einsetzen von Schadsoftware wie z.b. einem Trojaner auf dem Rechner des Benutzers, kann ein Angreifer unweigerlich unbefugten Zugriff auf die Sitzungsdaten erhalten. Dennoch bietet der Einsatz der QR-Token-basierten Authentifizierung hier eine deutliche Verbesserung gegenüber einem herkömmlichen Verfahren bei dem die Benutzerdaten über ein HTML-Formular übertragen werden: Der Angreifer kann das Password des Benutzers nicht über einen Keylogger auslesen, der sämtliche über die Tastatur des Rechners getätigten Eingaben aufzeichnet. Da nur die Sitzungsinformationen am Rechner bekannt sind, kann der Angreifer nicht auf die, am Smartphone verwalteten Benutzerinformationen, zugreifen. Dies führt dazu, dass der Zugriff nur im Rahmen einer offenen Sitzung kompromittiert ist. Das vorgeschlagene Verfahren ist demnach wesentlich resistenter gegen Malware auf dem Rechner, als ein System, das auf der Eingabe eines Passwortes basiert. Selbst bei einer totalen Kompromittierung des Rechners, beschränkt sich das Risiko auf bereits authentifizierte Sitzungen. Ein Angreifer erhält nicht die Möglichkeit selbst neue Sitzungen zu erstellen und zu validieren.

36 Kapitel 3 Konzept Malware auf dem Smartphone Wenn das Smartphone durch Schadprogramme kompromittiert ist, ist es theoretisch möglich, dass böswillige Software an die Benutzerdaten für den SSO-Prozess kommt. Das Android-Betriebssystem verhindert prinzipiell, wie in Abschnitt 2.3 erläutert, dass eine Anwendung auf die privaten Daten einer anderen Applikation zugreifen kann. Außerdem ist die Verbreitung von Malware bei mobilen Betriebssystemen noch sehr eingeschränkt und meist darauf beschränkt persönliche Daten wie Position und Kontaktdaten zu stehlen. Trotzdem ist es ratsam Gegenmaßnahmen für den unwahrscheinlichen Fall zu ergreifen, dass ein Angreifer die UUID eines Benutzers einsehen kann. Hierzu wird dem Benutzer bei der Registrierung ein persönlicher Schlüssel zugeteilt. Durch die serverseitige Überprüfung einer symmetrisch verschlüsselten Zeichenkette, kann sichergestellt werden, dass der Benutzer im Besitz dieses Schlüssels ist. Gelingt es nun einem Angreifer auch diesen Schlüssel auszulesen, wird eine Manipulation zusätzlich dadurch erschwert, dass der für die Verschlüsselung gebrauchte Initialisierungsvektor (IV) als Konstante auf Code-Ebene verankert und somit nicht auslesbar ist Phishing-Attacken Bei typischen Phishing-Attacken [21], wird dem Benutzer eine gefälschte Webseite präsentiert, die ihn dazu verleiten soll seine Login-Daten an eine nicht vertrauenswürdige Partei zu übermitteln. Speziell OpenID ist sehr anfällig für Phishing-Attacken, bei denen ein böswilliger oder kompromittierter Dienst den Benutzer an eine gefälschte Login-Maske verweist. Das in dieser Arbeit vorgeschlagene Verfahren ist hingegen sehr resistent gegenüber dieser Art von Angriffen. Da der Benutzer seine Kennung nicht, wie üblich, in das Formular einer Webseite einträgt, gibt es keinen entsprechenden Angriffspunkt. Die Benutzerdaten werden vom Smartphone ausschließlich an den zentralen Server der SSO- Architektur übertragen. Denkbar wäre ein entsprechender Angriff bei dem der Benutzer dazu gebracht wird, einen gefälschten QR-Token einzulesen. Dadurch gewinnt der Angreifer allerdings keinen Vorteil, da er die Kennung des Benutzers nicht abfangen kann Angriff auf den Token-Transfer Es ist denkbar, dass ein Angreifer versucht unerlaubt den QR-Token eines Benutzers einzuscannen. Entsprechend könnte er die kodierten Sitzungsdaten auslesen und käme in den Besitz der Sitzungs-ID und der Service-URL. Um selbst eine Sitzung zu validieren, fehlen dem Angreifer also die, auf Seite des Smartphones verwalteten Benutzerdaten. Allerdings hat der Angreifer die Möglichkeit sich selbst einen Cookie mit der geklauten SID zu konstruieren und darauf zu warten, dass der Benutzer selbst die Sitzung authentifiziert. Wie schon in dem Paragraphen Aushorchen eines Cookies beschrieben, könnte eine derartige Attacke

37 Kapitel 3 Konzept 37 am Effektivsten durch das Binden der Sitzung an die IP-Adresse des Client-Rechners unterbunden werden. Eine alternative Gegenmaßnahme ist die systematische Verschlüsselung des Token-Inhaltes vor dem Erstellen des QR-Codes. Der Angreifer müsste dann über den symmetrischen Schlüssel verfügen um die Sitzungsdaten auslesen zu können. Bei dem in Abschnitt 3.4 vorgeschlagenen Sitzungstransfer an das Smartphone, besteht indessen keine Gefahr durch das unerlaubte Auslesen des entsprechenden QR-Codes. Da die Anfrage zum Sitzungstransfer von der Smartphone-Applikation eingeleitet wird, werden hierbei die Benutzerdaten integriert. Beim Transfer einer Sitzung muss der am Smartphone registrierte Benutzer also dem Eigentümer der Sitzung entsprechen Man-in-the-middle Eine beliebte Angriffsmethode ist der sogenannte Man-in-the-middle-Angriff (MITM). Hierbei klinkt sich ein Angreifer in die Kommunikation ein und gibt sich bei beiden Parteien als der jeweilige Kommunikationspartner aus. Durch diese Position kann der Angreifer die Datenübertragung beliebig manipulieren. Im Rahmen des vorgestellten SSO-Verfahrens ist eine solche Attacke auf zwei verschiedene Bereiche der Kommunikation denkbar: 1. Der Angreifer könnte die Verbindung zwischen dem Smartphone und dem SSO-Server manipulieren und versuchen eine gefälschte Sitzung zu authentifizieren. 2. Es könnte versucht werden die Kommunikation zwischen dem SSO-Server und einem abhängigen Dienst zu kompromittieren um ihn bezüglich der Gültigkeit einer Sitzung zu täuschen. Die beste Möglichkeit MITM-Angriffe zu vermeiden ist die konsequente Verwendung von SSL/TLS zum Schutz von Datenübertragungen. Wie in [20] beschrieben, werden hierbei vertrauenswürdige Zertifikate [22] eingesetzt um die Kommunikationspartner zu authentifizieren. Meistens wird zwar nur die Identität der Serverseite überprüft, dieser Schutz reicht jedoch aus um MITM-Angriffe in diesem Rahmen zu vermeiden. Die Sicherheit der Kommunikation hängt hier in starkem Maße von der Vertrauenswürdigkeit des verwendeten Server-Zertifikates ab. Zusätzlich zum Schutz der Kommunikation durch SSL, wird bei der Authentifizierung einer Sitzung durch das Smartphone eine, mit dem geheimen Schlüssel des Benutzers verschlüsselte, Zeichenkette übermittelt. Teil dieser Zeichenkette ist unter anderem auch die SID der zu authentifizierenden Sitzung. Entsprechend kann vom SSO-Server nicht nur überprüft werden ob das Gegenüber im Besitz des Benutzer-Schlüssels ist, sondern auch sichergestellt werden, dass die SID authentisch ist.

38 Kapitel 4 Implementierung In Kapitel 3 wurde ein Konzept für den Einsatz eines Smartphones im Rahmen eines SSO-Verfahrens vorgeschlagenen. Im Folgenden wird die Implementierung eines Prototyps beschrieben, der die Validität dieses Konzeptes beweist. Die Entwicklung umfasste die Realisierung aller in der Authentifizierung involvierten Komponenten und des Kommunikationsprotokolls um diese zu verbinden. Im Folgenden wird im Detail beschrieben wie die einzelnen Komponenten realisiert wurden und welche Umgebung für ihre Entwicklung benutzt wurde. 4.1 Eingesetzte Entwicklungsumgebung Im Rahmen diese Abschnittes wird beschrieben welche Ressourcen, Technologien und Software verwendet wurde um die Entwicklung des beschriebenen Systems zu realisieren. Programmiersprache und IDE Für die Entwicklung sämtlicher Komponenten wurde die objektorientierte Programmiersprache Java [17] eingesetzt. Durch die Anforderungen der Implementierung wurden hierbei vor allem auf die Bibliotheken der Java Enterprise Edition (JEE) verwendet. Als integrierte Entwicklungsumgebung (IDE) kamen je nach Bedarf die beiden frei verfügbaren Programme Eclipse [23] und NetBeans [24] zum Einsatz. Beide bieten vollen Zugriff auf die Standard-Bibliotheken von Java und unterscheiden sich vor allem durch die integrierten Schnittstellen zu verschiedenen Frameworks und anderen Technologien. Technologie-Basis und verwendete Frameworks Als Basis für die Implementierung werden Servlets [25] und JavaServer Pages (JSP) [26] eingesetzt. Sowohl der Prototyp für den abhängigen Dienst, wie auch die Realisierung der server-seitigen Komponenten beruhen auf dem Einsatz dieser Java-Klassen. Servlets werden in einen Java-Anwendungsserver eingebunden und verwalten HTTP- Anfragen. Hierbei kann der Inhalt der Antworten dynamisch generiert werden, muss also 38

39 Kapitel 4 Implementierung 39 nicht wie z.b. im Fall von HTML-Seiten, fest vordefiniert sein. Der Einsatz dieser Technologien erlaubt es also eine Schnittstelle für HTTP-Anfragen anzubieten, die auf übermittelte Variablen reagieren und eine angepasste Antwort zurückliefern kann. Die Übermittlung von Variablen wird im HTTP-Protokoll, wie in [19] beschrieben, typischerweise in Form von Headern oder URL-Parametern realisiert. Beide Parameter-Typen können im Rahmen eines Servlets durch einfache Funktions-Aufrufe aus der Anfrage ausgelesen werden. Die JavaServer Pages Technologie baut auf der Grundlage von Servlets auf und bietet eine einfache Möglichkeit für die dynamische Darstellung von HTML- und XML-Inhalten. Hierbei kann ausgehend von statischem Inhalt, je nach Bedarf durch eingebetteten Java-Code die Ausgabe gesteuert werden. Weiterhin wurde bei der Implementierung das Open-Source-Framework Apache Struts [27] eingesetzt. Es erweitert die beschriebenen Technologien um nützliche Funktionen, die eine bessere Organisation von Webanwendungen nach dem Model-View-Controller-Prinzip erlauben. Insbesondere wird eine sinngemäße Behandlung von Formulardaten wesentlich vereinfacht. Server Um eine realistische Verteilung der Komponenten für den SSO-Server und die abhängigen Dienste zu erstellen, wurden für die Entwicklung mehrere von einander getrennte Server, mit verschiedenen Domänen eingesetzt: Authentification-Server Auf diesem Server laufen sowohl die Implementierung des SSO-Servers sowie die Generierung und Verwaltung der QR-Token. Service-Server Alle abhängigen Dienste werden unter dieser Domain zur Verfügung gestellt. Database-Server Die Datenbank für die Verwaltung der Benutzer und Sitzungsdaten wird auf einem getrennten Server realisiert. Die eingesetzten Systeme stellen für die Veröffentlichung von dynamischen Webinhalten den Java-Webserver Apache Tomcat in der Version 6 zur Verfügung. Tomcat bietet eine quelloffene Plattform für die Ausführung von Java-Code im Rahmen von Webapplikationen. Im Mittelpunkt der Fähigkeit Java-Code auszuführen steht die Integration eines Servlet-Containers, der wie in [25] beschrieben, den Zugriff auf Servlets verwaltet. Auf dem Datenbankserver läuft eine Installation des relationalen Datenbanksystems MySQL [28]. Der externe Zugriff auf den Inhalt der Datenbank ist auf die Domäne des Authentification- Servers beschränkt. Benutzerverzeichnis Als Grundlage für Authentifizierungsprozesse, wird am Server ein Benutzerverzeichnis zur Verfügung gestellt. Der Zugang zum Verzeichnis erfolgt über das Lightweight Directory Access Protocol (LDAP), dessen Funktionsweise in [29] beschrieben wird. Mit Hilfe von LDAP können persönliche Informationen zu allen Benutzern abgerufen werden, die im Rahmen eines SSO-Verfahrens authentifiziert werden sollen. Unter ande-

40 Kapitel 4 Implementierung 40 rem werden hier auch Gruppenzugehörigkeiten definiert, die bei Zugriffsentscheidungen berücksichtigt werden können. Entwicklung für die Android-Plattform Wie in Abschnitt 2.3 erläutert, basiert die Entwicklung von Applikationen für Android auf der Programmiersprache Java. Für die Umsetzung kommt die Entwicklungsumgebung Eclipse zum Einsatz, die über ein Plugin um die nötige Funktionalität erweitert wird. Neben dem Zugriff auf die Android- Klassenbibliotheken, erlaubt das Plugin vor allem die einfache Verwaltung von Android kompatiblen Projekten. Darüber hinaus wird die Möglichkeit geboten erstellte Software wahlweise in einer emulierten Umgebung oder direkt auf einem angeschlossenen Smartphone auszuführen und zu debuggen. 4.2 Smartphone-Applikation Eigens für die Realisierung einer Verbindung zwischen dem Smartphone und der beschriebenen SSO-Architektur, wurde eine Applikation für die Android Plattform implementiert. Bevor der Benutzer sich gegenüber dem System authentifizieren zu kann, muss er die im Folgenden beschriebene Software auf seinem Mobilgerät installieren. Um ihre Rolle in der Authentifizierung eines Benutzers erfüllen zu können, muss die Anwendung auf verschiedene Systemressourcen, wie eine offene Internetverbindung zugreifen können. Entsprechend müssen, wie in Abschnitt beschrieben, eine Reihe Berechtigungen erteilt werden: Internet Erlaubt der Applikation das Öffnen von Netzwerk-Sockets. Diese Berechtigung ist notwendig um eine Internetverbindung aufzubauen und mit dem Server zu kommunizieren. Read Phone State Wird benötigt um lesend auf den Zustand des Telefons zugreifen zu können. Hierzu gehört auch das Auslesen der International Mobile Station Equipment Identity (IMEI). Access Wifi State Neben dem Auslesen von Informationen zu verfügbaren Drahtlosnetzwerken, fällt auch das Beschaffen von Daten bezüglich des Netzwerk-Interfaces unter diese Berechtigung. Access Network State Diese Berechtigung erlaubt der Anwendung den Netzwerkstatus des Gerätes einzusehen. Get Accounts Erlaubt den Zugriff auf die Liste der an diesem Gerät angemeldeten Accounts. Neben der hier beschriebenen Applikation, muss außerdem die Software BarcodeScanner des ZXing Teams auf dem, für das SSO-Verfahren eingesetzten Smartphone installiert sein. Wie bereits unter Abschnitt beschrieben, ermöglicht diese Anwendung unter anderem

41 Kapitel 4 Implementierung 41 das Einlesen und Dekodieren von QR-Codes. In Abschnitt wird genauer beschrieben wie das Einscannen eines QR-Tokens mit Hilfe des BarcodeScanner realisiert wird. Der Startbildschirm der Applikation präsentiert dem Benutzer eine Auswahl zwischen 3 Buttons, über die er zu den verschiedenen Funktionen wechseln kann: Das Scannen eines QR-Codes Das Registrieren eines Benutzers beim SSO-Server Das Anzeigen des Benutzerprofils Entsprechend werden für die Abdeckung dieser Funktionalitäten geeignete Activities gestartet, deren Darstellung in Abb. 4.1 zu sehen ist. Abbildung 4.1: Übersicht der Funktionalitäten der mobilen Anwendung

42 Kapitel 4 Implementierung Registrierung eines Benutzer Die Registrierung des Benutzers beim SSO-Server stellt, wie in Kapitel 3 erörtert, den ersten Schritt im SSO-Verfahren dar. Im Rahmen der mobilen Applikation wurde für das Durchführen der Registrierung die Activity-Klasse RegistrationActivity implementiert. Die Oberfläche der Activity enthält wie in Abb. 4.1 zu sehen ist, neben Beschriftungen vor allem zwei Eingabefelder und einen Button. An dieser Stelle wird der Benutzer aufgefordert seinen Benutzernamen und sein Passwort in die Eingabefelder einzutragen und sich durch Betätigung des Buttons zu registrieren. Durch das Einleiten der Registrierung, werden in einem ersten Schritt ausgewählte Parameter des Mobilgerätes ausgelesen die an den Server übertragen werden. Unter anderem wird hierbei eine Zeichenfolge definiert die es erlaubt das Mobilgerät eindeutig zu identifizieren. Leider stellt die Android-Plattform keine Identifizierungs-Nummer zu Verfügung, mit deren Hilfe ein spezifisches Smartphone mit genügender Verlässlichkeit erkannt werden kann. Deshalb wurde eine Lösung entwickelt, um durch die Kombination verschiedener Parameter, eine Zeichenfolge zu generieren die eindeutig für ein bestimmtes Gerät ist. Diese Zeichenfolge setzt sich aus folgenden Bestandteilen zusammen: 1. Android-ID (AID) 2. International Mobile Station Equipment Identity (IMEI) 3. Integrated Circuit Card Identifier (ICCID) 4. Google-Account Namen Die AID ist eine vom Betriebssystem verwaltete Erkennungs-Nummer, die einzeln betrachtet keine genügende Verlässlichkeit bietet. Bei manchen Android-Versionen ist sie fehlerhaft implementiert. Darüber hinaus kann sie bei gerooteten Geräten leicht manipuliert werden. Die IMEI wird durch die Hersteller von Mobilfunkgeräten zum Zweck einer eindeutigen Identifikation festgelegt. Sie wird unter anderem eingesetzt, um gestohlene Geräte für die Benutzung von Mobilfunknetzen zu sperren. Leider lässt sich durch Einsatz von geeigneter Software die IMEI eines Gerätes manipulieren. Die ICCID entspricht der Seriennummer einer SIM-Karte. Sie wird unter anderem verwendet um einen Mobilfunk-Teilnehmer international gegenüber dem Netzanbieter zu identifizieren. Entsprechend, eignet sich diese ID prinzipiell für die eindeutige Repräsentation eines Smartphones. Durch die alleinige Verwendung der ICCID als Merkmal für das Mobilgerät würde jedoch die Präsenz einer SIM-Karte zwingend vorausgesetzt. Sowohl die IMEI als auch die ICCID können durch die Verwendung der Klasse TelephonyManager aus der Android-Bibliothek ausgelesen werden. Als zusätzliches Identifikationsmerkmal wird ausgelesen an welche Google-Accounts das Android-Gerät gebunden ist. Um bei der Übermittlung der Daten an den Server die Privatsphäre des Benutzers nicht unnötig zu gefährden, werden eventuelle Google-Konten nicht im Klartext verwendet sondern durch ein Hash-Verfahren unkenntlich gemacht.

43 Kapitel 4 Implementierung 43 Die Zusammensetzung der gewünschten Mobile Unique ID (MUID) wird durch die Aneinanderreihung der genannten Parameter realisiert. Hierbei werden Bindestriche als Trennungszeichen eingesetzt, sodass je nach Bedarf eine getrennte Überprüfung der einzelnen Merkmale möglich ist. Entsprechend ergibt sich die folgende Form für die MUID: MUID: 27996ce5b079ef1f e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 In einzelnen Fällen, wenn z.b. ein Smartphone ohne SIM-Karte oder mit einer modifizierten Systemsoftware eingesetzt wird, können einzelne Komponenten der MUID Nullwerte enthalten. Neben der zusammengesetzten MUID werden bei der Registrierung des Benutzers noch weitere Informationen zum benutzten Smartphone übermittelt. So wird etwa die Media- Access-Control-Adresse (MAC) des Netzwerk-Interfaces ausgelesen. Außerdem wird eine Zeichenkette generiert die dem Server mitteilt um welches Modell, von welchem Hersteller es sich bei dem eingesetzten Mobilgerät handelt. Hierdurch wird dem Server, bei Bedarf eine genauere Spezifizierung des Kommunikationspartners erlaubt. Nach dem erfolgreichen Auslesen der beschriebenen Geräte-Informationen, werden der Login-Name und das Passwort des Benutzers aus den entsprechenden Eingabefeldern gelesen. Anschließend wird, analog zu dem in Abb. 3.3 gezeigten Protokoll, eine HTTPS-Verbindung zum SSO- Server aufgebaut. Über diese Verbindung wird anschließend eine Anfrage zur Benutzer- Registrierung gestartet, die von der unter 4.4 beschriebenen API, durch die Präsenz der passenden HTTP-Header erkannt und bearbeitet wird. Neben einem Header, der den Anfrage-Typ definiert, werden auch die für die Registrierung nötigen Daten durch entsprechende Header übertragen. Bei erfolgreicher Überprüfung der Benutzerdaten, enthält die Antwort des Servers zwei Header, durch die der Smartphone-Applikation eine UUID und ein kryptographischer Schlüssel zugeteilt werden. Die enthaltenen Zeichenfolgen werden für die weitere Verwendung im privaten Speicher der Anwendung abgelegt. Die Benutzer- und Geräteinformationen werden hingegen nicht von der mobilen Anwendung abgespeichert sondern gleich wieder verworfen. Hierdurch wird eine möglichst hohe Sicherheit für die sensiblen Login-Daten gewährleistet. Außerdem ist es sinngemäß, dass die Daten zum Mobilgerät bei einer erneuten Registrierung, neu ausgelesen werden müssen Auswertung eines QR-Codes Das Einlesen eines QR-Codes wird durch das Initiieren der Funktionalität der, in Abschnitt beschriebenen, ZXing-Applikation eingeleitet. Hierzu wird ein entsprechender Intent gestartet, in dessen Kontext ein QR-Code gescannt werden kann. Nach Abschluss des Vorgangs, wird der Inhalt als Zeichenfolge an die Applikation zurückgegeben. Bevor der Scanvorgang und die anschließende Auswertung der Daten gestartet werden können, werden wie in Abbildung 4.2 dargestellt, einige Überprüfungen durchgeführt.

44 Kapitel 4 Implementierung 44 Für den Fall, dass die BarcodeScanner-Applikation nicht bereits auf dem Smartphone installiert ist, wird dem Benutzer die Möglichkeit gegeben dies nachzuholen. Hierzu wird er zum entsprechenden Eintrag im Android-Market weitergeleitet. Wenn dieser nicht vorhanden ist, wird der Browser mit der Homepage des Entwicklers geöffnet. Darüber hinaus wird gleich zu Beginn des Vorganges überprüft ob das Mobilgerät aktuell über eine aktive Internetverbindung verfügt. Da alle unterstützten Funktionen auf die Möglichkeit angewiesen sind eine Verbindung zum Server aufzubauen, führt das Fehlen einer Internetverbindung zum sofortigen Abbruch. Der Benutzer wird durch eine entsprechende Fehlermeldung aufgefordert vor dem Einscannen eine Verbindungsmöglichkeit sicherzustellen. Außerdem wird sichergestellt, dass der Benutzer sich bereits mit Hilfe der entsprechenden Funktion registriert hat. Hierzu wird überprüft ob sich eine gültige UUID im Speicher befindet. Abbildung 4.2: Flussdiagramm der durchgeführten Überprüfungen vor dem Einscannen eines QR-Codes Nach dieser Überprüfung bekommt der Benutzer die Gelegenheit das Smartphone zu benutzen um mit Hilfe der eingebauten Kamera einen QR-Code einzuscannen. Anhand der ausgelesenen Zeichenkette, kann die Anwendung unterscheiden ob es sich bei dem Code um ein Token zur Authentifizierung einer Sitzung an einem Rechner oder um einen Sitzungstransfer zum Smartphone handelt. Wie in Abb. 4.3 gezeigt, wird je nach Typ des Codes einer der folgenden Abläufe gestartet:

45 Kapitel 4 Implementierung 45 Authentifizieren einer Sitzung Eine Anfrage zur Authentifizierung einer Sitzung wird dadurch identifiziert, dass die eingelesene Zeichenkette mit dem Wort qrtoken beginnt. Wie bereits in Abschnitt 3.1 erwähnt, enthält die kodierte Zeichenfolge die SID, die URL des Dienstes und einen Zeitstempel. Nachdem diese Parameter ausgelesen wurden, wird der Benutzer durch einen Dialog befragt ob er eine Sitzung bei dem Dienst mit der URL aus dem QR-Code authentifizieren will. Diese Abfrage soll gleichzeitig die Transparenz des Verfahrens erhöhen und den Benutzer davor schützen, ungewollte Sitzungen zu berechtigen. Wenn der Benutzer der Authentifizierung zustimmt, werden in dem nächsten Schritt die gleichen gerätespezifischen Identifizierungsmerkmale ausgelesen wie bei der unter Abschnitt beschriebenen Registrierung. Anschließend wird eine Netzwerkverbindung zum Server aufgebaut. Die Sitzungsdaten aus dem QR-Token, die Benutzerdaten aus dem Speicher und die Parameter des Smartphones werden in entsprechenden HTTP-Header der Anfrage übermittelt. Außerdem werden die Sitzungsdaten mit Hilfe des Benutzerschlüssels aus dem Speicher, durch ein AES-Verfahren [30] verschlüsselt und in einem zusätzlichen Header mit verschickt. Der SSO-Server kann diesen Header später auslesen und durch eine Wiederholung der Verschlüsselung überprüfen ob der Kommunikationspartner im Besitz des zugeteilten Benutzerschlüssels ist. Die Antwort des SSO-Servers teilt dem Benutzer mit, ob die Authentifizierung erfolgreich abgeschlossen werden konnte oder sendet gegebenenfalls eine Fehlermeldung die ihn über den Grund des Fehlschlagens informiert. Transfer einer aktiven Sitzung Ein QR-Code zur Übertragung einer aktiven Sitzung enthält prinzipiell die gleichen Daten wie ein QR-Token für die Authentifizierung. Unterschieden wird der kodierte Inhalt durch das Vorhandensein der Zeichenkette qrtransfer gleich am Anfang. Genau wie im Rahmen einer Authentifizierung, werden wieder die im QR-Code enthaltenen Sitzungsdaten ausgelesen und die Benutzerdaten aus dem Speicher geladen. Dann wird der Standard-Browser des Android-Gerätes gestartet und eine URL aufgerufen in die Sitzungs- und Benutzerdaten als Parameter eingetragen sind. Die URL verweist auf eine Java Server Page (JSP) am SSO-Server, die genauer unter Abschnitt beschrieben wird. Durch das Auslesen der übermittelten URL-Parameter kann der Server eindeutig bestimmen welche Sitzung übertragen werden soll und welcher Benutzer diese Anfrage autorisiert hat. Nachdem die Parameter ausgewertet und überprüft wurden, wird der Browser mit einem entsprechenden Sitzungscookie versehen und zum Dienst weitergeleitet.

46 Kapitel 4 Implementierung 46 Abbildung 4.3: Flussdiagramm des Programmablaufs für die Auswertung eines QR-Codes Zusätzlich zur Möglichkeit einen QR-Code direkt mit Hilfe der Anwendung einzuscannen, kann hierfür auch eine externe Applikation wie der BarcodeScanner von ZXing [18] eingesetzt werden. In einem solchen Szenario scannt der Benutzer den QR-Code mit Hilfe des BarcodeScanners und sendet die ausgelesenen Daten dann für die weitere Verarbeitung an die Authentifizierungs-Applikation. Um die Übertragung des Inhaltes eines gescannten QR-Codes zu ermöglichen, werden die Sitzungsdaten für die Codierung in Form eines Uniform Resource Identifier (URI) [31] gebracht. Die folgende Syntax beschreibt den Inhalt eines QR-Codes, der für die Authentifizierung eingesetzt werden kann: qrtoken://qrtoken.tum.de?sid=<sitzungs-id>&ts=<zeitstempel>&url<url des Dienstes> Die URI setzt sich aus dem Schema qrtoken, dem Hostnamen qrtoken.tum.de und den Sitzungsdaten in Form von URL-Parametern zusammen. Analog wird für die Übertragung von Sitzungen das Schema qrtransfer verwendet. Im Android-Manifest der Anwendung wurden Intent-Filter definiert um alle Intents mit den

47 Kapitel 4 Implementierung 47 beschrieben Schemen zu empfangen. Hierbei wird die URI aus dem QR-Code vollständig an die Anwendung übergeben, sodass die Sitzungsdaten ausgelesen werden können. Je nach Schema wird dann, wie oben beschrieben, eine Authentifizierung oder ein Sitzungstransfer durchgeführt. Diese Lösung hat den Vorteil, dass der Benutzer seine gewohnte Scanner-App einsetzen kann. Gleichzeitig bieten die Intent-Filter eine Schnittstelle über die potentiell auch andere Applikationen Authentifizierungsprozesse einleiten können Abrufen des Benutzerprofils Der Benutzer hat die Möglichkeit seine Profildaten vom Server zu laden und direkt auf seinem Smartphone einzusehen. Dieses Profil wird durch die Applikation als XML-Datei vom Server abgerufen. Bei diesem Prozess authentifiziert der Benutzer sich, mit Hilfe seiner UUID und seines Benutzerschlüssels. Wie in Abb. 4.4 zu sehen ist, umfassen die Profildaten neben den Benutzerdaten wie Display Name und Distinguished Name auch eine Übersicht der momentan aktiven Sitzungen und der Dienste für die der Benutzer sich authentifizieren kann. Nach erhalten der XML-Datei, werden alle enthaltenen Felder ausgelesen und in geeignete Model-Dateien geladen. Anschließend werden die Zeichenketten in eine übersichtliche Darstellungsform gebracht und in einer ausklappbaren Liste angeordnet. Abbildung 4.4: Beispiel für ein Benutzerprofil in XML-Form

48 Kapitel 4 Implementierung 48 Neben der Darstellung der Profil-Informationen, ist im Rahmen der beschriebenen Activity auch eine Interaktion des Benutzers vorgesehen. Durch verlängertes Berühren eines Listeneintrags wird ein Kontextmenü geöffnet. Hier hat der Benutzer je nach Art des Eintrags folgende Möglichkeiten: Eine aktive Sitzung beenden Bei diesem Prozess wird der Benutzer wieder anhand seiner UUID und seines Schlüssels beim Server authentifiziert und übermittelt den Befehl die ungewollte Sitzung zu invalidieren. Da die Sitzung global am Server verwaltet wird, überträgt sich der Logout bei der nächsten Überprüfung an den Rechner. Eine aktive Sitzung auf das Smartphone übertragen Analog zum bereits beschriebenen Sitzungstransfer durch das Einscannen eines QR-Codes, kann eine Sitzung auch direkt auf Anfrage des Benutzers übertragen werden. Dafür werden die SID aus dem Profil entnommen und die Benutzerdaten aus dem Speicher gelesen. Anschließend wird eine entsprechende Anfrage an den SSO-Server geschickt. Eine genaue Beschreibung dieser Anfrage erfolgt in Abschnitt Nach erfolgreicher Übertragung, wird die Sitzung im Browser des Mobilgerätes gestartet und der Benutzer kann ohne weiteres Zutun auf den Dienst zugreifen. Einen Dienst im Browser aufrufen Bei diesem Vorgang wird die URL des Dienstes aus dem Profileintrag gelesen und durch einen geeigneten Intent im Standard-Browser des Smartphones aufgerufen. Zusätzlich zu den genannten Optionen, die über das Kontextmenü des Profils erreichbar sind, bietet ein Button die Möglichkeit, durch eine einzelne Aktion alle offenen Sitzungen zu schließen Authentifizierung im Browser des Mobilgerätes Neben der Authentifizierung durch das Einscannen eines QR-Codes, wurde auch eine Lösung für den vereinfachten Login im Browser des Smartphones vorgesehen. Hierbei wird ausgenutzt, dass der Standard-Browser von Android eine URI-Auflösung durchführt. Diese Funktion erlaubt es eine installierte Anwendung anzusteuern wenn eine spezielle URL im Browser geöffnet wird. Für die Umsetzung wird auf der Authentifizierungsseite ein Link bereitgestellt der den Browser veranlasst die Applikation zu starten und die Sitzungsdaten zu übermitteln. Solch eine URI hat die folgende Struktur: intent://qrtoken.tum.de/<verschlüsselte Sitzungsdaten>

49 Kapitel 4 Implementierung 49 Im Android-Manifest der Applikation wurde, wie bereits beschrieben, ein Filter definiert, der die Applikation als Ziel für alle URI-Aufrufe mit dem Schema intent:// und dem Hostnamen qrtoken.tum.de festlegt. Wenn die Anwendung durch solch einen Intent gestartet wird, wird der Pfad ausgelesen und entschlüsselt. Anschließend wird die Sitzung wie zuvor beschrieben beim Server authentifiziert. Um den Benutzer wieder zum Dienst zu leiten, wird das gleiche Verfahren eingesetzt wie beim Übernehmen einer aktiven Sitzung vom Rechner. 4.3 Generierung von QR-Token Die Generierung der QR-Codes wird in der vorgestellten Architektur durch einen eigens hierfür implementierten Dienst übernommen. Zentrale Komponente dieser Implementierung ist eine JavaServer Page (JSP) die den groben Ablauf steuert, Schnittstellen bedient und gegebenenfalls den QR-Token für den Benutzer darstellt. Wie in Kapitel 3 gezeigt, wird der Benutzer durch den abhängigen Dienst zu dem, für die Generierung der QR-Token verantwortlichen JSP weitergeleitet. Hierbei werden die URL des Dienstes und die SID der zu authentifizierenden Sitzung als URL-Parameter mitgesendet. Durch den Redirect des Benutzers zur Token-Generierung wird der, in Abbildung 4.5 gezeigte, Ablauf eingeleitet. In einem ersten Schritt werden die Cookies aus der Anfrage analysiert und auf das Vorhandensein eines gültigen Sitzungscookies untersucht. Falls eine valide Sitzung identifiziert werden kann, wird wie in Abschnitt 4.4 beschrieben, eine Sitzungsvererbung durchgeführt und der Browser des Benutzers wird ohne weitere Interaktion zum Dienst zurückgeleitet. Anderenfalls werden die SID und die URL des Dienstes aus der Anfrage gelesen. Es wird ein neuer Sitzungscookie mit der erhaltenen SID für die Serverdomäne gesetzt. Außerdem wird die Sitzung unter Zugriff auf die API des SSO-Servers registriert. Anschließend wird mit Hilfe der ZXing-Klassen (siehe Abschnitt 2.3.3) ein QR-Code erstellt. Hierbei wird eine Zeichenkette, bestehend aus der SID, der URL des Dienstes und einem aktuellen Zeitstempel, kodiert. Der erstellte QR-Token wird in den Inhalt des JSP eingebunden und für die Darstellung an den Browser des Benutzers gesendet. Das JSP enthält zusätzlich einen Eintrag der die regelmäßige Aktualisierung des Inhaltes veranlasst. Wie in Abb. 4.5 durch die Schleife rechts unten dargestellt, wird bei jeder Erneuerung überprüft ob die Sitzung noch nicht validiert wurde. Derart wird eine Authentifizierung durch den Benutzer zeitnah festgestellt und sein Browser wird automatisch wieder an den Dienst verwiesen. Neben der Authentifizierung durch das Einscannen des QR-Tokens mit einem Smartphone, wurde hier auch eine Möglichkeit implementiert eine Sitzung über eine klassische Eingabe von Benutzernamen und Passwort zu validieren. Hierbei werden die Benutzerdaten, ähnlich wie bei der Registrierung eines Benutzers am Smartphone (siehe 4.2), direkt über das LDAP-Verzeichnis geprüft. Über die in Abschnitt 4.4 beschriebene API wird ein neuer Benutzereintrag in der Datenbank angelegt und an die Sitzung gebunden. Für die Verwen-

50 Kapitel 4 Implementierung 50 Abbildung 4.5: Flussdiagramm der Generierung eines QR-Tokens dung des SSO-Verfahrens unter realistischen Bedingungen, ist es unerlässlich, dass Benutzer, die nicht über ein geeignetes Mobilgerät verfügen oder den zusätzlichen Aufwand für die Installation der mobilen Anwendung vermeiden wollen, sich über eine alternative Methode erkennbar machen können. Darüber hinaus demonstriert diese Lösung, wie weitere Authentifizierungsmethoden implementiert werden könnten. Denkbar sind etwa Verfahren die auf einem asynchronen Token oder einem TAN verfahren basieren um die Sicherheit zu erhöhen. Zusammen mit dem Token wird, wie in Abb. 4.6 gezeigt, ein zweiter QR-Code in den dargestellten Inhalt eingebunden. Dieser zusätzliche QR-Code enthält eine URL, die den

51 Kapitel 4 Implementierung 51 Benutzer direkt zum Download der benötigten Android-Anwendung, wie sie unter 4.2 beschrieben ist, führt. Abbildung 4.6: Screenshot der QR-Token-Seite Generieren von Token für die eingebettete Darstellung am Dienst Wenn die QR-Token, wie in Abschnitt beschrieben, direkt in den Webinhalt des Dienstes integriert werden, entfällt die Darstellung am Server. Stattdessen muss eine Logik implementiert werden, die es erlaubt auf Anfrage einen Token zu erstellen und als Bild zurückzugeben. Der hierfür nötige Ablauf, wie er in Abb. 4.7 gezeigt wird, ist wesentlich simpler als der für die direkte Darstellung. Diese Vereinfachung kommt daher, dass ein größerer Teil der Funktionalität vom Dienst übernommen wird. Eine Anfrage für einen eingebetteten Token wird durch die Präsenz eines zusätzlichen URL-Parameters mit dem Namen Embedded erkannt. Genau wie zuvor im Rahmen des normalen Ablaufes beschrieben, werden auch hier die SID und die URL des Dienstes aus den URL-Parametern gelesen. Anschließend wird die Sitzung am SSO-Server registriert und ein entsprechender QR-Token erstellt. Dann werden die Binärdaten der Graphik als Teil der Antwort zurückgegeben. Zusätzlich zu dem in Abb. 4.7 dargestellten Ablauf, muss an dieser Stelle eine Möglichkeit vorgesehen werden, wie ein Dienst mit eingebetteten Token den Sitzungs-Cookie des Servers überprüfen kann. Ansonsten würde eine zentrale Authentifizierung nicht für eine Verteilung von derartigen Diensten über mehrere Domänen funktionieren. Entsprechend wird ein Anfragetyp definiert, bei dem nur der Sitzungs- Cookie überprüft wird, und gegebenenfalls eine Vererbung der Sitzung durchgeführt wird.

52 Kapitel 4 Implementierung 52 Abbildung 4.7: Flussdiagramm der Generierung eines eingebetteten QR-Tokens Angepasste Darstellung für mobile Browser Über die Auswertung des Header-Feldes user-agent wird festgestellt ob eine Anfrage zur Authentifizierung vom Browser eines Smartphones stammt. In diesem Fall wird die Authentifizierung über eine alternative Seite fortgesetzt, die mit Hilfe des jquery Mobile Frameworks [32] speziell für die Darstellung an mobilen Geräten optimiert wurde. Mit jquery können unkompliziert Webinhalte mit den optischen Eigenschaften von nativen Smartphone-Applikationen erstellt werden. Wie in Abb. 4.8 zu sehen, entfällt bei der Authentifizierung über diese mobile Seite sinngemäß die übliche Darstellung der QR-Codes. Stattdessen kann der Benutzer sich über einfache Schaltflächen authentifizieren bzw. den Download der mobilen Anwendung starten.

53 Kapitel 4 Implementierung 53 Abbildung 4.8: Darstellung für die Authentifizierung im mobilen Browser 4.4 SSO-Server Der SSO-Server bildet das Backend der Architektur. Er besteht im Wesentlichen aus einem Servlet [25] und einer Datenbank. Das Servlet kann in einen beliebigen Applikations-/Webserver integriert werden um als Schnittstelle für HTTPS-Anfragen zu dienen. Eingehende Anfragen werden ausgewertet und entsprechende Interaktionen mit der Datenbank koordiniert. Die Vertraulichkeit und die Integrität bei der Kommunikation wird gewährleisten, indem nur Anfragen über SSL [20] entgegengenommen werden. Um seine Rolle, wie sie unter beschrieben wird, erfüllen zu können, muss der SSO- Server auf die, im Folgenden beschriebenen Anfrage-Typen reagieren können. Für die Übermittlung der verschiedenen Parameter werden HTTP-Header eingesetzt. Dieses Verfahren bietet sich besonders für die Entwicklung von Prototypen an, da es unkompliziert zu realisieren ist und leicht veränderten Bedingungen angepasst werden kann. Sitzungsabfrage Durch eine Sitzungsabfrage (Query) wird überprüft ob eine valide und authentisierte Session mit der gesuchten ID vorhanden ist. Dieser Anfrage-Typ erlaubt es einem abhängigen Dienst, die Sitzung eines Benutzers zu überprüfen. In Abb. 4.9 wird

54 Kapitel 4 Implementierung 54 dargestellt, welcher Ablauf beim Server durchgeführt wird um eine Sitzungsabfrage zu beantworten. Abbildung 4.9: Flussdiagramm einer Sitzungsabfrage In einem ersten Schritt werden die SID der zu prüfenden Sitzung und die URL des anfragenden Dienstes aus dem empfangenen Request entnommen. Dann wird die Datenbank nach einem passenden Eintrag durchsucht, um die Validität der Sitzung durch folgende Kriterien zu bestimmen: Existiert ein Eintrag in der Datenbank für die entsprechende SID?

55 Kapitel 4 Implementierung 55 Wurde die Sitzung in der Vergangenheit durch eine Authentifizierung validiert? Hat der Benutzer Zugangsrechte für den anfragenden Service? Ist die Sitzung nicht bereits abgelaufen? Wurde die Sitzung nicht bereits invalidiert? Falls alle genannten Kriterien zutreffen, wird dem anfragenden Dienst über die entsprechenden Header der Antwort mitgeteilt, dass die geprüfte Sitzung gültig ist. Außerdem werden die wichtigsten Informationen über die Sitzung und den zugehörigen Benutzer an den Dienst weitergeleitet. Registrierung einer Sitzung Die Registrierung einer Sitzung entspricht dem initialen Anlegen eines Sitzungs-Eintrages in der Datenbank wie er unter Abschnitt beschrieben wird. Hierbei werden die Felder für die SID, den Zeitstempel und die URL des anfragenden Dienstes mit den Werten aus der Anfrage befüllt. Da eine Sitzung zum Zeitpunkt ihrer Registrierung noch nicht authentifiziert ist, also noch keinem Benutzer zugeordnet ist, werden für die entsprechenden Einträge nur Nullwerte eingetragen. Da das Anlegen einer neuen Sitzung ein sicherheitskritischer Vorgang ist und potentiell den gesamten Authentifizierungsprozess kompromittieren kann, werden alle Anfragen zur Registrierung von Sitzungen auf ihre Herkunft hin überprüft und im Zweifelsfall abgelehnt. Authentifizierung einer Sitzung Die Schnittstelle für die Authentifizierung einer Sitzung initiiert den, in Abb gezeigten Prozess. Bei einer Anfrage, wird die Übermittlung von Sitzungs- und Benutzerinformationen in HTTP-Headern erwartet. Die Sitzungsinformationen werden in Form der selben Zeichenkette erwartet, die in einem QR-Token kodiert wird. Daraus werden in einem ersten Schritt die SID, der Zeitstempel und die URL des abhängigen Dienstes geparst. Zusätzlich werden die UUID des Benutzers, die Informationen zum benutzten Mobilgerät (siehe 4.2) und eine verschlüsselte Zeichenkette mit den Sitzungsinformationen aus den Headern der Anfrage gelesen. Mit Hilfe der erhaltenen SID und der UUID können die entsprechenden Datensätze aus der Datenbank geladen werden. Die anschließende Überprüfung der Anfrage umfasst folgende Schritte: Mit Hilfe der Datenbank wird geprüft ob die erhaltene UUID zu einem gültigen Benutzer gehört. Es wird sichergestellt, dass bereits eine Sitzung mit der übermittelten SID registriert wurde. Durch das Entschlüsseln der übermittelten Zeichenkette mit dem Benutzerschlüssel aus der Datenbank und dem anschließenden Vergleich mit der erhaltenen Klartext- Variante, wird sichergestellt, dass der Kommunikationspartner im Besitz des zugeteilten Schlüssels ist.

56 Kapitel 4 Implementierung 56 Es wird geprüft ob die vergangene Zeit seit dem Erstellen der Zeitstempel nicht über einem festgelegten Schwellwert liegt. Über die Datenbankeinträge wird festgestellt ob der Benutzer berechtigt ist um auf die übermittelte URL zuzugreifen. Je nach Bedarf können an dieser Stelle zusätzliche Eigenschaften, wie die IP des Benutzers oder die erhaltene MUID, mit Einträgen aus der Datenbank verglichen werden. Wenn die Anfrage verifiziert wurde, wird die Sitzung validiert und wieder in die Datenbank geschrieben. Die Antwort an das Mobilgerät, informiert den Benutzer über den erfolgreichen Abschluss der Authentifizierung. Abbildung 4.10: Flussdiagramm der Authentifizierung einer Sitzung

57 Kapitel 4 Implementierung 57 Registrierung eines Benutzers Die Registrierung eines Benutzers beschreibt das initiale Bekanntmachen eines Benutzers beim Server und das Erstellen eines Eintrages in der Benutzer-Tabelle der Datenbank. Wie unter gezeigt, wird die Registrierung eines Benutzers durch eine Anfrage vom Mobiltelefon eingeleitet. Für die Registrierung muss ein Benutzer lediglich seinen Benutzernamen und sein Passwort übermitteln, die anschließend mit einem LDAP-Verzeichnis abgeglichen werden. Wenn die genannten Benutzerdaten erfolgreich überprüft wurden, wird ein neuer Eintrag in der User-Tabelle der Datenbank erstellt. Hierfür wird dem Benutzer eine eindeutige Kennung (UUID) in Form einer 32 Byte langen Hexadezimalen Zeichenkette zugeordnet. Außerdem wird jedem Benutzer ein 128 Bit Schlüssel zugeteilt mit dem er sich bei zukünftigen Authentifikationen und Zugriffen auf sein Profil identifizieren kann. Entsprechend der Gruppenzugehörigkeiten des Benutzers im LDAP-Verzeichnis, werden für den neuen Benutzereintrag entsprechende auth service Verknüpfungen in der Datenbank angelegt. Diese Einträge verbinden jeweils einen Benutzer mit einem abhängigen Dienst und repräsentieren das Recht des Benutzers den genannten Dienst zu benutzen. Eine Sitzung kann im Anschluss nur authentifiziert werden wenn eine solche Verknüpfung zwischen dem authentifizierenden Benutzer und dem Dienst besteht, bei dem die Sitzung angelegt wird. Vererbung einer Sitzung Bei diesem Prozess wird eine neue Sitzung durch eine bereits aktive Sitzung authentifiziert. Hierbei werden die Rechte der vererbenden Sitzung, bzw. die des Inhabers automatisch an die erbende Sitzung übertragen. Voraussetzung hierfür ist, neben der Validität der aktiven Sitzung, dass der authentifizierende Benutzer Zugriffsrechte auf den Dienst hat, für den die neue Sitzung erstellt wurde. Das Vererben einer Sitzung wird jedes mal durchgeführt wenn mehrere Dienste verwendet werden, die sich nicht in der selben Domäne befinden. In einem solchen Szenario kommt es, wie in Abschnitt erläutert, zu der Situation, dass zwar ein gültiger Sitzungscookie für die Server-Domäne vorhanden ist, aber nicht für die des abhängigen Dienstes. Entsprechend wird eine neue Sitzung für den verwaisten Dienst erstellt und mit den Rechten der Server-Sitzung ausgestattet um eine redundante Verifizierung des Benutzers zu vermeiden Zusätzliche Schnittstellen Zusätzlich zu der vorgestellten API, die alle primär für die Authentifizierung notwendigen Funktionen anbietet, wurden Schnittstellen für die erweiterte Anbindung des Smartphones realisiert. So basieren etwa das Abrufen des Benutzerprofils und der Transfer von Sitzungen auf dem Einsatz von Webdiensten. Um diese Schnittstellen zur Verfügung zu stellen, wurden zusätzliche JSPs implementiert, die zusammen als Web-Archiv verpackt und auf dem SSO-Server verteilt werden können. Der Aufruf dieser zusätzlichen Schnittstellen erfolgt über HTTP unter Verwendung von URL-Parametern für die Übertragung von Sitzungs- und Benutzerdaten. Der Einsatz von

58 Kapitel 4 Implementierung 58 URL-Parametern bietet sich an um den besonderen Bedürfnissen der Aufrufe durch den Standard-Browser der Android-Mobilgeräte zu entsprechen. Schnittstelle für das Benutzerprofil Für den Zugriff auf das eigene Profil muss die Mobile Anwendung sich gegenüber dem Server authentifizieren. Dies wird über das Übermitteln von drei Parametern realisiert: UUID In diesem Parameter wird die eindeutige Kennung des Benutzers übermittelt. NONCE Dieser Parameter überträgt einen Zeitstempel im Unixzeit-Format 1. ENCRYPTED Enthält den, mit dem persönlichen Schlüssel des Benutzers kodierten Inhalt des Zeitstempels aus dem Parameter NONCE. Während die UUID dazu dient den Benutzer zu identifizieren, werden die anderen Werte genutzt um die Validität der Anfrage zu überprüfen. Hierfür werden erst die Informationen des Benutzers aus der Datenbank geladen. Dann wird der verschlüsselte Zeitstempel unter Verwendung des Benutzerschlüssels dechiffriert und mit dem Wert aus dem NONCE- Parameter verglichen. Wenn eine Übereinstimmung sichergestellt wurde, gilt der Zugriff als autorisiert. Bei diesem Verfahren wird ein Zeitstempel als Wert für die symmetrische Verschlüsselung benutzt um Replay-Attacken zu erschweren. Anschließend wird ein neues XML-Dokument erstellt und mit den für das Benutzerprofil relevanten Werten, wie in Abb. 4.4 gezeigt, befüllt. Dann wird die XML-Datei als Antwort an das Smartphone gesendet. Schnittstelle für den Sitzungstransfer Wie in Abb. 3.4 beschrieben, wurde eine Lösung integriert, die es erlaubt aktive Sitzungen vom Rechner an das Smartphone zu übertragen. Die Schnittstelle hierfür wird durch den Standard-Browser des Mobilgerätes aufgerufen. Bei jeder Anfrage muss eindeutig festgestellt werden, welcher Benutzer, welche Sitzung übertragen will und ob er das Recht dazu hat. Hierzu werden neben den URL-Parametern UUID, NONCE und ENCRYPTED, die auch bei der Abfrage des Profils übermittelt werden, noch zwei weitere Werte übertragen: SID Enthält die ID der zu übertragenden Sitzung. URL Übermittelt die URL des Dienstes bei dem die zu übertragende Sitzung erstellt wurde. Um die Anfrage zu authentifizieren wird die gleiche Überprüfung des verschlüsselten Zeitstempels eingesetzt wie bei der Profilabfrage. Anhand der mitgesendeten SID, kann die Sitzung eindeutig identifiziert und ihre Daten aus der Datenbank abgefragt werden. Für den Sitzungstransfer ist es wichtig, zu überprüfen ob die Anfrage auch vom Inhaber der Sitzung stammt. Wenn dies sichergestellt ist, wird wie in Abschnitt 3.4 beschrieben, ein 1 Unixzeit: Anzahl der seit dem 1. Januar :00 Uhr vergangenen Sekunden.

59 Kapitel 4 Implementierung 59 neuer Sitzungscookie gesetzt. Anschließend wird der Benutzer an den Dienst weitergeleitet der durch den Parameter URL spezifiziert wird. Schnittstelle für den mobilen Logout Um vom Smartphone aus SSO-Sitzungen ausloggen zu können, wird eine weitere Schnittstelle mit den bereits vorgestellten URL- Parametern UUID, NONCE und ENCRYPTED angesprochen. Analog zu den anderen Abläufen, wird eine Überprüfung des Benutzers durchgeführt. Anschließend werden alle aktiven Sitzungen des Benutzers invalidiert Datenbank Das Backend des SSO-Servers greift in einem hohen Ausmaße auf eine eigens implementierte relationale Datenbank zu, um die Benutzerdaten, Sitzungsinformationen und Zugriffsrechte zu verwalten. Als relationale Datenbank für den im Rahmen dieser Arbeit implementierten Prototypen, kommt MySQL [28] zum Einsatz. Für den Entwurf und die genauere Spezifikation der Datenbank wurde die Software MySQL Workbench eingesetzt. Im Folgenden wird die in Abb gezeigte Datenbankstruktur beschrieben. Dabei wird vor allem auf die eingesetzten Tabellen, die enthaltenen Variablen und deren Funktion eingegangen. Anschließend wird genauer erläutert wie der Zugriff auf die Datenbank realisiert wurde. Benutzer In der Table auth user werden alle registrierten Benutzer eingetragen. Neben der UUID und dem Distinguished Name (DN) des Benutzers enthält jeder Eintrag noch einen Parameter der dessen Gültigkeit definiert. Außerdem wird an dieser Stelle der kryptographische Schlüssel abgelegt der dem Benutzer im Rahmen der Registrierung zugeteilt wird. Sitzungen Für die Verwaltung der Sitzungsinformation enthält die Datenbank die Tabelle auth session. Jeder Eintrag definiert den Kontext einer Sitzung eindeutig. Hierzu gehört etwa eine zeitliche Begrenzung der Sitzung in Form zweier Zeitstempel ( valid from und valid to ) die respektive den Beginn und das Ende der Gültigkeit beschreiben. Der Parameter associated service uid bindet jeden Sitzungseintrag an einen Dienst aus der list service -Table. In der Abb ist dies durch die gerichtete Verbindung zwischen den beiden Tabellen und durch den Fremdschlüssel mit dem Namen fk service uid dargestellt. Darüber hinaus ist eine authentifizierte Sitzung durch die Variable im Feld user uuid eindeutig an einen Eintrag in der Benutzer-Tabelle gebunden. Darüber hinaus geben die Werte in den spalten validated und invalidated an ob die entsprechende Sitzung durch eine Authentifizierung validiert bzw. durch einen Logout oder durch den Administrator invalidiert wurde.

60 Kapitel 4 Implementierung 60 Abbildung 4.11: Übersicht der Datenbank (MySQL Workbench) Log-Einträge Für jede Sitzung können in der Tabelle auth session log beliebig viele Log-Einträge erstellt werden. Diese dienen dazu den Lebenszyklus einer Sitzung nachvollziehbar zu protokollieren. Durch den Wert im Feld session sid wird ein Eintrag an eine

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter SAML/Shibboleth Ein Vortrag von Florian Mutter Security Assertion Markup Language XML-basierter Standard für den Austausch von Authentifizierungs-, Attributs- Berechtigungsinformationen Seit 2001 von OASIS

Mehr

(c) 2014, Peter Sturm, Universität Trier

(c) 2014, Peter Sturm, Universität Trier Soziotechnische Informationssysteme 6. OAuth, OpenID und SAML Inhalte Motivation OAuth OpenID SAML 1 Grundlagen Schützenswerte Objekte Zugreifende Subjekte Authentifizierung Nachweis einer behaupteten

Mehr

Authentication im Web

Authentication im Web Authentication im Web Weiterführende Themen zu Internet- und WWW-Technologien 11.07.2011, Kai Fabian Inhalt 2 1. Begriffsabgrenzung 2. HTTP Basic Authentication (RFC 2617) 3. Single Sign-on-Techniken 3.1.

Mehr

Identity and Access Management for Complex Research Data Workflows

Identity and Access Management for Complex Research Data Workflows Identity and Access Management for Complex Research Data Workflows Richard Zahoransky, Saher Semaan, Klaus Rechert richard.zahoransky@rz.uni-freiburg.de, semaan@uni-freiburg.de, klaus.rechert@rz.uni-freiburg.de

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

Geschäftsbereich Mobile Services Was ist Android?

Geschäftsbereich Mobile Services Was ist Android? Geschäftsbereich Mobile Services Was ist Android? Hinter Hoben 149 53129 Bonn www.visionera.de Ansprechpartner: Arno Becker arno.becker@visionera.de +49 228 555 1111 +49 160 98965856 Einleitung Android

Mehr

MSP SSO. Portalübergreifendes Single Sign-on. Von MSP SSO unterstützte Standards:

MSP SSO. Portalübergreifendes Single Sign-on. Von MSP SSO unterstützte Standards: MSP SSO Portalübergreifendes Single Sign-on Für das Abwickeln von Online- Geschäftsprozessen ist es wichtig, sein Gegenüber zu kennen. Das gilt sowohl für den Kunden als auch den Betreiber des Online-

Mehr

www.eset.de Bewährt. Sicher.

www.eset.de Bewährt. Sicher. www.eset.de Bewährt. Sicher. Starke Authentifizierung zum Schutz Ihrer Netzwerkzugänge und -daten ESET Secure Authentication bietet eine starke zusätzliche Authentifizierungsmöglichkeit für Remotezugriffe

Mehr

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit SZENARIO BEISPIEL Implementation von Swiss SafeLab M.ID mit Citrix Redundanz und Skalierbarkeit Rahmeninformationen zum Fallbeispiel Das Nachfolgende Beispiel zeigt einen Aufbau von Swiss SafeLab M.ID

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

MOA-ID Hands-On Workshop

MOA-ID Hands-On Workshop MOA-ID Hands-On Workshop Architektur und Neuerungen Wien, 27.05.2014 Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz Neuerungen Datenbankbasierte

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Single Sign-On. Einführung und Überblick. Dipl-Inf. Rolf Negri. Technologie und Funktionalität. Installation und Konfiguration

Single Sign-On. Einführung und Überblick. Dipl-Inf. Rolf Negri. Technologie und Funktionalität. Installation und Konfiguration Single Sign-On Einführung und Überblick Dipl-Inf. Rolf Negri Copyright Trivadis AG 1 Agenda Einleitung Technologie und Funktionalität Installation und Konfiguration Ausblick Single Sign-On Copyright Trivadis

Mehr

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Dr. Marc Rennhard Institut für angewandte Informationstechnologie Zürcher Hochschule Winterthur marc.rennhard@zhwin.ch Angriffspunkt

Mehr

Mobile Device Management

Mobile Device Management Mobile Device Management Ein Überblick über die neue Herausforderung in der IT Mobile Device Management Seite 1 von 6 Was ist Mobile Device Management? Mobiles Arbeiten gewinnt in Unternehmen zunehmend

Mehr

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language.

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language. Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo Security Assertion Markup Language Björn Rathjens Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo 1 Einführung

Mehr

Bildungsportal-Verbund

Bildungsportal-Verbund Bildungsportal-Verbund BPVP Bildungsportal-Verbund Protokoll Kurzspezifikation Für weitere technische Details nehmen kontaktieren Sie bitte: Robert.kristoefl@bmbwk.gv.at Thomas.menzel@bmbwk.gv.at Version

Mehr

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen FAEL-Seminar Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte

Mehr

Mobile Application Development

Mobile Application Development Mobile Application Development Android: Einführung Jürg Luthiger University of Applied Sciences Northwestern Switzerland Institute for Mobile and Distributed Systems Lernziele Der/die Kursbesucher/in kann

Mehr

Mobile Security Smartphones

Mobile Security Smartphones Mobile Security Smartphones Schmelztiegel privater und geschäftlicher Aktivitäten eberhard@keyon.ch V1.1 2011 by keyon (www.keyon.ch) Über Keyon Warum Smartphones Welcher Nutzen wird vom Unternehmen erwartet?

Mehr

1. Software-Plattform Android Android. Was ist Android? Managed Code, Angepasste Java Virtual Machine

1. Software-Plattform Android Android. Was ist Android? Managed Code, Angepasste Java Virtual Machine 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel ab 2.6, aktuell 3.8 Managed Code,

Mehr

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel 2.6 Managed Code, Angepasste Java

Mehr

Anlage 3 Verfahrensbeschreibung

Anlage 3 Verfahrensbeschreibung Anlage 3 Verfahrensbeschreibung Stand September 2015 1 INHALTSVERZEICHNIS 1 EINLEITUNG... 2 2 SYSTEMVORAUSSETZUNGEN... 3 2.1 Technische Voraussetzung beim Kunden... 3 2.2 Ausstattung des Clients... 3 3

Mehr

Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick. Dr. Joachim Gerber

Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick. Dr. Joachim Gerber Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick Dr. Joachim Gerber INFORA-Kompetenzteam Informationssicherheit & Id-Management München, 14.06.2010 Agenda 1. Identität Begriff

Mehr

Internet Datasafe Sicherheitstechnische Herausforderungen

Internet Datasafe Sicherheitstechnische Herausforderungen ERFA-Tagung 14.9.2010 Internet Datasafe Sicherheitstechnische Herausforderungen Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte Wissenschaften

Mehr

Software Requirements Specification

Software Requirements Specification Software Requirements Specification Identifikation von Sehenswürdigkeiten basierend auf Bildinhalten Iterationsschritt: 3 Abgabedatum: 08.06.2010 Gruppe 37: Matthias Hochsteger 0627568 Josef Kemetmüller

Mehr

Kobil Roundtable 2013. Identity Federation. Konzepte und Einsatz

Kobil Roundtable 2013. Identity Federation. Konzepte und Einsatz Kobil Roundtable 2013 Identity Federation Konzepte und Einsatz Basel, 23. Oktober 2013 3 AD domain controller AD domain controller csi-domäne File server Exchange server Basel, 23. Oktober 2013 4 cnlab-domäne

Mehr

Benutzerhandbuch (Powered by App Security Technology)

Benutzerhandbuch (Powered by App Security Technology) m-identity Protection Demo App v 2.5 Trusted Login, Trusted Message Sign und Trusted Web View Benutzerhandbuch (Powered by App Security Technology) Inhaltsverzeichnis Anforderungen... 3 1 Inbetriebnahme...

Mehr

Google's Betriebssystem für mobile Plattformen. Vortrag von Michaela Rindt Universität Siegen

Google's Betriebssystem für mobile Plattformen. Vortrag von Michaela Rindt Universität Siegen Google's Betriebssystem für mobile Plattformen Vortrag von Michaela Rindt Universität Siegen Übersicht Einleitung Softwarearchitektur Softwareentwicklung für Android Unterschied zu anderen mobilen Plattformen

Mehr

IA&DT Sharepoint Extranet mit IA&DT Single Sign On (SSO) Authentifizierung

IA&DT Sharepoint Extranet mit IA&DT Single Sign On (SSO) Authentifizierung IA&DT Sharepoint Extranet mit IA&DT Single Sign On (SSO) Authentifizierung Inhalt SSO Account... 1 Erstkontakt mit dem System (Internet / Kundensicht)... 2 Erstkontakt mit dem System (Intranet)... 3 Funktionen

Mehr

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2)

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2) 14. URIs Uniform Resource Identifier 14-1 14. URIs Uniform Resource Identifier 14-2 Motivation Das WWW ist ein Hypermedia System. Es enthält: Resourcen (Multimedia Dokumente) Verweise (Links) zwischen

Mehr

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum Analyse der Android Plattform Andre Rein, Johannes Florian Tietje FH-Gieÿen-Friedberg Android Praktikum 28. Oktober 2010 Topics 1 Übersicht Android Plattform Application Framework Activities und Services

Mehr

Federated Identity Management

Federated Identity Management Federated Identity Management Verwendung von SAML, Liberty und XACML in einem Inter Campus Szenario d.marinescu@gmx.de 1 Fachbereich Informatik Inhalt Grundlagen Analyse Design Implementierung Demo Zusammenfassung

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

Datenhaltung für Android. Model First

Datenhaltung für Android. Model First Datenhaltung für Android Model First Frederik Götz, Johannes Tysiak 26.05.2011 Unser Ziel! 26.05.2011 Datenhaltung in Android - Model First» Frederik Götz, Johannes Tysiak 2 Agenda Android Quickstart Datenhaltung

Mehr

Univention Corporate Client. Quickstart Guide für Univention Corporate Client

Univention Corporate Client. Quickstart Guide für Univention Corporate Client Univention Corporate Client Quickstart Guide für Univention Corporate Client 2 Inhaltsverzeichnis 1. Einleitung... 4 2. Voraussetzungen... 5 3. Installation des UCS-Systems... 6 4. Inbetriebnahme des Thin

Mehr

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de Grundlagen AAI, Web-SSO, Metadaten und Föderationen Wolfgang Pempe, DFN-Verein pempe@dfn.de DFN-AAI IdP-Workshop, 24./25. Juni 2015, HS Amberg-Weiden Was ist DFN-AAI? AAI Authentifizierung Autorisierung

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

QR Code. Christina Nemecek, Jessica Machrowiak

QR Code. Christina Nemecek, Jessica Machrowiak QR Code Christina Nemecek, Jessica Machrowiak 1 Inhaltsangabe. Einführung Definition Entstehung Grundlagen Aufbau Fehlertoleranz und -erkennung Generieren des QR Codes Lesen des QR Codes Quellen 2 Einführung.

Mehr

Sicherheit in Webanwendungen CrossSite, Session und SQL

Sicherheit in Webanwendungen CrossSite, Session und SQL Sicherheit in Webanwendungen CrossSite, Session und SQL Angriffstechniken und Abwehrmaßnahmen Mario Klump Die Cross-Site -Familie Die Cross-Site-Arten Cross-Site-Scripting (CSS/XSS) Cross-Site-Request-Forgery

Mehr

Portalverbundprotokoll Version 2. S-Profil. Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG

Portalverbundprotokoll Version 2. S-Profil. Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG 1 Portalverbundprotokoll Version 2 S-Profil Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG Kurzbeschreibung Das S-Profil von PVP2 verwendet SAML WebSSO für die Authentifizierung von Benutzern mit Webbrowser.

Mehr

Das Ende der Passwort-Ära X.509 Authentifizierung die Alternative!

Das Ende der Passwort-Ära X.509 Authentifizierung die Alternative! Das Ende der Passwort-Ära X.509 Authentifizierung die Alternative! - X.509 Sicherheit für alle mobilen Geräte - Die PKI/MDM Integrationsproblematik - Ist Ihre Infrastruktur kompatibel? Juni 2013 Nicolas

Mehr

KOGIS Checkservice Benutzerhandbuch

KOGIS Checkservice Benutzerhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 KOGIS Checkservice Benutzerhandbuch Zusammenfassung Diese Dokumentation beschreibt die Bedienung des KOGIS Checkservice. 4.2.2015

Mehr

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST 2. Interaktive Web Seiten GET und POST Die Übertragungsmethoden GET und POST sind im http Protokoll definiert: POST: gibt an, dass sich weitere Daten im Körper der übertragenen Nachricht befinden: z.b.

Mehr

Installation des edu- sharing Plug- Ins für Moodle

Installation des edu- sharing Plug- Ins für Moodle Installation des edu- sharing Plug- Ins für Moodle [edu-sharing Team] [Dieses Dokument beschreibt die Installation und Konfiguration des edu-sharing Plug-Ins für das LMS Moodle.] edu- sharing / metaventis

Mehr

Database Exchange Manager. Infinqa IT Solutions GmbH, Berlin Stralauer Allee 2 10245 Berlin Tel.:+49(0) 30 2900 8639 Fax.:+49(0) 30 2900 8695

Database Exchange Manager. Infinqa IT Solutions GmbH, Berlin Stralauer Allee 2 10245 Berlin Tel.:+49(0) 30 2900 8639 Fax.:+49(0) 30 2900 8695 Database Exchange Manager Replication Service- schematische Darstellung Replication Service- allgemeines Replikation von Daten von bzw. in ein SAP-System und einer relationalen DMS-Datenbank Kombination

Mehr

vap 2006 R2 Datenbankzugriff mit Windows Integrated Security Technische Dokumenation

vap 2006 R2 Datenbankzugriff mit Windows Integrated Security Technische Dokumenation vap 2006 R2 Datenbankzugriff mit Windows Integrated Security Technische Dokumenation www.visionapp.com Inhalt 1 Einleitung... 2 2 Voraussetzungen... 2 3 Installation... 2 3.1 Infrastrukturelle Anforderungen...

Mehr

Single-Sign-On mit Java und Kerberos. Michael Wiesner, SOFTCON IT-Service GmbH

Single-Sign-On mit Java und Kerberos. Michael Wiesner, SOFTCON IT-Service GmbH Single-Sign-On mit Java und Kerberos Michael Wiesner, SOFTCON IT-Service GmbH Über mich Softwareentwickler und Sicherheitsexperte bei der Firma SOFTCON Projekte: Enterprise Software, Webportale, Sicherheitslösungen,...

Mehr

[DIA] Webinterface 2.4

[DIA] Webinterface 2.4 [DIA] Webinterface 2.4 2 Inhalt Inhalt... 2 1. Einleitung... 3 2. Konzept... 4 2.1 Vorteile und Anwendungen des... 4 2.2 Integration in bestehende Systeme und Strukturen... 4 2.3 Verfügbarkeit... 5 3.

Mehr

Hidden Automa-c Navigator your gateway to electronic resources. Markus Libiseller M.A. Technical Product Manager

Hidden Automa-c Navigator your gateway to electronic resources. Markus Libiseller M.A. Technical Product Manager Hidden Automa-c Navigator your gateway to electronic resources Markus Libiseller M.A. Technical Product Manager E- Ressourcen in modernen Bibliotheken Moderne Bibliotheken stellen nicht nur klassische,

Mehr

Wo ist mein Geld? Identitätsmissbrauch im Online-Banking. Christoph Sorge Universität des Saarlandes juris-stiftungsprofessur für Rechtsinformatik

Wo ist mein Geld? Identitätsmissbrauch im Online-Banking. Christoph Sorge Universität des Saarlandes juris-stiftungsprofessur für Rechtsinformatik Wo ist mein Geld? Identitätsmissbrauch im Online-Banking Christoph Sorge Universität des Saarlandes juris-stiftungsprofessur für Rechtsinformatik C. Sorge 2 Überblick Rechner des Kunden Server der Bank

Mehr

2 Verwalten einer Active Directory

2 Verwalten einer Active Directory Einführung 2 Verwalten einer Active Directory Infrastruktur Lernziele Active Directory und DNS Besonderheiten beim Anmeldevorgang Vertrauensstellungen Sichern von Active Directory Wiederherstellen von

Mehr

Tourismus-Infos per Augmented Reality und mobiler Website www.easytourist.at

Tourismus-Infos per Augmented Reality und mobiler Website www.easytourist.at Tourismus-Infos per Augmented Reality und mobiler Website www.easytourist.at Tourismus-Infos per Augmented Reality und mobiler Website Die Zukunft ist mobil! In Österreich geht bereits jeder Zweite mobil

Mehr

Bedienungsanleitung. roi-light

Bedienungsanleitung. roi-light Bedienungsanleitung roi-light Version 1.1 vom 15.01.2009 Valenciaplatz 6 55118 Mainz Inhaltsverzeichnis 1 Einleitung für Administratoren...3 2 Support für Administratoren...4 3 Authentifizierungsvarianten...5

Mehr

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr

Ein technischer Überblick

Ein technischer Überblick Wie funktioniert Shibboleth? Ein technischer Überblick 3. AAR-Workshop Freiburg, 10. Oktober 2006 Franck Borel, UB Freiburg E-Mail: borel@ub.uni-freiburg.de Übersicht Was ist Shibboleth? Warum Shibboleth?

Mehr

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Ein Auszug aus... Studie Content Management Systeme im Vergleich Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Die komplette Studie ist bei amazon.de käuflich zu erwerben. Inhaltsverzeichnis

Mehr

ESB - Elektronischer Service Bericht

ESB - Elektronischer Service Bericht Desk Software & Consulting GmbH ESB - Elektronischer Service Bericht Dokumentation des elektronischen Serviceberichts Matthias Hoffmann 25.04.2012 DESK Software und Consulting GmbH Im Heerfeld 2-4 35713

Mehr

Installation und Dokumentation. juris Autologon 3.1

Installation und Dokumentation. juris Autologon 3.1 Installation und Dokumentation juris Autologon 3.1 Inhaltsverzeichnis: 1. Allgemeines 3 2. Installation Einzelplatz 3 3. Installation Netzwerk 3 3.1 Konfiguration Netzwerk 3 3.1.1 Die Autologon.ini 3 3.1.2

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

Kundeninformation zu Secure E-Mail

Kundeninformation zu Secure E-Mail Kundeninformation zu Secure E-Mail Einleitung Das sogenannte Sniffen, Ausspähen von E-Mailinhalten und Authentifizierungs-dateien sowie das E-Mail Spoofing, das Erstellen einer E-Mail mit gefälschtem Absender,

Mehr

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet SEC Für ein sicheres Internet Was ist SEC? SEC ist eine Erweiterung des Domain Namen Systems (), die dazu dient, die Echtheit (Authentizität) und die Voll ständig keit (Integrität) der Daten von - Antworten

Mehr

Häufig gestellte Fragen zu Brainloop Secure Dataroom

Häufig gestellte Fragen zu Brainloop Secure Dataroom Häufig gestellte Fragen zu Brainloop Secure Dataroom Klicken Sie auf eine der Fragen unten, um die Antwort dazu anzuzeigen. 1. Ich versuche mich zu registrieren, aber erhalte keine TAN. Warum? 2. Ich kann

Mehr

Aktuelle Sicherheitsprobleme im Internet

Aktuelle Sicherheitsprobleme im Internet Herbst 2014 Aktuelle Sicherheitsprobleme im Internet Wirtschaftsinformatik: 5. Semester Dozenten: Rainer Telesko / Martin Hüsler Fachhochschule Nordwestschweiz FHNW / Rainer Telesko - Martin Hüsler 1 Inhalt

Mehr

App-Entwicklung für Android

App-Entwicklung für Android App-Entwicklung für Android Einleitung - Systemarchitektur Hochschule Darmstadt WS15/16 1 Inhalt Historie Systemarchitektur Sandbox 2 Motivation Kontra Pro Limitierte Größe Begrenzte Ressourcen Kein Standardgerät

Mehr

Zuerst: Installation auf dem Mobilgerät (des Kindes)

Zuerst: Installation auf dem Mobilgerät (des Kindes) Inhalt Willkommen... 3 Was ist der Chico Browser?... 3 Bei Android: App Kontrolle inklusive... 3 Das kann der Chico Browser nicht... 3 Zuerst: Installation auf dem Mobilgerät (des Kindes)... 4 Einstellungen

Mehr

EXAM Ein interaktives Lern- und Prüfungssystem. Whitepaper

EXAM Ein interaktives Lern- und Prüfungssystem. Whitepaper EXAM Ein interaktives Lern- und Prüfungssystem Whitepaper Inhalt A. Die Architektur von EXAM...3 Der Serverbereich...3 Der Clientbereich...3 Übersicht...4 B. Die Sicherheit in EXAM...5 Die Servertechnik...5

Mehr

Sicherheit im Mobile Computing Praxisforum "Anwender und Anbieter im Dialog - Mobile Sicherheit im Unternehmen" 4.12.2014, IHK Akademie München

Sicherheit im Mobile Computing Praxisforum Anwender und Anbieter im Dialog - Mobile Sicherheit im Unternehmen 4.12.2014, IHK Akademie München Dr. Martin Werner Sicherheit im Mobile Computing Praxisforum "Anwender und Anbieter im Dialog - Mobile Sicherheit im Unternehmen" 4.12.2014, IHK Akademie München Dr. Martin Werner Überblick Sicherheit

Mehr

Howto. Konfiguration eines Adobe Document Services

Howto. Konfiguration eines Adobe Document Services Howto Konfiguration eines Adobe Document Services (ADS) Inhaltsverzeichnis: 1 SYSTEMUMGEBUNG... 3 2 TECHNISCHE VERBINDUNGEN ZWISCHEN DEN SYSTEMEN... 3 2.1 PDF BASIERENDE FORMULARE IN DER ABAP UMGEBUNG...

Mehr

Benutzerzertifikate für Java Webstart

Benutzerzertifikate für Java Webstart Benutzerzertifikate für Java Webstart Benutzerdokumentation Wien 5. Dezember 2011 Florian Bruckner, Florian Heinisch 3kraft IT GmbH & Co KG Wasagasse 26/2 1090 Wien Österreich Tel: +43 1 920 45 49 Fax

Mehr

TimePunch SQL Server Datenbank Setup

TimePunch SQL Server Datenbank Setup TimePunch TimePunch SQL Server Datenbank Setup Benutzerhandbuch 26.11.2013 TimePunch KG, Wormser Str. 37, 68642 Bürstadt Dokumenten Information: Dokumenten-Name Benutzerhandbuch, TimePunch SQL Server Datenbank

Mehr

Endpoint Security. Where trust begins and ends. SINN GmbH Andreas Fleischmann Technischer Leiter. www.s-inn.de

Endpoint Security. Where trust begins and ends. SINN GmbH Andreas Fleischmann Technischer Leiter. www.s-inn.de Endpoint Security Where trust begins and ends SINN GmbH Andreas Fleischmann Technischer Leiter www.s-inn.de Herausforderung für die IT Wer befindet sich im Netzwerk? Welcher Benutzer? Mit welchem Gerät?

Mehr

Anleitung mtan (SMS-Authentisierung) mit SSLVPN.TG.CH

Anleitung mtan (SMS-Authentisierung) mit SSLVPN.TG.CH Amt für Informatik Anleitung mtan (SMS-Authentisierung) mit SSLVPN.TG.CH Anleitung vom 12. September 2009 Version: 1.0 Ersteller: Ressort Sicherheit Zielgruppe: Benutzer von SSLVPN.TG.CH Kurzbeschreib:

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Identity Management. Nutzen Konzepte Standards. Dr. Oliver Stiemerling

Identity Management. Nutzen Konzepte Standards. Dr. Oliver Stiemerling Identity Management Nutzen Konzepte Standards Dr. Oliver Stiemerling ecambria systems GmbH Hospeltstr. 35a 50825 Köln Tel.: 0221 595527-0 Fax.: 0221 595527-5 os@ecambria-systems.com http://www.ecambria-systems.com

Mehr

S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen

S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen Herzlichen Dank! Projektleitung S.A.F.E.: Meinhard Wöhrmann (meinhard.woehrmann@olg-duesseldorf.nrw.de)

Mehr

SBB Schulung für digitale Fahrplanabfrage und Ticketkäufe.

SBB Schulung für digitale Fahrplanabfrage und Ticketkäufe. SBB Schulung für digitale Fahrplanabfrage und Ticketkäufe. Vielen Dank, dass Sie sich für die SBB Schulung für die digitale Fahrplanabfrage und Ticketkäufe angemeldet haben. Das vorliegende Dokument erklärt

Mehr

Einrichtungsanleitung Exchange Server Synchronisation

Einrichtungsanleitung Exchange Server Synchronisation Einrichtungsanleitung Exchange Server Synchronisation www.simplimed.de Dieses Dokument erhebt keinen Anspruch auf Vollständigkeit oder Korrektheit. Seite: 2 1. Die Exchange Server Synchronisation (EXS)

Mehr

Einführung in Android. 9. Dezember 2014

Einführung in Android. 9. Dezember 2014 Einführung in Android 9. Dezember 2014 Was ist Android? Software für mobile Geräte: Betriebssystem Middleware Kernanwendungen Android SDK: Tools und APIs zur Entwicklung von Anwendungen auf der Android-Plattform

Mehr

Mobile Computing I. Tickapp Projekt. Dustin Augstein, Thomas Filbry, Eric Jahn Sommersemester 2011. Prof. Dr. Jörg Sahm

Mobile Computing I. Tickapp Projekt. Dustin Augstein, Thomas Filbry, Eric Jahn Sommersemester 2011. Prof. Dr. Jörg Sahm Mobile Computing I Tickapp Projekt Dustin Augstein, Thomas Filbry, Eric Jahn Sommersemester 2011 Prof. Dr. Jörg Sahm Inhaltsverzeichnis Abbildungsverzeichniss... 3 1. Beschreibung der Anwendung... 4 1.1

Mehr

Benutzer- und Gruppenverwaltung, Registrierung

Benutzer- und Gruppenverwaltung, Registrierung OS Content Management mit Zope/Plone Benutzer- und Gruppenverwaltung, Registrierung in Plone 4.0 Jennifer Meyer, Christopher Oehmig Inhalt 1. Benutzer- und Gruppenverwaltung a. Allgemeine Arbeitsweise

Mehr

TimeMachine. Installation und Konfiguration. Version 1.4. Stand 21.11.2013. Dokument: install.odt. Berger EDV Service Tulbeckstr.

TimeMachine. Installation und Konfiguration. Version 1.4. Stand 21.11.2013. Dokument: install.odt. Berger EDV Service Tulbeckstr. Installation und Konfiguration Version 1.4 Stand 21.11.2013 TimeMachine Dokument: install.odt Berger EDV Service Tulbeckstr. 33 80339 München Fon +49 89 13945642 Mail rb@bergertime.de Versionsangaben Autor

Mehr

Ein mobiler Electronic Program Guide für Android

Ein mobiler Electronic Program Guide für Android Whitepaper Telekommunikation Ein mobiler Electronic Program Guide für Android Prototyp für Android Apps 2011 SYRACOM AG 1 Einleitung Apps Anwendungen für mobile Geräte sind derzeit in aller Munde. Durch

Mehr

Safe & Quick Mobile Payment. SQ ist eine Authentifizierungs- und Bezahltechnologie für das mobile, bargeld- und kontaktlose Bezahlen per Smartphone

Safe & Quick Mobile Payment. SQ ist eine Authentifizierungs- und Bezahltechnologie für das mobile, bargeld- und kontaktlose Bezahlen per Smartphone Safe & Quick Mobile Payment SQ ist eine Authentifizierungs- und Bezahltechnologie für das mobile, bargeld- und kontaktlose Bezahlen per Smartphone DIE ZIELGRUPPEN SQ spricht jeden an ZAHLUNGSDIENSTLEISTER,

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

Mobile App Development. - Einführung -

Mobile App Development. - Einführung - Mobile App Development - Einführung - Inhalt Organisatorisches Vorlesungsinhalt Mobile Geräte Android Architektur App Aufbau Praktikum Organisatorisches 4 SWS, 5 ECTS 2 Vorlesung / 2 Praktikum ca. 10 Wochen

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Sind Ihre Anwendungen auf mobilen Endgeräten sicher? Karsten Sohr Technologie-Zentrum Informatik Universität Bremen

Sind Ihre Anwendungen auf mobilen Endgeräten sicher? Karsten Sohr Technologie-Zentrum Informatik Universität Bremen Sind Ihre Anwendungen auf mobilen Endgeräten sicher? Karsten Sohr Technologie-Zentrum Informatik Universität Bremen Inhalt Motivation allgemeine Bedrohungen für mobile Endgeräte bösartige Anwendungen für

Mehr

1. Integration von Liferay & Alfresco 2. Single Sign On mit CAS

1. Integration von Liferay & Alfresco 2. Single Sign On mit CAS 1. Integration von Liferay & Alfresco 2. Single Sign On mit CAS Vortrag zum 4. LUGD Tag, am 21.1.2010 form4 GmbH & Co. KG Oliver Charlet, Hajo Passon Tel.: 040.20 93 27 88-0 E-Mail: oliver.charlet@form4.de

Mehr

Kundeninformation zu Secure E-Mail

Kundeninformation zu Secure E-Mail S Stadtsparkasse Felsberg Kundeninformation zu Secure E-Mail Einleitung Das sogenannte Sniffen, Ausspähen von E-Mailinhalten und Authentifizierungsdateien sowie das E-Mail Spoofing, das Erstellen einer

Mehr

Von der Testumgebung zum produktiven Einsatz von Shibboleth

Von der Testumgebung zum produktiven Einsatz von Shibboleth Authentifizierung, Autorisierung und Rechteverwaltung Von der Testumgebung zum produktiven Einsatz von Shibboleth 3. Shibboleth-Workshop Freiburg, 10. Oktober 2006 Bernd Oberknapp, UB Freiburg E-Mail:

Mehr

Appery.io Mobile Apps schnell und einfach entwickeln

Appery.io Mobile Apps schnell und einfach entwickeln Appery.io Mobile Apps schnell und einfach entwickeln Cloud-basierte Entwicklungsumgebung, keine lokale Installation von Entwicklungsumgebung nötig. Technologie: HTML5. JQuery Mobile, Apache Cordova. Plattformen:

Mehr

KvBK: Basic Authentication, Digest Authentication, OAuth

KvBK: Basic Authentication, Digest Authentication, OAuth 14.07.2010 Julian Reisser Julian.Reisser@ce.stud.uni-erlangen.de KvBK: Basic Authentication, Digest Authentication, OAuth Motivation Authentifizierung Nachweis, dass man der ist für den man sich ausgibt

Mehr

Philosophie & Tätigkeiten. Geschäftsfelder. Software Engineering. Business Applikationen. Mobile Applikationen. Web Applikationen.

Philosophie & Tätigkeiten. Geschäftsfelder. Software Engineering. Business Applikationen. Mobile Applikationen. Web Applikationen. Philosophie & Tätigkeiten Wir sind ein Unternehmen, welches sich mit der Umsetzung kundenspezifischer Softwareprodukte und IT-Lösungen beschäftigt. Wir unterstützen unsere Kunde während des gesamten Projektprozesses,

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen RWE Effizienz GmbH Flamingoweg 1 44139 Dortmund für das IT-System RWE eoperate IT Services die Erfüllung aller

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

ProCall 5 Enterprise

ProCall 5 Enterprise ProCall 5 Enterprise Installationsanleitung Upgradeverfahren von ProCall 4+ Enterprise auf ProCall 5 Enterprise ProCall 5 Enterprise Upgrade Seite 1 von 10 Rechtliche Hinweise / Impressum Die Angaben in

Mehr

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. 7 Key Features.

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. 7 Key Features. Inhalt 1 Übersicht 2 Anwendungsbeispiele 3 Einsatzgebiete 4 Systemanforderungen 5 Lizenzierung 6 Installation 7 Key Features Seite 2 von 12 1. Übersicht MIK.arjuna ist eine 64-bit multidimensionale Datenbank,

Mehr