MOCCA. Installation und Konfiguration der Online-BKU

Transkript

1 Telefon: ++43 (316) Fax: ++43 (316) Inffeldgasse 16a / 8010 Graz / Austria MOCCA Installation und Konfiguration der Online-BKU Change History V wbauer First Version

2 1 Einleitung In diesem Dokument wird die Installation und Konfiguration von MOCCA in der Ausprägung als Online-BKU beschrieben. Die zwei anderen Varianten (als Server oder als lokal installierte BKU) werden hier nicht adressiert. Daher ist in diesem Dokument MOCCA als Synonym für die online BKU, bestehend aus Server und Applet, zu verstehen. In den folgenden Abschnitten wird davon ausgegangen, dass der Leser mit der prinzipiellen Funktionsweise von MOCCA und dem Deploymentprozess von Java Webanwendungen unter Tomcat vertraut ist. Darüberhinaus gehen wir davon aus, dass MOCCA als fertig compiliertes und gepacktes war File vom Server heruntergeladen wurde. Wie sie MOCCA selbst compilieren ist in (1) beschrieben. 1.1 Voraussetzungen Entwickelt und getestet ist MOCCA in folgender Umgebung: Java 1.6.0_07 Apache Tomcat Um das Anzeigeformat XHTML entsprechend der Spezifikation zu validieren, benötigt MOCCA den XML Parser Xerces in der Version Diese Abhängigkeit befindet sich zwar, wie alle anderen, im Verzeichnis WEB-INF/lib, jedoch muss es mit den endorsed Mechanismen eingebunden werden (siehe dazu auch (2)). Daher empfiehlt es sich das File xercesimpl jar in ein eigenes Verzeichnis zu verschieben und dieses über ein System Property (java.endorsed.dirs) bekanntzugeben. Das vom Server heruntergeladene war File kann standardmäßig deployed werden. MOCCA stellt keine Anforderungen an den tatsächlich verwendeten Kontext. 2 Konfiguration Die Serverkomponente verwendet das Spring Framework zur dependency injection. Es wurde jedoch versucht, diese Abhängigkeit möglichst gering zu halten. Aus diesem Grund erfolgt die Konfiguration des MOCCA Servers über ein Java Property File. Dieses Property File wird jedoch im Spring Application Context referenziert. Dies wird in den folgenden Abschnitten konkret beschrieben. 2.1 Bekanntgabe des Konfigurationsfiles Das Konfigurationsfile wird über das File WEB-INF/applicationContext.xml referenziert. Konkret befindet sich dort folgende Bean Definition: <bean id="configurator" class="at.gv.egiz.bku.online.conf.springconfigurator" init-method="configure" scope="singleton"> <property name="resource" value="classpath:at/gv/egiz/bku/online/conf/defaultconf.properties"/> <property name="certvalidator" ref="certvalidator"></property> </bean> Relevant ist hier das value Attribut, das auf das Property File referenziert. Das Prefix classpath: gibt an, dass versucht wird das File über den Classloader zu laden. Alternativ, kann auch das Prefix file: verwendet werden, um direkt eine File zu referenzieren. 2

3 2.2 Konfiguration Die Konfiguration von MOCCA ist relativ einfach und fast selbsterklärend Konfiguration des Zugriffsschutzes MOCCA ist entsprechend den spezifizierten Zugriffsschutzmechanismen, konfiguriert. In der Online Variante ist dieser Schutz jedoch zweistufig zu sehen. 1. Schutzmechanismen des Applets: Das Applet stellt sicher, dass es die Stammzahl nur an einen MOCCA Server aus der gv.at Domäne (bzw. an einen Server der sich mit einem Zertifikat, das die geforderte Verwaltungseigenschaft aufweist) übermittelt. An diesem Mechanismus kann nichts konfiguriert werden. 2. Schutzmechanismus des MOCCA Servers: hier greifen die Schutzmechanismen, wie sie spezifiziert sind. Diese können auch konfiguriert werden, wie in weiterer Folge gezeigt wird. Das folgende Fragment zeigt den, für den Zugriffsschutz relevanten, Abschnitt aus dem MOCCA Konfigurationsfile. AccessController.acceptUnmatched=false AccessController.policyResource=classpath:at/gv/egiz/bku/online/conf/accessContro lconfig.xml Das erste Property definiert das Standardverhalten. Dies kommt zur Anwendung, wenn keine der definierten Regel zur Anwendung kommt. Ist das Property auf false gesetzt, werden Befehle ohne entsprechendem Regeleintrag verhindert. Es wird empfohlen den voreingestellten Wert (false) nicht zu verändern. Das zweite Property definiert die Regeln der Zugriffskontrolle. Die Zugriffsregeln sind in einem einfachen XML File definiert. Dieses File ist wieder als Resource referenziert (das classpath: Präfix hat die gleiche Bedeutung wie in Abschnitt 2.1 beschrieben und kann auch wiederum durch file: ersetzt werden). Bei der Regeldefinition (XML File) gibt es 2 fix definierte Chain Definitionen, die InputChain und die OutputChain. Die Inputchain definiert die Zugriffsregeln die vor der Befehlsabarbeitung angewendet werden, sind also für Befehle relevant deren Ausführung schützenswert ist (z.b. Schreiben einer Infobox). Da MOCCA keinen dieser Befehle unterstütz sind hier keine Einschränkungen getroffen. Die OutputChain definiert Regeln für Befehle deren Antwort schützenswert ist. Hier ist das Konzept der Spezifikation übernommen und man kann entsprechende Authentifizierungsklassen und Filterketten spezifizieren. Die definierten UserInteraction Elemente sind hier ohne Auswirkung SSL Konfiguration Für die Kommunikation mit anderen Servern (das ist notwendig, wenn in der Securitylayeranfrage eine Dataurl angegeben ist) kann man das SSL Verhalten konfigurieren. Die dabei relevanten Properties im Konfigurationsfile sind: SSL.caDirectory=classpath:at/gv/egiz/bku/online/conf/certs/CACerts SSL.certDirectory=classpath:at/gv/egiz/bku/online/conf/certs/certStore SSL.sslProtocol=TLS # warning do not set the following property to true # its intended for debugging and testing only SSL.disableAllChecks=false Über das erste Property (SSL.caDirectory) kann man definieren, wo die vertrauenswürdigen CA Zertifikate liegen. Dabei muss ein Verzeichnis spezifiziert werden, in dem die CA Zertifikate DER kodiert liegen. ACHTUNG: werden neue vertrauenswürdige CA Zertifikate hinzugefügt müssen die auch im certdirectory, wie im Nächsten Absatz beschrieben, eingefügt werden. 3

