Alarmierungsframework Rescue Alert

Transkript

1 Alarmierungsframework Rescue Alert BACHELORARBEIT 2 durchgeführt am Bachelorstudiengang Informationstechnik & System Management Fachhochschule Salzburg GmbH vorgelegt von: Ing. Johannes Winkler Studiengangsleiter: BetreuerIn: FH-Prof. DI Dr. Gerhard Jöchtl DI (FH) Thomas Lampoltshammer MSc Salzburg, Mai 2012

2 Ing. Johannes Winkler Halleiner Landesstraße Oberalm Hiermit versichere ich, dass ich die von mir vorgelegte Arbeit selbstständig verfasst habe, dass ich die verwendeten Quellen, Internet-Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit einschließlich Tabellen, Karten und Abbildungen, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach entnommen sind, auf jeden Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht habe. Oberalm, den 5. Mai 2012 Ing. Johannes Winkler

3 Danksagung: An dieser Stelle möchte ich mich herzlich bei meinem Betreuer DI (FH) Thomas Lampoltshammer MSc bedanken, welcher mir mit Rat und Tat zur Seite gestanden ist. Weiters möchte ich mich bei der Freiwilligen Feuerwehr Oberalm, im Besondern HBI Christoph Pongratz, bedanken, welche mir die Alarmierung einer Feuerwehr näher brachte und die Infrastruktur zum Testen zur Verfügung gestellt hat. Der vorliegende Text ist auf Basis des L A TEX-Templates aus [1] erstellt. Das Originaltemplate wurde als Basis für die Erstellung einer Bachelorarbeit am Studiengang ITS angepasst. Die Erweiterungen und Anpassungen am Template als Basis für eine ITS Bachelorarbeit wurden von Karl Entacher und Simon Kranzer durchgeführt.

4 Kurzzusammenfassung Das Ziel dieser Arbeit ist, einen mobilen Alarmierungsclient zur Verfügung zu stellen. Der Grund hierfür ist, dass derzeit eine Web-basierende Alarmierungslösung verwendet wird, die zwar über einen mobilen Zugang verfügt (über SMS), dieser jedoch äußerst kompliziert zu bedienen ist. Aus diesem Grund ist die mobile Alarmierung von Einsatzkräften derzeit kaum genutzt. An dieser Stelle setzt dieses Projekt auf. Der mobile Client ist möglichst einfach und ohne Vorwissen zu bedienen. Daher fiel die Entscheidung auf eine Weboberfläche auf der die Daten administrierbar sind. Diese Weboberfläche wurde als Typo3 Plugin realisiert und kann somit in eine Typo3-basierende Website integriert werden. Die App verfügt anschließend über die Möglichkeit, die Daten über einen Webservice zu importieren. Zusätzlich wurde das Augenmerk auf die Sicherheit der Daten gelegt. So verfügt diese Lösung über div. Sicherheitsmechanismen die unter anderem das direkte Übertragen eines Passwortes verhindern und die Daten vor dem Zugriff fremder schützen. Gerade dieser Sicherheitsgedanke war einer der Schwerpunkte dieses Projektes. So wurden diverse Sicherheitskonfigurationen gewählt und auch die Hardware mit einer Verfügbarkeit von über 99.9% ausgewählt. Als Ergebnis dieses Projektes ist es nun für einen Einsatzleiter möglich, seine Mannschaft auf einfache Weise zu benachrichtigen und zu alarmieren. Abstract The main aim of this thesis was to create a generic mobile application for rescue forces. This app gives the possibility to simply alert any kind of a rescue force. The app is as simple usable as possible. To guarantee this usability, there is a website for the data administration. This website is only for the administrator who controls the whole configuration data. Another aim was to guarantee the security. Therefore some security mechanism were created. For example, the password is never transmitted in plain text and so on. The result of this project is now a intuitive application which can be used by anyone. As already mentioned, one of the important questions was, how to secure this app. Therefore a highly available server cluster with a service level agreement of 99.9% was chosen. The chosen server is virtualized and in case of emergency portable to another hardware cluster. As a result of the project, a director of operations is now able to inform and alarm his forces with a short interaction with his mobile phone.

5 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Quellcodeverzeichnis iii iv v 1 Einleitung Motivation Aufbau und Kapitelübersicht Grundlagen Webinterface PHP Javascript CMS Systeme Webservice Mobile App - Android Android Architektur und Aufbau Security unter Android Datenbanken unter Android Security SALTing MD5 im Fokus Umsetzung Genereller Aufbau der Lösung Wahl der verwendeten Technologien Mobile App Frontend Webservice Abläufe im Programm Login Prozedere - Three Way Handshake Prozess zum Update der Daten Prozess zum Auslösen eines Alarms Die Lösung im Detail Datenbankstruktur Frontend Plugin zur Anzeige der Daten in Typo Backend - Administration der Daten in Typo i

6 3.4.4 Webservice als Typo3 Plugin Rescue Alert die Applikation Zusammenfassung und Ausblick 31 Literatur 32 ii

7 Abbildungsverzeichnis 3.1 Programmaufbau Three Way Handshake Login und Update Auslösen eines Alarms Datenbankstruktur am Server Grobstruktur des Frontend-Typo3 Plugins Anzeige der Gateway Information im Frontend Anzeige der Alarmtextinformation im Frontend Anzeige der kompletten Eigenschaften eines clients im Frontend Anzeige der kompletten erfassten Daten im Backend Editieren eines Gateways Editieren eines Alarmclients Grobstruktur des REST - Webservice Grobstruktur der Android App DB Struktur der App Oberfläche der App iii

8 Tabellenverzeichnis 3.1 Technologiewahl - Mobile App Technologiewahl - Frontend Technologiewahl - Webservice iv

9 Listings 2.1 JavaScript in HTML eingebettet JavaScript in HTML referenziert Typo3 Session schreiben Typo3 Session auslesen XML Response zur GatewayInfo XML Response zum Alarmtext XML Response zur Alarmgruppe v

10 Kapitel 1 Einleitung Ziel dieser Arbeit war es, eine mobile Anwendung zur Verfügung zu stellen, welche eine Alarmierung von Einsatzkräften über das Mobiltelefon ermöglicht. Eine der Hauptanforderung war die Benutzerfreundlichkeit dieser Applikation. Aus diesem Grund wurde der mobile Client übersichtlich gestaltet und die Administration der Stammdaten kann von einer zentralen Stelle aus durch einen Administrator vorgenommen werden. 1.1 Motivation Aktuell verfügen nahezu sämtliche Feuerwehren des Landes Salzburg über einen Zugang zum Blaulicht SMS 1 Alarmierungssystem. Der Ablauf einer Alarmierung läuft im Normalfall auf folgenden Weg ab: Anrufer wählt den Notruf und informiert den Disponenten 2Disponent erfasst den Einsatz in der EDV und alarmiert die benötigten Feuerwehren Seitens der Feuerwehr werden die Funk basierenden Alarmgeber ausgelöst (Sirene, Rufempfänger) Gleichzeitig verfügt die Zentrale über eine IP Schnittstelle zum SMS Alarmgeber. Dieser löst den Alarm aus und versendet an die gewünschten Empfänger eine Alarm SMS Ein weiterer Alarmierungsablauf welcher immer häufiger vorkommt, ist jedoch auch folgender: Anrufer wählt den Notruf und informiert den Disponenten über ein Kleinschadensereignis 1 Blaulicht SMS ist eine österreichische Firma, welche sich auf die mobile Alarmierung von Einsatzkräften spezialisiert hat. 1

11 Disponent erfasst den Einsatz in der EDV und informiert den zuständigen Bereitschaftskommandanten einer Feuerwehr. Bereitschaftskommandant entscheidet den weiteren Weg und kann hier auch von seinem Handy aus einen Alarm auslösen. Um diesen Alarm auslösen zu können muss, unter Verwendung der angeführten Templates, eine SMS an eine Alarmierungsnummer versendet werden. [#] [N/F/B] [Z] Gx [Gy] [Gz] Ax [Ay] [Qx] [Tx] : Ihr Freitext Der oben beschriebene Vorgang ist zu komplex und wird in der Praxis nicht angenommen. Der in dieser Arbeit beschreibene Alternativansatz kann wie folgt beschrieben werden: Der Kommandant der betroffenen Wehr verwaltet sämtliche Clients auf dem Konfigurationsserver (Weboberfläche). Hier werden die Berechtigungen (Welche Gruppen in Zukunft auf dem Handy verfügbar sind) vergeben und die Vorlagen für den Alarmtext erfasst. Der Bereitschaftskommandant lädt sich auf seinem Smartphone die Client App herunter, installiert diese und meldet sich mit seinem Benutzer und seinem Passwort einmalig am Server an. Anschließend wird die ihm zugeordnete Konfiguration heruntergeladen. Der Bereitschaftskommandant sieht nun in der Oberfläche für jede verfügbare Gruppe eine Schaltfläche. Mit Klick auf diese folgt die Auswahlmaske der Alarmtexte. Hier kann auch ein eigener Text erfasst werden. Als letzter Schritt wird, nach doppelter Bestätigung, der Alarm über das Handy ausgelöst. 1.2 Aufbau und Kapitelübersicht Im Kapitel 2 werden die theoretischen Grundlagen, welche für dieses Projekt verwendet wurden erläutert. Hierbei wird vorallem der Sicherheitsaspekt hervorgehoben. Im Kapitel Webinterface werden neben den theoretischen Grundlagen zur serverorientierten Abarbeitung von PHP auch der Grundbegriff des Content Management System erläutert. Android ist als Plattform in aller Munde, im Kapitel 2.3 wird der theoretische Hintergrund zu Android erläutert. Neben dem Systemaufbau und der Systemarchitektur wird auch auf einige sicherheitstechnische Rafinessen des mobilen Betriebssystemes eingegangen. Im Kapitel 2.4 wird der theoretische Hintergrund zu den verwendeten Sicherheitstechnologien erläutert. Speziell bei MD5 wird auf die aktuelle Situation der, bereits gebrochenen, Hashfunktion eingegangen. Ab dem Kapitel 3 wird die praktische Umsetzung erläutert. Zu jeder gewählten Technologie existiert eine Bewertungsmatrix in der die einzelnen Faktoren zu einer objektiven Auswahl der Technologie führen. Im Kapitel 3.2 werden diese ausführlich erläutert und die einzelnen Faktoren erklärt. In 3.4 wird die genaue Implementierung der Lösung erläutert. Neben der Erklärung der Datenbankstruktur sind hier Details zu dem Webservice, dem Frontend und vorallem zur mobilen Applikation zu finden. Weiters sind auch Screenshot der fertigen Lösung angehängt. 2

12 Kapitel 2 Grundlagen In diesem Kapitel werden die theoretischen Grundlagen der verwendeten Technologien erklärt. Gerade in einem sensiblen Bereich wie der Alarmierung von Einsatzkräften spielt das Thema Sicherheit eine sehr große Rolle. Aus diesem Grund wurde im Theorieteil speziell auf dieses Thema eingegangen. Im Kapitel finden sich Konfigurationshinweise zum sicheren konfigurieren eines Webservers. Weiters wird im Kapitel speziell auf die Sicherheitsmechanismen der Android Plattform eingegangen. Neben den verschiedenen Sicherheitslayern wird her auch das generelle Konzept hinter Android erklärt. In 2.4 werden die allgemeinen Grundlagen zu MD5 und SALTing erläutert. Diese Kombination aus Hashing-Verfahren und zugehörigem Sicherheitsmechanismus birgt in der Praxis einige Gefahren. Gerade da MD5 bereits gebrochen ist, muss auf diesen Bereich besondere Rücksicht genommen werden. 2.1 Webinterface Das Webinterface dient bei diesem Projekt zum anzeigen und editieren der Stammdaten. Als Technologien wurden hier für die Anzeige im Browser HTML und Javascript verwendet. Im Hintergrund wurde das ganze mit PHP Entwickelt. Die Grundlagen zu PHP sind im Kapitel erklärt PHP PHP 1 ist eine Serverorientierte Skriptsprache und wird direkt am Server verarbeitet und ausgeführt. Da PHP direkt am Server ausgeführt wird, gibt es einige potentielle Einfallslücken in das System. Diese werden hier gesonder erläutert, sowie Gegenmaßnahmen vorgestellt. Auf sämtliche hier erwähnte Sicherheitshinweise wurden auch im Projekt Rücksicht genommen. Error Reporting Error Reporting birgt einige Gefahren, so wird in [2, Seite 3] explizit davor gewarnt, dass PHP Errors wichtige Informationen über das System anzeigen. Über diese Informationen 1 Ist ein rekursives Akronym und bedeutet Hypertext Preprocessor 3

13 kann ein möglicher Angreifer Einfallspunkte in das System oder Schwachstellen finden. Es ist daher von enormer Bedeutung, das Error Logging auf den Server-Internen Log zu beschränken beziehungsweise komplett zu deaktivieren. MD5 Hash nur mit SALT verwenden Wie im Kapitel nachzulesen ist, wurde MD5 bereits gebrochen. Dies bedeutet, dass diese Hashfunktion nicht mehr unbedingt verwendet werden sollte. In [2] emfiehlt der Autor, dass MD5 nur noch in Verwendung mit einem entsprechenden SALT 2. Hierfür kann ein Pseudozufallszahlengenerator verwendet werden. Dies birgt jedoch ebenso Risken und sollte vor der Implementation gut durchdacht werden (siehe hierzu auch 2.4.1) SQL Injection SQL Injection bezeichnet eine Angriffsart, bei der über GET oder POST Parameter das Statement verändernde Befehle eingefügt werden. In addition, the attacker knows that data is not being properly filtered (there was no application error mentioning an invalid username) nor escaped (there was a database error), and the entire WHERE clause has been exposed. Knowing the format of the WHERE clause, the attacker can now try to manipulate which records are matched by the query. From this point, the attacker has many options. One is to try to make the query match regardless of whether the access credentials are correct by providing the following username: myuser or foo = foo [2, S. 38] In diesem konkreten Beispiel wird vorgeführt, wie einfach es ist, ein SQL Statement zu manipulieren, wenn GET oder POST Parameter ungeprüft übernommen werden. Hier bieten Frameworks, wie sie zum Beispiel auch in Typo3 vorkommen, Abhilfe. Diese überprüfen die Parameter und passen sie gegebenenfalls an. Somit kann eine Manipulation des SQL- Statements nahezu ausgeschlossen werden Javascript Javascript ist, im Gegensatz zu PHP, eine Scriptsprache welche lokal am Client interpretiert und ausgeführt wird. Javascript läuft im Browser und kann die jeweilige zugehörige HTML Seite manipulieren. In [3] wird auf der Seite 10 die Funktionalität sowie der Ablauf der Client - Server Kommunikation genauestens beschrieben. Einbindung von Javascript in ein HTML Dokument Javascript kann auf mehrere Arten in ein Dokument eingebunden werden. Befehle können direkt im HTML Code eingebettet und ausgeführt werden (Siehe hierzu [3] Seite 20 bzw. Seite 29): 2 Im Kapitel wird das Verfahren genau erläutert 4

14 <body > <p> Das ist HTML </p> <script type =" text / javascript "> alert (" Hallo Welt! Das ist JavaScript."); / script > </ body > Listing 2.1: JavaScript in HTML eingebettet Bei dieser Version wird der Code zwischen den beiden Script Tags direkt ausgeführt und interpretiert. <body > <script type =" text / javascript " src =" test.js"></ script > </ body > Listing 2.2: JavaScript in HTML referenziert Bei der zweiten Methode steht der komplette JS 3 Code in einem externen File. Dieses wird zur Laufzeit geladen und interpretiert. Javascript findet im Rahmen dieses Projektes in der Visualisierung Anwendung. So ermöglicht es Javascript, eine übersichtliche und dynamische Darstellung von Elementen zu erstellen CMS Systeme Als Content bezeichnet man Inhalte aller Art. Dies können textuelle, visuelle oder auch programmatische Inhalte sein. Gerade die Verwaltung dieser ist der Aufgabenbereich des Content Managements. From a process point of view, CM is a process for collecting, managing, and publishing content. 1. Collection: You either create or acquire information from an existing source. Depending on the source, you may or may not need to convert the information to a master format (such as XML). Finally, you aggregate the information into your system by editing it, segmenting it into chunks (or components), and adding appropriate metadata. 2. Management: You create a repository that consists of database records and/or files containing content components and administrative data (data on the system s users, for example). 3. Publishing: You make the content available by extracting components out of the repository and constructing targeted publications such as Web sites, printable documents, and newsletters. The publications consist of appropriately arranged components, functionality, standard surrounding information, and navigation. 3 Abkürzung für JavaScript 5

15 [4, S. 72] Der Autor beschreibt in seinem Buch, dass der Sinn des Content Management im Sammeln, Verwalten und dem Veröffentlichen von Inhalten aller Art geht. Ein CMS System ist daher eine Umgebung, die alle diese Faktoren ermöglicht und unterstützt. Viele CMS Systeme arbeiten Webbasiert und laufen auf einem Webserver. Gerade diese Systeme ermöglichen eine comfortable Verwaltung der Inhalte. Typo3 Typo3 ist ein konkretes Contentmanagement System welches auf einem Webserver läuft und keinerlei Zusatzsoftware benötigt. Typo3 ist in PHP implementiert und läuft daher auf jeden Webserver mit PHP Unterstützung. Als Datenbank wird standardmäßig MyS- QL 4 verwendet. Ein Anwender von Typo3 benötigt für das Verwalten der Inhalte lediglich einen Webbrowser. Weitere Zusatzsoftware wird nicht benötigt. Laut [5] wird Typo3 derzeit stark weiterentwickelt und erscheint in regelmäßigen Versionen, welche zahlreiche Probleme beseitigen. Als webbasierendes System muss Typo3 jedoch auch regelmäßig gewartet werden. Neben dem Einspielen von Sicherheitsupdates sollten idealerweise auch regelmäßige Backups angefertigt werden. Als Open Source-Produkt ist Typo3 lizenzkostenfrei. Die Entwicklung wird von einer Internet Community getragen. Das komplette Typo3- Projekt finanziert sich laut [5, S. 3] über Spenden die an die Typo3 Association gehen. Die Typo3 Association ist eine gemeinnützige Organisation, welche die Entwicklung des Contentmanagement Systems managed und vorantreibt. Session Verwaltung in Typo3 Wie in der Einleitung geschrieben, wird im Theorieteil dieser Arbeit ein großes Augenmerk auf die Sicherheit dieses Projekts gelgt. Darum wird in diesem Abschnitt auch die Sessionverwaltung von Typo3 näher beleuchtet. In Typo3 ist es mit wenigen Zeilen Code möglich, auf die Sessionvariablen zuzugreifen: $data = test ; $GLOBALS [" TSFE "]-> fe_user -> setkey (" ses "," mydata ", $data ); Listing 2.3: Typo3 Session schreiben In diesem Beispiel werden in die Session mydata die Daten test geschrieben. Diese Daten können, unter Kenntniss des Sessiontitels, auch jederzeit wieder ausgelesen werden: $data = $GLOBALS [" TSFE "]-> fe_user -> getkey (" ses "," mydata "); Listing 2.4: Typo3 Session auslesen Laut [5] werden die Session Daten in Typo3 in der Tabelle fe session data2 abgespeichert. Zusätzlich wird beim Seitenaufrufer automatisch ein Cookie 5 erstellt, welches den Session Key enthält. Sollte ein Benutzer das Browserfenster schließen, verliert die Session ihre Gültigkeit und die Daten werden gelöscht. Hierdurch wird ein nachträgliches Auslesen der Daten verhindert und die Sicherheit der kompletten Applikation erhöht Ein Cookie ist eine Kurze Textinformation, die bei einem Seitenaufruf automatisch mit auf den Server übertragen wird. 6

16 2.2 Webservice Jede Web-Anwendung - jede Web Site - ist ein Service. Sie können sich dies für Anwendungen zunutze machen, wenn Sie mit dem Web arbeiten, statt gegen es und wenn Sie seine einmaligen Möglichkeiten nicht mit dicken Abstraktionssichten zuschütten.[6, S. XII] Die Autoren bringen in diesen paar Zeilen, die Grunddefinition eines Webservice auf den Punkt. Im Web ist jede Applikation, jede Website, eigentlich jede Möglichkeit für den Benutzer zu Interagieren ein Webservice. Der Webservice der in diesem Fall Anwendung findet ist nur eine Adaptierung, welche das Ergebnis für Maschinen leichter lesbar macht. REST 6 ist ein Paradigma für Webanwendungen. Im Grunde gibt es keine Norm für Rest, Rest bezeichnet nur die Idee, dass der Aufruf einer konkreten Url genau eine Seite als Ergebnis einer spezifischen Serveraktion zurückliefert. SOAP 7 Im Gegensatz zu REST, welches rein den Aufrufen und der Verwendung des HTTP Protokolls folgt, ist SOAP ein komplettes Internetprotokoll für die Kommunikation von Clients mit Webdiensten. In [6] wird SOAP als ein Umschlagformat wie HTTP, jedoch XML basiert bezeichnet. Der Autor beschreibt weiter, dass bei SOAP ein zusätzlicher XML Umschlag in die Abfrage des darüberliegenden Protokoll gegeben wird.soap ist nicht an HTTP gebunden, theoretisch wäre auch eine Verwendung unter FTP 8 bzw. SMTP 9 möglich. 2.3 Mobile App - Android Android ist ein mobiles Betriebssystem welches von Google entwickelt wurde. Laut [7] wurde Android ursprünglich nur für Mobiltelefone konzipiert. Aktuell sind Geräte aus allen Sparten verfügbar, so unter anderem im Bereich Auto-Infotainment, Home Entertainment, Tablet-Pc, und einige andere. Das erste SDK wurde am 12. November 2007 veröffentlicht. Seit diesem Zeitpunkt erscheinen täglich neue Apps am Markt und der Nutzerkreis wächst Android Architektur und Aufbau In [7] wird die Architektur von Android auf folgende Weise beschrieben: Android basiert auf einem optimierten Linux-Kernel. Dieser enthält die erforderlichen Gerätetreiber und wurde in Hinsicht auf Energieverbrauch und Speichermanagement optimiert. Auf Android laufen sämtliche Applikationsprozesse in einer virtuellen Maschine. Pro Android Anwendung wird ein eigener Betriebssystemprozess gestartet. Jeder Betriebssystem besitzt anschließend seine eigene DVM 10 in welcher die Anwendung läuft. Der Vorteil dieser Architektur liegt darin, dass jede Anwendung über ihren eigenen Speicherbereich verfügt und im Falle einer Fehlersituation keine andere Anwendung beeinflussen kann. 6 Representional Stat Transfer 7 Simple Object Access Protocol 8 File Transfer Protocol 9 Simple Mail Transfer Protocol 10 Dalvik Virtual Machine 7

17 2.3.2 Security unter Android Der wichtigste Sicherheitsaspekt unter Android ist das sogenannte Sandbox-Prinzip. Dies bedeutet, dass die Anwendungen, wie in der Einleitung beschrieben unter einer eigenen Umgebung laufen und daher folgende Eigenschaften aufweisen: 1. einen eigenen Prozess 2. einen eigenen Betriebssystem User 3. eine eigene DVM 4. einen eigenen Speicherbereich im Heap und im Dateisystem Als Berechtigungssystem wird das Linux eigene System verwendet. Bei einer Installation wird der Anwendung ein neuer Benutzer auf Betriebssystemebene zugeordnet. Wenn die Anwendung gestartet wird, läuft sie immer unter diesem User in einem eigenen Prozess. Android gewährt den Zugriff auf System und Hardwareressourcen nur nach Vergabe der entsprechenden Berechtigung. Es ist daher nicht möglich, auf das Filesystem oder die Textnachrichten zuzugreifen ohne die entsprechende Berechtigung zu besitzen. Eine Berechtigung wird vom Entwickler bei der Entwicklung vergeben und muss vom User bei der Installation bestätigt werden. Laut [7] existieren insgesamt ca. 100 verschiedene Berechtigungen. Die wichtigsten hierbei sind: 1. ACCESS FINE LOCATION Ermöglicht den Zugriff auf die aktuelle Position über das eingebaute GPS Modul. 2. ACCESS NETWORK STATE Erlaubt es, eine Liste der zur Verfügung stehenden Netzwerke abzurufen. 3. CHANGE NETWORK STATE Gibt die Berechtigung, die Verbindung zum Netzwerk zu ändern. Beispielsweise das WLAN für den Internetzugriff zu nutzen. 4. INTERNET Berechtigung zum Benutzen einer Socket-Verbindung ins Internet 5. RECEIVE SMS Ohne diese Berechtigung darf eine Anwendung keine Textnachrichten empfangen Datenbanken unter Android Android liefert bereits eine SQLite Datenbank mit. Diese ermöglicht es, Konfigurations-, sowie Benutzerdaten direkt in eine Relationale Datenbank zu speichern. Weiters können die Daten entsprechend strukturiert und dynamisch abgefragt werden. SQLite ist ein quelloffenes, relationales Datenbanksystem welches zahlreiche Standardfunktionalitäten einer Datenbank unterstützt (umfangreiche SQL-Syntax, Transaktionen, usw.). Laut [7] benötigt die Installation selbst jedoch nur ein Minumum an Speicher (max. 250 KB). 8

18 SQLite wurde unter Android so konfiguriert, dass die Daten einer Datenbank in mehreren Anwendungen gleichzeitig verwendet werden können. Dies ermöglicht, die gemeinsame Datenhaltung zwischen verschiedenen Applikationen. Ein großer Vorteil ist die oben erwähnte Optimierung, so alloziert SQLite nur den tatsächlich benötigten Speicher pro Datenbankfeld und besitzt so eine dynamische Feldlänge. 2.4 Security Gerade bei einer Anwendung die mit einem Klick über einhundert Frauen und Männer alarmieren kann ist die Sicherheit ein äußerst wichtiges Thema. Um hier die bestmögliche Sicherheit zu gewährleisten wurde ein spezielles Verfahren für die Authentifizierung verwendet. Im Kapitel wird der Loginvorgang inklusive des gewählten Verfahrens zum Schlüsselaustausch in der Praxis erklärt. Im folgenden wird auf die theoretischen Grundlagen der verwendeten Komponenten eingegangen SALTing Bruce Schneier erklärt einen SALT folgendermaßen: Das Salt ist eine Zufallssequenz, die mit dem ein Passwort konkateniert wird, bevor die Einwegfunktion darauf angewandt wird. In der Datenbank auf dem Host werden sowohl der Saltwert als auch das Ergebnis der Einwegfunktion gespeichert. Ist die Anzahl der möglichen Saltwerte groß genug, schließt dies einen Wörterbuchangriff (dictionary attack) gegen häufig benutzte Passwörter praktisch aus[8, S. 63] Im Falle der vorliegenden Anwendung ist die Sicherheit des Salted Password noch höher, da hier die Passwörter nicht mit den zugehörigen SALT Werten in einer Datenbank gespeichert werden, sondern die SALT Werte hier pro Login (siehe hierzu 3.3.1) generiert werden. Als SALT dient ein pseudo-zufälliger Wert. Pseudo Zufallszahlen als Salt In [8] berichtet Bruce Schneier, dass die meisten Zufallszahlen Generatoren alles andere als zufällig sind. Laut seinen Ausführungen sind Zufallszahlen pseudozufällig und wiederholen sich nach einer gewissen Bitfolge. Für die hier vorliegende Anwendungen sind diese Zahlen jedoch ausreichend sicher, da sie nur bedingt vorhersehbar sind und auch nur für den Zeitpunkt des Logins als Salt benötigt und benutzt werden. Diese Zahlen werden nicht dauerhaft abgespeichert. Daher ist eine Wiederholung nach X Loginversuchen auch kein Problem MD5 im Fokus MD5 11 ist eine kryptographische Hashfunktion welche einen 128 Bit Hashwert aus einer beliebigen Nachricht erzeugt. Aktuell gilt reines MD5 als nicht mehr sicher, da es mit 11 Message-Digest Algorithm 5 9

19 vertretbaren Aufwand möglich ist, verschiedene Nachrichten mit dem selben Hash zu erzeugen. Dies wird auch in [9] beschrieben. Hier erwähnt der Autor noch, dass MD5 bereits seit 2004 offiziell als gebrochen gilt. Für diese Anwendung ist die Sicherheit jedoch trotzdem ausreichend, da das Passwort vor dem Hashen zusätzlich noch mit einem pseudo-zufälligen Salt (siehe hierzu auch 2.4.1) versehen wird. Dies gewährleistet, dass eine Wörterbuchattacke nicht angewandt werden kann, da sich der zu hashende String jedes Mal in hohen Ausmaße ändert und somit in der Theorie niemals doppelt vorkommen kann. 10

20 Kapitel 3 Umsetzung In diesem Kapitel wird die Umsetzung und Verwendung der vorher genannten Technologien erläutert. Zusätzlich werden Snapshots der GUI gezeigt und die Funktionalität der gesamten Anwendung erläutert. 3.1 Genereller Aufbau der Lösung Das Programm wurde in einer klassischen Server-Client Architektur aufgebaut. Als Server steht ein Linuxserver mit installierten Debian Betriebssystem zur Verfügung. Zusätzlich ist auf diesem Server ein Apache Webserver mit PHP Plugin, sowie einer MySql Datenbank installiert. Der Server per se ist ein virtueller Server auf einem Hochleistungs-Cluster. Das komplette System wird zusätzlich durch ein Rechenzentrum überwacht und verfügt über redundante Hardware. Diese gewählte Kombination gewährt Hochverfügbarkeit. Garantiert wird seitens des Anbieters ein SLA 1 von 99.9%. Dies entspricht einer maximalen Ausfallszeit von 8.76 Stunden pro Jahr. 1 Service-Level-Agreement 11

21 Prinzipiell ist das Programm in drei Teile gegliedert: Abbildung 3.1: Programmaufbau 1. REST - Webservice Wie im Kapitel beschrieben, wurde als Webservice ein REST-Webservice gewählt. Dieser dient dazu, die Stammdaten, nach erfolgreicher Authentifizierung, aus der Datenbank zu selektieren und in ein entsprechendes Format zu transformieren. Anschließend holt sich die App über einen HTTP-GET die Daten ab. 2. Typo3-Frontend Im Kapitel wird beschrieben, warum Typo3 verwendet wurde. Die Funktionalität des Frontends ist derzeit, dass hier die Daten einer Rettungsorganisation angezeigt werden und an entsprechender Stelle mit der zugehörigen Berechtigung geändert werden können. 3. Mobile-Applikation Die Mobile Applikation ist der essentielle Teil dieses Projektes. Hier wurde der Fokus vorallem auf die einfache Bedienbarkeit gelegt. Daher wurde auch die Oberfläche benutzerfreundlich und übersichtlich gestaltet. So ist gewährleistet, dass sich der möglicherweise nicht technikaffine Einsatzleiter binnen kurzer Zeit zurecht findet. 12

22 3.2 Wahl der verwendeten Technologien Um die Wahl der Technologien möglichst effizient und objektiv zu gestalten, wurde hier die Methode der Punktevergabe gewählt. Zuerst wurden für den jeweiligen Programmteil die wichtigsten Parameter erfasst. Anschließend wurden diese Parameter mit einer Punkteskala von maximal fünf Punkten gewichtet. Jene Technologie, welche am Schluss die höchste Gewichtung hat wurde anschließend für den jeweiligen Projektpart verwendet Mobile App Bekannte Programmiersprache Die Iphone Plattform arbeitet intern mit Objectiv C, einem Objekt-orientierten C Derivat. Dieses Derivat war zum Zeitpunkt dieser Arbeit weder Gegenstand der Ausbildung, noch (mangels Testdevice) Gegenstand einer privaten Fortbildung. Aus diesen Gründen wurden hier Null Punkte vergeben. Die Windows Phone Plattform arbeitet intern mit einer abgespeckten Version des.net Frameworks. Dieses Framework ist äußerst gut dokumentiert, übersichtlich und ausreichend im Rahmen des Unterrichts behandelt worden. Auch im privaten wurde zum Zeitpunkt dieser Arbeit das.net Framework umfangreich eingesetzt. Es konnte daher mit der vollen Punktezahl bewertet werden. Die Android Plattform stellt mit Java eine Programmiersprache zur Verfügung, welche im Rahmen der Ausbildung an der FH Salzburg umfangreich gelehrt wird. Auch die verwendete Entwicklungsumgebung (Eclipse) ist bereits durch die Ausbildung an der FH Salzburg gut bekannt. Dadurch konnten hierfür vier Punkte vergeben werden. Es gab einen Punkt Abzug, da die speziellen Eigenheiten der Android API unter Java bislang noch völlig unbekannt waren. Vorhandenes Testdevice Einen wesentlichen Faktor in der Auswahl der Technologie stellte das Vorhandensein eines Testgerätes dar. Ein Android Device stand ständig und uneingeschränkt zur Verfügung und konnte daher mit der vollen Punktezahl bewertet werden. Ein Windows Testdevice dagegen stand nur begrenzt zur Verfügung, daher wurde es auch nur mit einem mittleren Wert gewichtet. Da ein IPhone extra angeschafft hätte werden müssen, schied es bei diesem Kriterium aus und wurde mit Null Punkten bewertet. Unterstützung durch Literatur Für alle drei gewählten Plattformen sind sowohl im Internet, als auch in den Printmedien ausreichend Dokumentationen zu finden. Bei diesem Punkt wurden daher alle Plattformen mit der vollen Punktezahl bewertet. Iphone Windows Phone Android Bekannte Programmiersprache Vorhandenes Testdevice Unterstützung durch Literatur Summe Tabelle 3.1: Technologiewahl - Mobile App 13

23 Conclusio Im Anschluss an die Gewichtung der einzelnen Punkte ergab sich ein sehr konkretes Bild. Android ging als klarer Sieger aus dieser Technologieauswahl hervor und wurde daher auch für die Entwicklung in diesem Projekt verwendet Frontend Bei der Wahl des Frontends war vorallem ausschlaggebend, dass ein Contentmanagement- System im Hintergrund verfügbar ist. Dies gewährleistet, dass das System auch für die Zukunft umfangreich erweiterbar ist und das auch Standard-Erweiterungen nicht selbst entwickelt werden müssen, sondern bereits vorhandene Entwicklungen der Community verwendet werden können. Vorhandenes Wissen Um bei der Entwicklung beste Qualität gewährleisten zu können, wurde der Fokus auf bereits bekannte Technologien gelegt.. Typo3 wurde zum Zeitpunkt dieser Arbeit im beruflichen Alltag des Autors verwendet und erhielt daher vier Punkte in diesem Kriterium. Joomla stellt ein kleineres CMS System dar und ist zum Zeitpunkt dieser Arbeit auch mehrmals vom Autor verwendet worden, jedoch ist der Wissenstand hier marginal geringer als bei Typo3. Um diesen Unterschied in die Bewertung einfließen zu lassen, wurden für Joomla nur drei Punkte vergeben. Wordpress war bis dato nur vom Namen her bekannt und wurde vom Autor noch nicht produktiv eingesetzt. Es wurde daher nur ein Punkt vergeben. Eigenentwicklung, eine Eigenentwicklung muss bei diesem Kriterium die höchste Punktezahl erhalten, da hier kein Framework abseits der Standardfunktionalität von PHP bekannt sein muss. Es wurden daher fünf Punkte vergeben. Unterstützendes Framework (API) Typo3 bietet ein äußerst Umfangreiches Framework an, dass sämtliche Standardbereiche der Webentwicklung abdeckt. Neben der vollen API Unterstützung für Datenbankabfragen, findet sich in Typo3 auch eine umfangreiche Userverwaltung auf welche im Code zugegriffen werden kann. Auch das Sessionhandling wird von der API unterstützt und vereinfacht. Soweit dem Autor bekannt, sind diese Punkte in Wordpress und Joomla nur marginal implementiert und wurden daher aufgrund des subjektiven Kenntnisstandes bewertet. Bei einer Eigenentwicklung muss auf die Unterstützung durch eine API vollständig verzichtet werden. Aufgrund obiger Begründung geht daher Typo3 als am meisten gewichtetes Kriterium hervor. Erweiterungen am Markt verfügbar Für Typo3 existieren aktuell über 5400 Extensions im Repository. Sämtliche Extensions im Typo3 Repository sind Open Source und können auch für kommerzielle Anwendungen verwendet werden. Auch Joomla bietet ein offizielles Repository mit frei verwendbaren Extensions an. Das 14

24 Joomla Repository enthält zum heutigen Stand über 9400 Extensions. Joomla verfügt dadurch über bedeutend mehr an frei verfügbaren Extensions. Das aktuell größte am Markt verfügbare Content Management System ist Wordpress. Wordpress bietet zum heutigen Tag über Plugins und bietet dadurch auch die größte Möglichkeit an Erweiterungen. Für eine Eigenentwicklung müssten Erweiterungen selbst implementiert werden. Diese Variante wurde daher bei diesem Kriterium mit null Punkten gewichtet. Aufgrund der oben genannten Zahlen ergibt sich daher die gewählte Gewichtung. Wordpress, als klarer führender, erhält daher den maximal Wert von fünf Punkten. Joomla erhält aufgrund der ermittelten Zahlen eine Gewichtung von vier Punkten und Typo3 bildet mit drei Punkten das Schlusslicht bei den Content Management Systemen. Hilfestellungen im Internet verfügbar Alle drei Content Management Systeme sind bereits markterprobt und zigfach eingesetzt. Durch dieses Faktum ist bereits genügend Dokumentation im Internet verfügbar. Gerade die allgemeinen Themen wie API Funktionen und allgemeine Probleme mit Extensions sind breit und ausführlich erklärt. Doch auch hier gilt wieder die Problematik mit der Eigenentwicklung. Die Dokumentation der Eigenentwicklung im Internet beschränkt sich auf allgemeine Problemstellungen. Aufgrund dieser Begründung wurden die drei CMS - Systeme mit je fünf Punkte gewichtet, die Eigenentwicklung mit null Punkten. Einfache Erweiterungen in der Zukunft Der Punkt einfache Erweiterungen in der Zukunft ist eine Kombination aus den am Markt verfügbaren Erweiterungen und der im Internet verfügbaren Dokumentation. Hier wurde festgestellt, dass sämtliche CMS Systeme in der Zukunft gut erweiterbar sind. Bei der Eigenentwicklung muss jede Funktionalität manuell entwickelt werden. Auch hier wurde die Eigenentwicklung daher mit null Punkten gewichtet. Da die CMS Systeme ideal erweiterbar sind, wurden hier alle gewählten Systeme mit fünf Punkten gewichtet. Typo3 Joomla Wordpress Eigenentwicklung Vorhandenes Wissen Unterstützendes Framework (API) Erweiterungen am Markt verfügbar Hilfestellungen im Internet Erweiterung in der Zukunft Summe Tabelle 3.2: Technologiewahl - Frontend Conclusio Typo3 erfüllt aufgrund der oben ausführlich erklärten Faktoren sämtliche Anforderungen. Weiters geht Typo3 aus der Technologiewahl mit einem Abstand von drei Punkten als Sieger aus der Auswahl hervor. Aus diesem Grund wurde Typo3 für die Visualisierung des Frontends verwendet. 15

25 3.2.3 Webservice Der Webservice ist eine essentielle Komponente dieser Lösung. Er versorgt den mobilen Client mit den Stammdaten die für eine Alarmierung benötigt werden. Verwendbarkeit mit dem mobilen Client Android per se verfügt über keinen SOAP Client. Dieser müsste manuell entwickelt werden. Dies ist zwar möglich, würde jedoch einen erheblichen Mehraufwand bedeuten. REST hingegen kann über einen einfachen GET-Call abgerufen werden. Für den GET-Call gibt es in Android eigene Funktionen welche diesen Aufruf auf wenige Zeilen Code beschränken. Vorhandenes wissen REST war zum Zeitpunkt dieser Arbeit bereits in den Grundzügen bekannt. Bei SOAP jedoch nur die theoretische Grundlage. Aus diesem Grund wurden hier drei Punkte für REST bzw. Zwei Punkte für SOAP vergeben. REST SOAP Verwendbarkeit mit dem mobilen Client 5 2 Vorhandenes Wissen 3 2 Summe 8 4 Tabelle 3.3: Technologiewahl - Webservice Conclusio Mit acht Punkten gilt hier REST als Technologie der Wahl. Aufgrund der oben beschriebenen Faktoren wurde diese Technologie dann auch für die Implementierung gewählt. REST bietet zusätzlich umfangreiche Erweiterungsmöglichkeiten für die Zukunft. Dadurch, dass REST per HTTP-GET aufgerufen werden kann, kann der Webservice von jeder Technologie, welche das HTTP-Protokoll unterstützt, benutzt werden. 16

26 3.3 Abläufe im Programm In diesem Kapitel werden die kompletten Abläufe im Programm erläutert. Neben den einzelnen Programmteilen ist auch der Zusammenhang und die zeitliche Abfolge erläutert. Auch die jeweiligen Entscheidungspfade sind in diversen Grafiken näher erläutert Login Prozedere - Three Way Handshake Aufgrund von sicherheitstechnischen Aspekten wurde bei dieser Arbeit auf die Übertragung des Passwortes über einen unsicheren Kanal verzichtet. Bei Dieser Lösung wurde ein sogenannter Three Way Handshake verwendet. Abbildung 3.2: Three Way Handshake Zuerst verbindet sich der mobile Client mit dem Server und ruft die Funktion generatelogincode() auf. In dieser Funktion wird mittels des PHP Zufallsgenerators eine Zufallszahl 17

27 zwischen 0xFFFF und 0xFFFFFF generiert. Diese Zufallszahl wird anschließend Serverseitig in der Session abgespeichert und an den Client übertragen. Der Client konkatiert die erhaltene Zufallszahl mit dem lokal gespeicherten Passwort und bildet aus dem eben erhaltenen String einen MD5 Hash. Dieser Hash wird anschießend an den Server übetragen. Weiters wird der Benutzername zur Identifikation übertragen. Am Server wird zum empfangenen Benutzername das zugehörige Passwort aus der Datenbank selektiert. Dieser Wert wird ebenfalls (wie am mobilen Client) mit dem, in der Session gespeicherten, Zufallscode konkatiert. Im Anschluss daran wird auch hier ein MD5 Hash aus dem erhaltenen String gebildet. Abschließend werden die beiden Hashes verglichen. Bei Gleichheit wird in der Session der Client als eingeloggt markiert und eine positive Antwort wird an den Client übermittelt. Sollten die übermittelten Hashes nicht gleich sein, wird eine negative Antwort an den Client übermittelt und die bisher gespeicherten Daten werden gelöscht Prozess zum Update der Daten Nach einem erfolgreichen Login ruft die mobile App sämtliche Daten vom Server ab. Die Konfiguration wird in einer XML Struktur übertragen. Jede Struktur ist eigenständig und kann somit auch einzeln vom Server abgerufen werden. Jedoch werden sämtliche erhaltenen Daten am Client in einer Datenbank abgelegt und sind somit ständig, auch offline verfügbar. Abbildung 3.3: Login und Update Im folgenden werden die einzelnen Daten sowie ihre Verwendung erläutert. 18

28 Gateway Info Die Gateway Info enthält die Informationen über den zu verwendenden SMS Gateway. An ihn werden später die Alarmierungsnachrichten übermittelt. < gatewayinfo > < gatewaytitle > Blaulichtsms </ gatewaytitle > < gatewaycontent > </ gatewaycontent > </ gatewayinfo > Listing 3.1: XML Response zur GatewayInfo Wie im Listing 3.1 zu sehen ist, enthält eine GatewayInfo neben der Gateway Nummer auch einen Titel zur besseren Identifikation. Alarmtext Der Alarmtext ist jener Text, der bei der Alarmierung an die zu alarmierenden Personen übermittelt wird. Dieser wird mit der im Listing 3.2 gezeigten XML Struktur an den Client übertragen. < alerttext > < alerttext_title > VU </ alerttext_title > < ale rttext_conte nt > Verkehrsunfall, sofort einrücken </ ale rttext_conte nt > </ alerttext > Listing 3.2: XML Response zum Alarmtext Auch der Alarmierungstext enthält einen Titel, dieser ermöglicht in der mobilen Applikation eine bessere Identifikation. Weiters wird auch der Inhalt übertragen. Bei einer Alarmierung wird nur der Inhalt des Alarmtextes übertragen, nicht jedoch der Titel. Alarmgruppe Die Alarmgruppe ist die Zielgruppe, welche die Alarmierung erhalten soll. Hier ist eine granulare Aufteilung in Personengruppen nach ihrer Funktion möglich. So kann zum Beispiel eine Gruppe für technische Einsätze oder eine Gruppe für Brandeinsätze vorhanden sein. Im Listing 3.3 ist die XML Struktur einer Alarmgruppe, wie sie beim updaten der Daten verwendet wird, zu sehen. < alarmgroup > <title >Test </ title > < smsidentifier ># G8A0: </ smsidentifier > </ alarmgroup > Listing 3.3: XML Response zur Alarmgruppe Wie bei den anderen beiden Datenstrukturen zuvor, enthält auch die Alarmgruppe einen Titel, der eine Identifikation ermöglicht. Zusätzlich wird hier der Code übertragen, welcher die Alarmierung am Gateway auslöst. Dieser Code wird vor die eigentliche Nachricht gesetzt und übermittelt dem Gateway alle benötigten Meta Informationen für die Alarmierung. 19

29 3.3.3 Prozess zum Auslösen eines Alarms Das Auslösen eines Alarmes will gut überlegt sein, darum wurde hier ein ausführlicher Prozess mit Sicherheitsabfragen definiert. Dieser verhindert ein ungewolltes Auslösen eines Alarms. Abbildung 3.4: Auslösen eines Alarms Die mobile App ist im Gesamten so aufgebaut, dass dieser Prozess bei der Verwendung intuitiv anklang findet. Zuerst muss eine Alarmgruppe ausgewählt werden. Anschließend wird überprüft ob der gewünschte Alarmtext bereits vorhanden ist. Sollte er vorhanden sein, so kann er nun ausgewählt werden. Sollte er nicht vorhanden sein, so kann er nun als neuer Alarmtext erfasst und anschließend für die Alarmierung ausgewählt werden. Nach der Auswahl dieser beiden Parameter kann der Alarm ausgelöst werden. Damit die Alarmierungsanweisung jedoch tatsächlich gesendet wird, muss noch eine letzte Sicherheitsabfrage beantwortet werden. Diese letzte Maßnahme verhindert ein ungewolltes Auslösen. 20

30 3.4 Die Lösung im Detail In den folgenden Kapiteln werden die genauen Implementierungsdetails erläutert. Neben den Datenbankstrukturen und der jeweiligen zugehörigen Erläuterung wurde auch auf die übersichtliche Darstellung der Applikation wert gelegt. So sind auch mehrere Illustrationen der Oberfläche vorhanden, welche das Handling und den Umgang mit der implementierten Lösung zeigen Datenbankstruktur Im Diagramm 3.5 ist die Datenbankstruktur am Server beschrieben. Die Tabelle fe user ist eine Typo3 - Systemtabelle und enthält sämtliche userspezifischen Daten. Die Entität im gezeigten Programm ist nur marginal ausgefüllt und dient als Platzhalter für die korrekte Systemtabelle. In der systemeigenen Datenbank wird jedoch nur die UserId benötigt. Abbildung 3.5: Datenbankstruktur am Server Das Typo3 Framework liefert über API Funktionen immer die UID des gerade eingeloggten Benutzers. Die Präfix tx rescuealert spezifiziert in Typo3 den Namen des Plugins, durch welches diese Tabellen erstellt wurden. Dies dient der besseren Übersichtlichkeit und wurde daher in das DB Modell übernommen. 21

31 In den folgenden Diagrammen wird diese DB Struktur als Typo3-DB stilisiert und nicht näher erläutert. Die Tabellen tx rescuealert Group, tx rescuealert Alerttext, tx rescuealert Gatewayinfo enthalten jene Informationen, die bereits im Kapitel erläutert wurden. Sämtliche in diesem Kapitel gezeigten Informationen sind in diesen equivalänten Tabellen vorhanden. Neu ist einzig die Tabelle Client. Diese Tabelle repräsentiert einen Mobilen Client. Passwort und Benutzername dienen zur Authentifizierung (das genaue Login Prozedere wurde im Kapitel erläutert) Frontend Plugin zur Anzeige der Daten in Typo3 Die das Frontend Plugin wurde in drei Teilbereiche unterteilt. Jeder Teilbereich repräsentiert eigenen Code, ein eigenes Template und ein eigenes Frontend Plugin in Typo3. Das Frontend dient in der aktuellen Ausbaustufe einzig zum Anzeigen der Daten. Die jeweilige Rettungsorganisation kann hier Ihre Daten überprüfen. Gewartet werden die Daten derzeit über das Typo3 Backend. In einer späteren Ausbaustufe wird das Frontend volle Administrierbarkeit bieten, damit jede Organisation die Daten selbstständig verwalten kann. Der Login wurde mittels der Typo3 eigenen Login Komponente realisiert. Da dies Bestandteil von Typo3 ist, wird in dieser Arbeit nicht näher auf diese Komponente eingegangen. Weiters wird im folgenden nur auf die Nicht Typo3 spezifischen Inhalte eingegangen, da diese eigens entwickelt wurden und nicht in diversen Typo3 Handbüchern eingesehen werden können. Abbildung 3.6: Grobstruktur des Frontend-Typo3 Plugins 22

32 Anzeige der Gateway Info In einer übersichtlichen Textbox kann sofort nach dem Login, die Nummer des Gateways überprüft werden. Hier ist bereits für ein späteres Stadium, in dem die Daten direkt im Frontend geändert werden können, das Formular im Hintergrund vorbereitet. Abbildung 3.7: Anzeige der Gateway Information im Frontend Anzeige Alarmtextinformationen In einem Akkordion werden sämtliche, dem Benutzer zugeordnete, Alarmtexte mit Titel angezeigt. Der Frontend User kann durch einen Klick auf den Titel des jeweiligen Textes die Details anzeigen. Abbildung 3.8: Anzeige der Alarmtextinformation im Frontend 23

33 Anzeige Clientinformationen Die Clientinformation stellt eine Zusammenfassung aller bisher gezeigten Daten, ergänzt mit dem mobilen Client dar. Hier kann der Administrator einer Rettungsorganisation sofort sehen, welche Informationen zu welchen mobilen Clients hinterlegt sind. Auch hier wurde zur einfachen Anzeige eine Akkordion - Ansicht gewählt. Mit einem Klick auf den jeweiligen Titel des Clients kann die Information aktiviert werden. Abbildung 3.9: Anzeige der kompletten Eigenschaften eines clients im Frontend In einem späteren Ausbauschritt, erhält der Administrator hier zusätzlich die Möglichkeit, seine Daten zu ändern. Aktuell werden hier neben den eigentlichen Benutzerdaten (Benutzername, Passwort), die zugeordneten Alarmtexte und Gruppen angezeigt. Bei den Alarmtexten ist eine reine Anzeige des Titels ausreichend, da die zusätzliche Information (Alarmierungscode) die Anzeige nur unübersichtlich machen würde. Bei den Alarmtexten hingegen ist neben dem Titel, welcher die Nachricht später in der mobilen Applikation identifiziert, auch der konkrete Inhalt, welcher als Alarmtext versendet wird, angezeigt. 24

34 3.4.3 Backend - Administration der Daten in Typo3 Da die komplette Datenbankstruktur Typo3-konform aufgebaut wurde, bietet Typo3 im Backend automatisch generierte Formulare zur Administration der Daten an. Diese Formulare sind für den Administrator zugänglich. Im folgenden Text wird auf die einzelnen Komponenten näher eingegangen und das Handling mit Typo3-Elementen beschrieben. Übersicht über alle Informationen Abbildung 3.10: Anzeige der kompletten erfassten Daten im Backend Typo3 gruppiert die Daten nach den DB Tabellen die im Hintergrund stehen. Im Backend ist anschließend für den jeweiligen Administrator eine Auflistung der kompletten Daten verfügbar. Hier können auch einzelne Datensätze bearbeitet werden. Im Folgenden werden nur jene Formulare erwähnt, in denen neue Datentypen und differente Eingabe Verwendung finden. Als Beispiel sei hier die Administration eines Gateways und eines Alarmtextes erwähnt. Beide verfügen über einen Titel und ein Detaileingabefeld. Zusätzlich verfügen beide über eine Zuordnung zu einem konkreten Frontend-Benutzer. Aus diesem Grund wird hier nur die Administration eines Gateways angezeigt. 25

35 Administration eines Gateways Je nach Datentyp in der Datenbank bietet Typo3 in den generierten Formularen die richtigen Eingabefelder und Validierungen an. In diesem Bild is zu sehen, dass bei einfachen Daten (Text, Nummer) eine Textbox verwendung findet. Bei 1:1 Datenbank-Relation ist in diesem Fall eine Selectorbox gewählt worden. Diese Selectorbox zeigt alle verfügbaren Frontend-Benutzer an. Anschließend wird jedoch nur die ID des Datensatzes abgespeichert. Das Mapping wird hier vom Typo3 Framework erledigt. Abbildung 3.11: Editieren eines Gateways Administration eines Clients Auch der Client ist mit einem User verknüpft. In diesem Formular sieht man auch die zwei differenten Anzeigemöglichkeiten von m:n Beziehungen in Typo3. Typo3 ermöglicht es, Informationen in virtuelle Ordner zu Gliedern. Alarmtexte könnten daher theoretisch in differente Ordner gegliedert werden. Aus diesem Grund wurde hier die Eingabemöglichkeit mittels Folder Dialog gewählt. Im Gegensatz dazu sollten die Alarmgruppen Global einzigartig sein. Daher wurde hier ein globales Selectorobjekt verwendet. Dies ermöglicht ein einfaches und übersichtliches Selektieren der gewünschten Gruppen. Abbildung 3.12: Editieren eines Alarmclients 26

36 3.4.4 Webservice als Typo3 Plugin Da Typo3 bereits einiges an API-Unterstützung bietet (Content-Management, Daten des eingeloggten Users, Datenbankzugriffe,...) wurde auch der Webservice als Typo3-Plugin gestaltet. Der Webservice dient als zentrale Schnittstelle zwischen dem mobilen Client und seinen Daten in der Serverdatenbank. Nach einem erfolgreichen Login (siehe hierzu Kapitel 3.3.1) können vom Client diverse Methoden aufgerufen werden, die die Daten aus der Datenbank selektieren und als XML Struktur zurückgeben (die genauen Daten und deren Struktur sind im Kapitel erläutert). Abbildung 3.13: Grobstruktur des REST - Webservice Der Aufbau gliedert sich in vier Teile: 1. Das Webservice Interface Entspricht der Main Methode. Hier werden alle Anfragen mit den entsprechenden Parametern geparst und an die Main-Logic delegiert. 2. Die Main-Logic Enthält die jeweiligen Methoden zur Abarbeitung einer konkreten Anfrage. Die Main- Logic bedient sich der beiden Hilfsparser um Anfragen abzuarbeiten und entsprechend formatiert wieder zurückzugeben. In diesem Teil findet auch das Session- Handling und der Datenbankzugriff statt. 3. Der Get-Parser Der Get-Parser ist eine Hilfsmethode welche die GET Parameter einer Anfrage entsprechend splittet und die jeweiligen Übergabeparameter herausfiltert. 4. Der XML-Parser Der XML-Parser konvertiert die ermittelten Werte in eine entsprechend, vom Client zu verarbeitende, XML-Struktur. 27

37 3.4.5 Rescue Alert die Applikation Abbildung 3.14: Grobstruktur der Android App Die App ist in mehrere Bereiche aufgeteilt. 1. Externe Schnittstellen Die App verfügt über zwei externe Schnittstellen, eine um den REST Server zu kontaktieren und so die benötigten Konfigurationsdaten auszulsen, eine Zweite um die Alarm SMS an die gewünschten Personen zu verschicken. Bei dem Server handelt es sich um jenen REST-Server, der bereits im Kapitel erläutert wurde. Der SMS- Gateway ist ein externer Provider, welcher die codierte SMS, die vom Client generiert wird, decodiert und entsprechend broadcastet. 2. SQLite-DB Die Datenbank ist der zentrale Speicher sämtlicher Daten der Applikation. In ihr sind Konfigurations und Arbeitsdaten gespeichert. Eine nähere Erklärung des Designs und der Daten ist folgenden Abschnitt zu finden. 3. DB-, Rest-, Client-Helper Die grünen Teile stellen Hilfsklassen im Programm dar, die die Logik enthalten, den Alarmablauf gewährleisten und durchführen, mit dem Server interagieren und das Datenhandling in Zusammenarbeit mit der DB gewährleisten. 4. Die Oberfläche Die Oberfläche ist in zwei Hauptfenster (Main Panel, Edit AlertTexts) und diverse Dialoge geteilt (Edit Userdata, edit Special Alert Text) im folgenden Text werden nur die wichtigsten erläutert und dargestellt. 28

38 DB Struktur Die Datenbank in Rescue Alert dient rein zum Abspeichern der Konfigurations- und Einsatzdaten. Daher sind in den oben beschriebenen Tabellen auch keine Constraints und Relationen vorhanden. Beim DB Design auf der App wurde vorallem Wert auf eine schlichte, kleine und somit auch sehr schnelle Datenbank gelegt. Das Resultat sind die oben zu sehenden vier Tabellen, die nur die notwendigsten und wirklich benötigten Informationen enthalten. Abbildung 3.15: DB Struktur der App Main Panel Das Main Panel dient als zentrale Oberfläche der App. Hier findet die Interaktion des Benutzers zum Alarmieren statt. Im oberen Bereich kann über eine Selectbox die zu alarmierende Gruppe gewählt werden. Hier sind sämtliche Gruppen, die beim Synchronisierungsvorgang (siehe 3.3.2) übertragen wurden vorhanden. Abbildung 3.16: Oberfläche der App Weiters kann eine Alarmtext gewählt werden. Sollte kein gewünschter Alarmtext hinterlegt sein, so kann mit dem Button Alarmtexte bearbeiten der Dialog zum einpflegen neuer Alarmtexte und editieren bereits vorhandener geöffnet werden. 29