4 Über das Property SSL.certDirectory kann man Zertifikate hinzufügen, die für die Zertifikatskettenbildung verwendet werden. Die ist vor allem dann wichtig, wenn ein SSL Server, entgegen der Spezifikation, nicht die Zertifikate aller Zwischenzertifizierungsstellen, mitschickt. Über dieses Property wird ein Verzeichnis referenziert, das einen effizienten Zugriff auf Zertifikate gestattet. Anders als beim cadirectory können neue Zertifikate nicht einfach in das Verzeichnis kopiert werden, sondern müssen im Unterverzeichnis tobeadded abgelegt werden. Beim nächsten Start, werden dann diese Zertifikate automatische einsortiert und aus dem Verzeichnis gelöscht. Das Property SSL.sslProtocol definiert die tatsächlich verwendeten Protokollvarianten (siehe dazu Das letzte Property SSL.disableAllChecks schaltet alle SSL Überprüfungen ab und dient ausschließlich zu Entwicklungszwecken. Es darf KEINENFALLS IN PRODUKTIVSYSTEMEN auf true gesetzt werden Andere Konfigurationen Die letzten relevanten Properties sind: ValidateHashDataInputs=true AppletTimeout= Mit ValidateHashDataInputs kann man die Überprüfung des Anzeigeformates steuern. Dieser Wert sollte immer auf true bleiben. Dadurch ist sichergestellt, dass die Signaturdaten dem spezifizierten Anzeigeformat entsprechen. Über das Property AppletTimeout kann definiert werden, wie lange der MOCCA Server auf eine Antwort vom Applet wartet. Dieser Wert wird als Zeit in ms interpretiert. Nach Ablauf dieser Zeit wir die Antwort des Applets nicht mehr akzeptiert und serverseitig die allokierten Ressourcen freigegeben. Dieser Wert sollte mit dem Session Timeout im web.xml File korrelieren Logging Konfiguration MOCCA verwendet das Apache Commons-Logging Framework. Vorkonfiguriert ist hier Log4J. Diese Konfigurationsfiles dazu befinden sich im WEB-INF/classes Vereichnis. ACHTUNG: Wird der Loglevel auf TRACE gesetzt, werden bei einer MOA-ID Anmeldung auch die SAML-Assertions aufgezeichnet. Das heißt, bei Onlineapplikationen die die bpk Berechnung selbst durchführen, wird hier die STAMMZAHL in das Logfile geschrieben. Dies widerspricht dem E-Governmentgesetz, das das Speichern von Stammzahlen verbietet Applet Konfiguration Das Erscheinungsbild der Webseite, die das Applet beinhaltet, kann über die Seite appletpage.jsp konfiguriert werden. Für nicht integrierte Varianten, kann diese Seite entsprechend den Betreiberanforderungen bzw. Kundenanforderungen gestaltet werden. Das Applet selbst wertet folgende optionale Parameter aus: Parameter Mögliche Werte Bedeutung Background Eine http URL Über diesen Wert kann der Applet Hintergrund gesetzt werden, GuiStyle advanced oder simple Im advanced Mode ist das Applet GUI etwas aufwendiger und benötigt daher auch etwas 4

5 mehr Platz. Alle anderen Appletparameter werden von MOCCA unbedingt benötigt und dürfen nicht verändert werden. 3 Literaturverzeichnis 1. EGIZ. MOCCA-Build and Deploymentguide Apache Software Foundation. Apache Tomcat 6.0, Class Loader HOW-TO. [Online] 5