From 4075bf26b65cf2be4c55f2e9cbdc1b854a41dbce Mon Sep 17 00:00:00 2001 From: pdanner Date: Wed, 5 Sep 2007 10:02:19 +0000 Subject: removed obsolete files git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/trunk@990 d688527b-c9ab-4aba-bd8d-4036d912da1d --- .../handbook/operation/images/testapp.screen1.png | Bin 38150 -> 0 bytes .../handbook/operation/images/testapp.screen2.png | Bin 44749 -> 0 bytes .../handbook/operation/images/testapp.screen3.png | Bin 16625 -> 0 bytes .../handbook/operation/images/testapp.screen4.png | Bin 40110 -> 0 bytes spss.slinterface/handbook/operation/operation.html | 1351 -------------------- 5 files changed, 1351 deletions(-) delete mode 100644 spss.slinterface/handbook/operation/images/testapp.screen1.png delete mode 100644 spss.slinterface/handbook/operation/images/testapp.screen2.png delete mode 100644 spss.slinterface/handbook/operation/images/testapp.screen3.png delete mode 100644 spss.slinterface/handbook/operation/images/testapp.screen4.png delete mode 100644 spss.slinterface/handbook/operation/operation.html (limited to 'spss.slinterface/handbook/operation') diff --git a/spss.slinterface/handbook/operation/images/testapp.screen1.png b/spss.slinterface/handbook/operation/images/testapp.screen1.png deleted file mode 100644 index 38a226d09..000000000 Binary files a/spss.slinterface/handbook/operation/images/testapp.screen1.png and /dev/null differ diff --git a/spss.slinterface/handbook/operation/images/testapp.screen2.png b/spss.slinterface/handbook/operation/images/testapp.screen2.png deleted file mode 100644 index 45230d5c9..000000000 Binary files a/spss.slinterface/handbook/operation/images/testapp.screen2.png and /dev/null differ diff --git a/spss.slinterface/handbook/operation/images/testapp.screen3.png b/spss.slinterface/handbook/operation/images/testapp.screen3.png deleted file mode 100644 index 7d5db9cad..000000000 Binary files a/spss.slinterface/handbook/operation/images/testapp.screen3.png and /dev/null differ diff --git a/spss.slinterface/handbook/operation/images/testapp.screen4.png b/spss.slinterface/handbook/operation/images/testapp.screen4.png deleted file mode 100644 index 9fe7ee264..000000000 Binary files a/spss.slinterface/handbook/operation/images/testapp.screen4.png and /dev/null differ diff --git a/spss.slinterface/handbook/operation/operation.html b/spss.slinterface/handbook/operation/operation.html deleted file mode 100644 index 05287b293..000000000 --- a/spss.slinterface/handbook/operation/operation.html +++ /dev/null @@ -1,1351 +0,0 @@ - - - - - - MOA SL - Betriebshandbuch - - - - - - - - - - - - - - - - - - - - - - - - -

Open -Source
- -für das E-Government

- -

MOA: -Serverseitige Signaturprüfung (SL), V 1.1

- -

Betriebshandbuch

- -

Inhalt

- -

-
Übersicht
- -
Installation -
1. Einführung
2. Vorbereitung
3. Konfiguration -von Apache Tomcat -
  1. Konfiguration -des HTTP Connectors
  2. Konfiguration -des HTTPS Connectors
  - -
4. Einsatz des -MOA SL Webservices in Tomcat
5. Starten -und Stoppen von Tomcat -
  1. Unter -Windows
  2. Unter -Unix
  3. Logging -
    1. Format -der Log-Meldungen
    - -
  4. Prüfen -des erfolgreichen Starts
  - -
- -
Konfiguration -
1. Zentrale -Konfigurationsdatei -
  - -
2. Layout des -Prüfberichts
- -
Durchlaufen der -Testapplikation

- -

1 -Übersicht

- -

Das Modul Serverseitige -Signaturprüfung (MOA SL) ist als -plattformunabhängiges Modul ausgelegt, das als Webservice -über HTTP bzw. HTTPS angesprochen werden kann.

- -

Dieses Handbuch beschreibt einerseits die Installation des -Moduls, andererseits werden die Konfigurationsmöglichkeiten -dargestellt. Für eine funktionale Beschreibung des Moduls -siehe Systemhandbuch. -

- -

2 -Installation

- -

2.1 -Einführung

- -

Das MOA SL Webservice wurde plattformunabhänig -konzipiert und in Java entwickelt. Es benötigt als -Ablaufumgebung eine Java 2 Standard Edition (J2SE SDK, Version 1.4.2 oder 5.0) sowie -einen Java Servlet Container, der die Java -Servlet Specification in der Version 2.3 erfüllt.

- -

In diesem Betriebshandbuch wird davon ausgegangen, dass MOA SL -Apache -Tomcat (Version 4.1 oder höher) als Servlet -Container verwendet. Die Verwendung eines anderen Servlet Containers -ist grundsätzlich möglich, wurde aber nicht getestet -und ist auch nicht Gegenstand dieses Betriebshandbuchs.

- -

Weiters wird davon ausgegangen, dass Apache Tomcat -gleichzeitig als HTTP- bzw. HTTPS-Endpunkt für das MOA SL -Webservice dient, d.h. beide Protokolle werden direkt in Tomcat -konfiguriert. Die Verwendung eines vor Apache Tomcat geschalteten -Webservers ist grundsätzlich möglich. So werden etwa -als Teil des Apache Tomcat Projekts Module -zur Verbindung mit einem vorgeschalteten Microsoft Internet Information -Server oder mit einem vorgeschalteten Apache Webserver angeboten. Die -Beschreibung der möglichen Vorschaltungen ist jedoch nicht -Teil dieses Betriebshandbuchs.

- -

Das MOA SL Webservice nimmt Signaturprüfungsrequests -für XML-Signaturen entsprechend der Spezifikation des -Security-Layers zur österreichischen Bürgerkarte in -den Versionen 1.1 und 1.2 entgegen. Für die -Durchführung der Signaturprüfung bedient sich MOA SL -des Moduls MOA Signaturprüfung (SP). Für den Betrieb -von MOA SL ist daher die Verfügbarkeit einer -Webservice-Installation von MOA SP in der Version 1.2 oder -höher Voraussetzung.

- -

Als Logging Toolkit verwendet das MOA SL Webservice Apache Log4j. -

- -

2.2 Vorbereitung

- -

Die folgenden Schritte dienen der Vorbereitung der -Installation.

- -

Installation von J2SE SDK: Installieren Sie J2SE 1.4.2 SDK -oder J2SE 5.0 -SDK in ein beliebiges Verzeichnis. Das Wurzelverzeichnis der -J2SE SDK Installation wird im weiteren Verlauf als $JAVA_HOME -bezeichnet.
Installation von Apache Tomcat: Installieren Sie Apache -Tomcat 4.1.31 oder höher in ein Verzeichnis, das -keine Leerzeichen im Pfadnamen enthält. Verwenden Sie bitte -die zu Ihrem J2SE SDK passende Distribution von Tomcat. Das -Wurzelverzeichnis der Tomcat-Installation wird im weiteren Verlauf als $CATALINA_HOME -bezeichnet.
Installation von MOA SP: Installieren Sie das Kombinationsmodul -MOA SPSS Version 1.3 oder höher entsprechend seiner -Installationsanleitung. Sie benötigen die -Webservice-Schnittstelle von MOA SP. Es ist ausreichend, mittels -entsprechender Konfigurationseinstellungen ausschließlich MOA -SP zu aktivieren; MOA SS kann deaktiviert bleiben. Wenn Sie sowohl -für MOA SPSS als auch für MOA SL Apache Tomcat als -Servlet Container verwenden möchten, empfehlen wir, MOA SPSS -und MOA SL in jeweils eigenständigen Instanzen von Apache -Tomcat zu betreiben.
Entpacken der MOA SL Distribution: Entpacken Sie die Datei moa-sl-1.1.x.zip -in ein beliebiges Verzeichnis. Dieses Verzeichnis wird im weiteren -Verlauf als $MOA_SL_INST bezeichnet.

- -

2.3 Konfiguration -von Apache Tomcat

- -

Die zentrale Konfigurations-Datei von Tomcat ist $CATALINA_HOME/conf/server.xml. -Tomcat wird grundsätzlich mit einer funktionierenden -Default-Konfiguration ausgeliefert, die jedoch einiges an Ballast -enthält und viele Ports offen lässt.

- -

2.3.1 -Konfiguration des HTTP Connectors

- -

Die Datei $MOA_SL_INST/conf/tomcat/server.xml -enthält eine minimale Tomcat-Konfiguration, die -ausschließlich den Connector für HTTP auf Port 8080 -freischaltet. Durch kopieren dieser Datei nach $CATALINA_HOME/conf/server.xml -kann Tomcat mit dieser Konfiguration gestartet werden. Wir empfehlen -diese Konfiguration nur für Fälle, in denen das MOA -SL Webservice in einer abgeschlossenen Netzwerkumgebung betrieben wird. -

- -

2.3.2 -Konfiguration des HTTPS Connectors

- -

Wird das MOA SL Webservice in einer nicht abgeschlossenen -Umgebung (z.B. Erreichbarkeit über das Internet) betrieben, -ist es für den Benutzer von MOA SL essentiell, die -Identität des Webservice eindeutig feststellen zu -können, denn er vertraut dem Webservice ja die -Prüfung einer elektronischen Signatur an. Diese -Identitätsprüfung kann mit hoher Qualität -vorgenommen werden, wenn die Erreichbarkeit des Webservice auf HTTPS -mit Serverauthentisierung eingeschränkt wird.

- -

Für die dazu notwendige Konfiguration kann die im -vorigen Abschnitt besprochene minimale Tomcat-Konfiguration als -Ausgangspunkt verwendet werden: Zunächst ist der HTTP -Connector abzuschalten (auszukommentieren). Anschließend ist -der HTTPS Connector zu konfigurieren. Das Dokument Tomcat -SSL Configuration HOW-TO gibt einen guten -Überblick dazu. Grob zusammengefasst sind folgende Schritte -durchzuführen:

- -

Erstellung eines Server-Keystores, -der den privaten Schlüssel sowie das zugehörige -Zertifikat des Webservices enthält, mit dem es sich bei Aufbau -einer SSL-Verbindung gegenüber dem Kunden ausweist. Sie -können diesen Keystore z.B. mit keytool -erstellen, einem Programm, das Ihrem J2SE SDK beiliegt.
Erstellung eines Client-Keystores, -der die Zertifikate aller Kunden des Webservices enthält. Nur -Kunden des MOA SL Webservices, die sich beim Aufbau einer -SSL-Verbindung gegenüber dem Webservice mit einem im Client-Keystore enthaltenen -Zertifikat ausweisen, erhalten Zugriff zu den Diensten des MOA SL -Webservices. Auch dieser Keystore kann z.B. mit keytool -erstellt werden. Dieser Keystore ist optional und braucht nur erstellt -zu werden, wenn sich die Kunden gegenüber dem MOA SL -Webservice authentisieren müssen.
Konfiguration des HTTPS Connectors in $CATALINA_HOME/conf/server.xml.

- -

Die Konfiguration des HTTPS Connectors kann entfallen, wenn -Tomcat ein Webserver vorgeschaltet ist, und dieser die -SSL-Kommunikation mit dem Kunden übernimmt (siehe Abschnitt 2.1).

- -

2.4 Einsatz des MOA SL -Webservices in Tomcat

- -

Um das MOA SL Webservice in Tomcat für den Einsatz -vorzubereiten, sind folgende Schritte notwendig:

- -

Die Datei $MOA_SL_INST/moa-sl.war -enthält das einsatzfertige MOA SL Webarchiv und muss ins -Verzeichnis $CATALINA_HOME/webapps kopiert -werden. Dort wird sie beim ersten Start von Tomcat automatisch ins -Verzeichnis $CATALINA_HOME/webapps/moa-sl -entpackt.
Die zentrale Konfigurationsdatei für MOA SL muss -in ein beliebiges Verzeichnis im Dateisystem kopiert werden (z.B. $CATALINA_HOME/conf/moa-sl/). -Eine funktionsfähige Konfiguration, die als Ausgangspunkt -für die Konfiguration des MOA SL Webservices dienen kann, -finden Sie unter $MOA_SL_INST/conf/moa-sl/moa-sl.properties. -
Die Dateien xalan.jar, xercesImpl.jar -und xmlParserAPIs.jar aus dem Verzeichnis $MOA_SL_INST/endorsed14 -müssen in das Tomcat-Verzeichnis $CATALINA_HOME/common/endorsed -kopiert werden. Sind gleichnamige Dateien dort bereits vorhanden, -müssen sie überschrieben werden. Die ggf. in diesem -Verzeichnis vorhandene Datei xml-apis.jar -muss gelöscht werden.
Folgende System Properties -für die Java Virtual Machine -müssen bzw. können gesetzt werden. Am einfachsten -können diese System Properties -beim Starten von Tomcat in der Umgebungsvariablen CATALINA_OPTS -in der Form -D<name>=<wert> -übergeben werden. -
- at.gv.egovernment.moa.spss.slinterface.PropertiesLocation: -Pfad und Name der zentralen Konfigurationsdatei für MOA SL. -Eine beispielhafte Konfigurationsdatei finden Sie unter $MOA_SL_INST/conf/moa-sl/moa-sl.properties. -Wird ein relativer Pfad angegeben, wird zuerst versucht, diesen relativ -zum Wurzelverzeichnis der Webapplikation (also $CATALINA_HOME/webapps/moa-sl) -zu interpretieren. Klappt das nicht, wird dann versucht, den relativen -Pfad relativ zum Startverzeichnis der Java -Virtual Machine zu interpretieren. Diese System Property muss jedenfalls -gesetzt werden.
- log4j.configuration: -URL der Log4j Konfigurationsdatei. Eine beispielhafte -Log4j-Konfiguration finden Sie unter $MOA_SL_INST/conf/log4j/log4j.properties. Wird eine -relative URL angegeben, wird diese als File-URL relativ zum -Startverzeichnis der Java Virtual -Machine interpretiert. Ist diese System Property nicht -gesetzt, wird automatisch eine im Webarchiv unter WEB-INF/classes -enthaltene Default-Konfiguration herangezogen.
- javax.net.ssl.trustStore: -Pfad und Dateiname des Truststores -für vertrauenswürdige SSL Client-Zertifikate -(optional; nur wenn kein Webserver vor Tomcat geschalten wird und SSL -Client-Authentisierung durchgeführt werden soll). Ein -relativer Pfad werden relativ zum Startverzeichnis der Java Virtual Machine interpretiert.
- javax.net.ssl.trustStorePassword: -Passwort für den Truststore -(optional; nur wenn kein Webserver vor Tomcat geschalten wird und SSL -Client-Authentisierung durchgeführt werden soll).
- javax.net.ssl.trustStoreType: -Truststore-Typ (optional; nur wenn kein Webserver vor Tomcat geschalten -wird und SSL Client-Authentisierung durchgeführt werden soll). -Je nach verwendetem Keystore-Typ muss jks (Java Key Store) oder pkcs12 -(PKCS#12-Datei) angegeben werden.
- -

- -

2.5 Starten und -Stoppen von Tomcat

- -

2.5.1 -Unter Windows

- -

Das Verzeichnis $MOA_SL_INST/conf/tomcat/win32 -enthält Script-Dateien zum Starten und Stoppen von Tomcat. Vor -der erstmaligen Verwendung der Scripts müssen in den ersten -Zeilen die Umgebungsvariablen JAVA_HOME -(Basisverzeichnis des eingesetzten J2SE SDK) und CATALINA_HOME -(Basisverzeichnis der eingesetzten Tomcat-Installation) angepasst -werden. Evtl. müssen Sie auch noch die in den Script-Dateien -gesetzten, in Abschnitt 2.4 -besprochenen System Properties -anpassen.

- -

2.5.2 Unter -Unix

- -

Zunächst müssen die in Abschnitt 2.4 -besprochenen System Properties -mit Hilfe der Umgebungsvariablen CATALINA_OPTS -gesetzt werden. Die Datei $MOA_SL_INST/tomcat/unix/moa-env.sh -enthält ein Beispiel dafür. Weiters müssen -noch die Umgebungsvariablen JAVA_HOME -(Basisverzeichnis des eingesetzten J2SE SDK) und CATALINA_HOME -(Basisverzeichnis der eingesetzten Tomcat-Installation) angepasst -werden.

- -

Nun kann Tomcat aus seinem Basisverzeichnis mit

- -

bin/catalina.sh start

- -gestartet werden. Das Stoppen von Tomcat erfolgt analog mit -

bin/catalina.sh stop

- -

2.5.3 -Logging

- -

Das MOA SL Webservice verwendet Apache Log4j für die -Ausgabe von Log-Meldungen am Bildschirm bzw. in Log-Dateien. Log4j -bietet zahlreiche Konfigurationsmöglichkeiten, die -ausführlich im Apache -Log4j -Handbuch beschrieben sind. Unter anderem gibt es die -Möglichkeit, folgende Einstellungen vorzunehmen: -

- -

-
Das verwendete Log-Level (DEBUG, INFO, - WARN, ERROR, FATAL);
- -
-
Name und maximale Größe der -Log-Datei(en);
- -
-
Das Aussehen der Log-Einträge.
- -

- -

Das MOA SL Webservice verwendet für alle -Logeinträge die Log-Hierarchie slinterface. -Für die einzelnen Pakete des MOA SL Webservices werden davon -abgeleitete Sub-Hierarchien eingesetzt, z.B. slinterface.xmlparser, -slinterface.beans oder slinterface.filters.

- -

Eine für MOA SL passende Konfigurationsdatei -für Log4j finden Sie unter $MOA_SL_INST/conf/log4j/log4j.properties. Wird diese -Datei als Logging-Konfiguration verwendet, so werden alle Log-Meldungen -sowohl in die Konsole, als auch in die Datei $CATALINA_HOME/logs/moa-sl.log -geschrieben.

- -

2.5.3.1 -Format der Log-Meldungen

- -

Anhand einer konkreten Log-Meldung wird das Format der MOA SL -Log-Meldungen erläutert:

- -

INFO | 10 15:58:45,531 | slinterface.listeners | main | 
 Web application initialization succeeded..

- -

Der Wert INFO besagt, dass die -Log-Meldung im Log-Level INFO entstanden ist. -Folgende Log-Levels existieren:

- -

-
DEBUG: Log-Meldungen im Log-Level - DEBUG geben Auskunft über die -innere Arbeitsweise des Systems. Sie sind hauptsächlich -für Entwickler interessant.
- -
-
INFO: Diese Log-Meldungen geben -Status-Informationen über den Ablauf des Webservices, wie z.B. -über das Einlangen einer neuen Anfrage.
- -
-
WARN: Bei der Ausführung -einer Anfrage sind leichte Fehler aufgetreten. Der Ablauf des -Webservices ist nicht weiter beeinträchtigt.
- -
-
ERROR: Die Ausführung -einer Anfrage musste abgebrochen werden. Das Webservice ist davon nicht -beeinträchtigt.
- -
-
FATAL: Es ist ein Fehler -aufgetreten, der den weiteren Betrieb des Webservices nicht mehr -erlaubt.
- -

- -

Der nächste Wert 10 15:58:45,531 -gibt den Zeitpunkt an, zu dem die Log-Meldung generiert wurde (in -diesem Fall den 10. Tag im aktuellen Monat, sowie die genaue Uhrzeit).

- -

Der Wert slinterface.listeners gibt -die Log-Hierarchie an, aus der die Log-Meldung stammt.

- -

Der Wert main bezeichnet den Thread, -aus der die Log-Meldung stammt.

- -

Der Rest der Zeile einer Log-Meldung ist der eigentliche Text, -mit dem das System bestimmte Informationen anzeigt. Im Fehlerfall ist -häufig ein Java Stack-Trace angefügt, der eine -genauere Ursachen-Forschung ermöglicht.

- -

2.5.4 -Prüfen des erfolgreichen Starts

- -

Ein erfolgreicher Start des MOA SL Webservices ist an -folgender Log-Meldung ersichtlich:

- -

INFO | 10 15:58:45,531 | slinterface.listeners | main | 
 Web application initialization succeeded..

- -

Konnte das MOA SL Webservice nicht -ordnungsgemäß gestartet werden, führt das -zu folgender Log-Meldung:

- -

FATAL | 18 10:17:03,475 | main | TID=startup NID=<null> 
 Web application initialization failed.

- -

In diesem Fall geben die Log-Meldungen -unmittelbar davor Aufschluss über den genaueren Grund.

- -

Fehlermeldungen während der Initialisierung des -XML-Parsers, die wie nachfolgend dargestellt aussehen, können -ignoriert werden. Sie resultieren aus einem Bug im eingesetzten -XML-Parser Apache Xerces in der Version 2.6.2.

- -

[Error] xhtml-attribs-1.xsd:xx:xx: src-attribute_group.3: 
 Circular definitions detected for attribute group 'xxx'. 
 Recursively following attribute group references eventually leads back to itself.
[Error] xhtml-attribs-1.xsd:xx:xx: src-redefine.7.2.1: 
 No attributeGroup in the redefined schema has a name matching 'xx'.

- -

3 -Konfiguration

- -

3.1 -Zentrale Konfigurationsdatei

- -

Alle Konfigurationsparameter von MOA SL mit Ausnahme des -Layouts für den Prüfbericht (siehe Abschnitt 3.2) sind in einer -zentralen Konfigurationsdatei zusammengefasst. Eine beispielhafte -Konfigurationsdatei finden Sie unter $MOA_SL_INST/conf/moa-sl/moa-sl.properties. -Für Hinweise, wie Sie dem MOA SL Webservice mitteilen, welche -Konfigurationsdatei es verwenden soll, siehe Abschnitt 2.4.

- -

In den folgenden Abschnitten werden die einzelnen -Konfigurationsparameter der zentralen Konfigurationsdatei im Detail -besprochen. Die meisten Konfigurationsparameter werden leichter -verständlich, wenn Sie zunächst das Systemhandbuch lesen. Dort werden -der gesamte Ablauf eines Signaturprüfvorgangs in MOA SL sowie -die daran beteiligten Komponenten erklärt.

- -

Die Konfigurationsdatei ist als Java -Properties Datei aufgebaut, d. h. jede Zeile -enthält den Namen sowie den Wert des jeweiligen -Konfigurationsparameters in der Form name=wert. -Details zum Aufbau einer Java -Properties Datei finden Sie in der API-Dokumentation zu -Ihrem Java JDK, beispielsweise hier. -

- -

3.1.1 -XML-Schemata für Request- und Response-Validierung

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name location.schema.sl

Erläuterung

Mit diesem Konfigurationsparameter wird MOA SL -mitgeteilt, wo es das XML-Schema für die Validierung eines -eingehenden Signaturprüfungsrequests nach Security-Layer V1.2 -findet.

- -

Der Konfigurationsparameter muss als Wert einen Pfad -enthalten, der mit / beginnt, und der von MOA -SL als relativ zum Context Root -der Webapplikation interpretiert wird.

- -

Beispiel

/WEB-INF/classes/resources/schemas/Core.20031231.xsd

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name location.schema.moa

Erläuterung

Mit diesem Konfigurationsparameter wird MOA SL -mitgeteilt, wo es das XML-Schema für die Validierung eines von -MOA SP empfangenen Signaturprüfungsresponses nach MOA SPSS -V1.3 findet.

- -

Der Konfigurationsparameter muss als Wert einen Pfad -enthalten, der mit / beginnt, und der von MOA -SL als relativ zum Context Root -der Webapplikation interpretiert wird.

- -

Beispiel

/WEB-INF/classes/resources/schemas/MOA-SPSS-1.3.xsd

- -

3.1.2 -Arbeitsverzeichnis

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name location.tempdir

Erläuterung

Mit diesem Konfigurationsparameter wird MOA SL -mitgeteilt, wo es das Arbeitsverzeichnis zum Ablegen der von einer -geprüften Signatur abgesicherten Dokumente findet. Diese -Dokumente werden temporär gespeichert, damit sie vom Benutzer -über den Prüfbericht abgerufen werden -können.

- -

Der Konfigurationsparameter muss als Wert einen Pfad -enthalten, der von MOA SL als relativ zum Context -Root der Webapplikation interpretiert wird. Der angegebene -Pfad muss einen abschließenden / -aufweisen und im Dateisystem tatsächlich existieren.

- -

Beispiel

/workdir/temp/

- -

3.1.3 -Parameter der verwendeten MOA SP Installation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name service.sp.endpoint

Erläuterung

Mit diesem Konfigurationsparameter wird MOA SL der -Zugangspunkt zum Webservice von MOA SP mitgeteilt.

- -

Der Konfigurationsparameter muss eine URL enthalten, die -von MOA SL aus erreichbar ist und den Zugangspunkt zu MOA SP -adressiert.

- -

Beispiel

http://localhost:8080/moa-spss/services/SignatureVerification

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name service.sp.trustProfileId

Erläuterung

Mit diesem Konfigurationsparameter wird MOA SL -mitgeteilt, welches Vertrauensprofil es im Signaturprüfrequest -an MOA SP verwenden soll.

- -

Der Konfigurationsparameter muss den Bezeichner eines in -MOA SP hinterlegten Vertrauensprofils enthalten.

- -

Hinweis: Zum Durchlaufen der -Testapplikation nach Abschnitt 4 -dieses Handbuchs müssen Sie in MOA SP ein Vertrauensprofil mit -dem Namen MOA-SL-Test einrichten. Unter $MOA_SL_INST/conf/moa-spss/trustprofiles/spssconfig.fragment -finden Sie das dazu notwendige XML-Fragment zum -Einfügen in die Konfigurationsdatei von MOA SP. Unter $MOA_SL_INST/conf/moa-spss/trustprofiles/moa-sl/test/ -finden Sie das im XML-Fragment referenzierte Verzeichnis mit den -für das Vertrauensprofil notwendigen Zertifikatsdateien.

- -

Beispiel

MOA-SL-Test

- -

3.1.4 -Umfang der Prüfberichtseite

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name result.showetsi

Erläuterung

Dieser Konfigurationsparameter gibt an, ob MOA SL auf -der Prüfberichtseite unter den signierten Dokumenten auch -eventuell vorhandenene, mitsignierte Signatureigenschaften (z.B. das -Signaturdatum) auflisten soll. Signatureigenschaften sind in der Regel -vorhanden, wenn die zur Prüfung eingereichte Signatur von -einer Bürgerkartenumgebung erstellt worden ist.

- -

Der Konfigurationsparamter muss einen der Werte true -oder false aufweisen.

- -

Beispiel

false

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name result.showslmanifest

Erläuterung

Dieser Konfigurationsparameter gibt an, ob MOA SL auf -der Prüfberichtseite unter den signierten Dokumenten auch ein -eventuell vorhandenes, mitsigniertes Signaturmanifest -nach Security-Layer V1.2 auflisten soll.

- -

Der Konfigurationsparamter muss einen der Werte true -oder false aufweisen.

- -

Beispiel

false

- -

3.1.5 -Parameter für das Umschreiben der Links in der -Prüfberichtseite

- -

Insbesondere zum Verständnis dieses Abschnitts -sollten Sie zunächst das Systemhandbuch lesen. -Dort werden der gesamte Ablauf eines Signaturprüfvorgangs in -MOA SL sowie die daran beteiligten Komponenten erklärt.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name rewrite

Erläuterung

Dieser Konfigurationsparameter gibt an, ob MOA SL Links -auf der Prüfberichtseite umschreiben soll.

- -

der

- -

Beispiel

true

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name rewrite.proxyURL

Erläuterung

Dieser Konfigurationsparameter enthält die URL -des Rewrite-Proxy. Der Rewrite-Proxy ist jener Rechner, -der (möglicherweise im Gegensatz zum Rechner, auf dem MOA SL -läuft) vom Internet aus erreichbar ist, und über den -alle Anfragen vom Benutzer an MOA SL geleitet werden.

- -

Teil der mit diesem Konfigurationsparameter angegebenen -URL ist der Platzhalter für den Domänennamen des Rewrite-Proxy. Wie dieser -Platzhalter aussehen muss, wird im Konfigurationsparameter rewrite.proxyURL.proxyhostDummy -festgelegt. Im unten angegebenen Beispiel lautet der Platzhalter <proxyhost>.

- -

Beispiel

http://<rewriteproxyhost>:1234/rewrite

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name rewrite.proxyURL.proxyhostDummy

Erläuterung

Dieser Konfigurationsparameter enthält das -Format für den Platzhalter für den -Domänennamen des Rewrite-Proxy. -Der Platzhalter im Konfigurationsparameter rewrite.proxyURL -muss genau diesem Format entsprechen.

- -

Notwendig ist dieser Platzhalter, weil MOA SL bei der -Erstellung der Prüfberichtseite alle Vorkommnisse dieses -Platzhalters in der Prüfberichtseite durch den -Domänennamen jener IP-Adresse ersetzt, von der aus der -Signaturprüfrequest an MOA SL gesendet wurde. Die -Konfiguration des dazu notwendigen Reverse -DNS Lookup geschieht mit dem Konfigurationsparameter rewrite.dn.*. -

- -

Beispiel

<rewriteproxyhost>

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name rewrite.dn.*

Erläuterung

Dieser (bzw. diese) Konfigurationsparameter definieren -die Lookup-Tabelle für das Reverse -DNS Lookup im Zuge der Umschreibung von Links in der -Prüfberichtseite, damit diese ausschließlich -über den Rewrite-Proxy -abgerufen werden können.

- -

Der Aufbau der Konfigurationsparameter entspricht dabei -dem Schema-rewrite.dn.<IP-Adresse>=<Domänenname>. -

- -

Der Default-Domänenname, der für die -Umschreibung verwendet wird, wenn für die IP-Adresse des Rewrite-Proxy kein Eintrag in der -Lookup-Tabelle definiert wurde, wird wie folgt angegeben: rewrite.dn.default=<Domänenname>. -

- -

Das Beispiel geht von zwei möglichen Rewrite-Proxys aus, denen die -IP-Adressen 192.168.0.101 bzw. 192.168.0.102 -zugeordnet sind. Die nach außen sichtbaren Namen dieser Rewrite-Proxys lauten rewriteproxyhost1 -und rewriteproxyhost2. rewriteproxyhost1 -ist als Standard-Rewrite-Proxy -konfiguriert.

- -

Beispiel

rewrite.dn.192.168.0.101=rewriteproxyhost1 - -rewrite.dn.192.168.0.102=rewriteproxyhost2 - -rewrite.dn.default=rewriteproxyhost1

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name rewrite.MOASLUrlParamName

Erläuterung

Dieser Konfigurationsparameter gibt den Namen des -URL-Parameters in den im Signaturprüfbericht für den Rewrite-Proxy umgeschriebenen -Links an, dessen Wert die vom Rewrite-Proxy -für den tatsächlichen Abruf von Daten von MOA SL -enthält.

- -

Am Wert dieses Konfigurationsparameters erkennt der Rewrite-Proxy, wie der -HTTP-Request an den Rewrite-Proxy -in einen HTTP-Request an das MOA SL Webservice umzusetzen ist. Lautet -eine im Signaturprüfbericht enthaltene URL z.B. http://rewriteproxyhost1:1234/rewrite?targetURL=http://moaslhost:8080/moa-sl/showdata?hidCount=0, -dann geht zunächst ein HTTP-Request an den Rewrite-Proxy (der auf dem -Rechner mit dem Namen rewriteproxyhost1 unter Port 1234 -lauscht). Der Rewrite-Proxy -entnimmt nun aus dem URL-Parameter targetURL -die URL für die Umsetzung an MOA SL, also http://moaslhost:8080/moa-sl/showdata?hidCount=0. -Der Rewrite-Proxy setzt -nun einen entsprechenden HTTP-Request an MOA SL ab; die Antwort von MOA -SL wird als Antwort auf den an den Rewrite-Proxy -gerichteten HTTP-Request weitergegeben.

- -

Beispiel

targetURL

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name rewrite.MOASLWebAppServUrl

Erläuterung

Dieser Konfigurationsparameter gibt jene URL an, unter -der der Webapplikationsserver mit MOA SL vom Rewrite-Proxy -aus erreichbar ist.

- -

Die URL besteht aus Protokoll, Domänennamen -sowie gegebenenfalls Port (wenn dieser nicht dem Standardport -für das Protokoll entspricht). Nach dem Domänennamen -bzw. Port dürfen keine weiteren Bestandteile mehr vorkommen.

- -

Verwendung findet dieser Konfigurationsparameter als -erster Teil des Werts für den oben besprochenen URL-Parameter (rewrite.sliUrlParamName). -

- -

Beispiel

http://moaslhost:8080

- -

3.2 Layout des -Prüfberichts

- -

Die einzige Schnittstelle des MOA SL Webservices zum Benutzer -ist der Prüfbericht über die eingereichte Signatur, -den das Service dem Benutzer in einer für ihn gut -aufbereiteten Form darstellt, bevor das automatisch auswertbare -Prüfprotokoll an die aufrufende Applikation -zurückübermittelt (für eine -Erklärung des gesamten Signaturprüfvorgangs in MOA SL -sowie der daran beteiligten Komponenten vergleiche das Systemhandbuch).

- -

Das Layout des Prüfberichts, das in der JSP-Seite $MOA_SL_WEBAPP/pages/resultOverview.jsp -($MOA_SL_WEBAPP steht für den Ort der -Webapplikatioin, für gewöhnlich ist das-$CATALINA_HOME/webapps) festgelegt ist, kann -völlig frei gestaltet werden.

- -

Wenn Sie das Layout gegenüber der Vorgabe -verändern möchten, editieren Sie einfach die -HTML-Teile dieser JSP-Seite. Beachten Sie bitte, dass Sie dabei die -JSP-Scriptelemente unverändert lassen. JSP-Scriptelemente sind -entweder Tags, die mit dem Präfix jsp -gekennzeichnet sind (z.B. <jsp:useBean> -oder <jsp:getProperty>, oder -Bereiche die mit der Kennzeichnung <% -eingeleitet bzw. mit der Kennzeichnung %> -ausgeleitet werden.

- -

4 -Durchlaufen der Testapplikation

- -

Konnte das MOA SL Webservice entsprechend Abschnitt 2.5.4 -erfolgreich initialisiert werden, und haben Sie weiters die -Konfiguration des MOA SL Webservices entsprechend Abschnitt 3 an Ihre Anforderungen -angepasst, sollten Sie schließlich prüfen, ob die -mit MOA SL mitgelieferte Testapplikation erfolgreich durchlaufen werden -kann.

- -

Beginnen Sie bitte, in dem Sie einen Webbrowser starten und -sich mit folgender Seite verbinden, die Teil des MOA SL Webservices -ist. Sollte Ihre Tomcat-Installation unter einer anderen Adresse als localhost:8080 -erreichbar sein, passen Sie die URL bitte entsprechend an.

- -

http://localhost:8080/moa-sl/pages/test/forms/verify.slxhtml.jsp

- -

Die aufgerufene Webseite sollte in etwa wie folgt aussehen -(für eine größere Darstellung bitte -klicken):

- -

Durch Abschicken des dargestellten Formulars wird ein -vorbereiteter Signaturprüfungsrequest entsprechend der -Spezifikation des Security-Layers an MOA SL übermittelt. Als -weiterer Parameter wird eine DataURL ebenfalls ensprechend der -Spezifikation des Security-Layers angegeben. Beide Parameter sind auf -das installierte MOA SL Webservice abgestimmt und können -unverändert übernommen werden.

- -

Wenn das Formular an an MOA SL übermittelt wurde, -antwortet MOA SL mit dem Signaturprüfbericht, der in etwa wie -folgt aussehen sollte:

- -

Sollten Sie an statt des Prüfberichts eine -Fehlerseite von Tomcat erhalten, liegt das mit hoher Wahrscheinlichkeit -daran, dass das Zusammenspiel von MOA SL mit MOA SPSS nicht korrekt -konfiguriert wurde. Prüfen Sie dann Ihre Konfiguration -entsprechend den Angaben in Abschnitt 3.1.3.

- -

Wenn Sie den Prüfbericht zwar erhalten, der Text zu -Prüfungen/Zertifikat jedoch in rot gehalten ist und auf einen -Fehler bei der Zertifikatsprüfung hinweist, wurde das -für die Testapplikation notwendige Vertrauensprofil in MOA -SPSS nicht korrekt konfiguriert. Folgen Sie dann den Hinweisen in -Abschnitt 3.1.3.

- -

Der Prüfbericht selbst enthält Informationen -zum Ersteller der Signatur, zum Aussteller des Zertifikats, -über Seriennummer und Qualität des Zertifikats, sowie -über die durchgeführten Prüfungen -bezüglich der Signatur selbst sowie des verwendeten -Zertifikats. Nach diesen Informationen enthält der -Prüfbericht eine Liste der von der Signatur gesicherten -Dokumente. In unserem Fall erstreckt sich die Signatur über -genau ein Dokument. Dieses Dokument kann durch einen Klick auf den -entsprechenden Link in einem neuen Fenster geöffnet werden. -Das geöffnete Dokument sollte in etwa wie folgt aussehen:

- -

Wenn Sie schließlich im Prüfbericht dem -Link Zurück zur Anwendung ... -folgen, gelangen Sie zur Abschlussseite der Testapplikation:

- -

Die Abschlussseite präsentiert in Tabellenform die -Informationen, die vom MOA SL Webservice als automatisch auswertbare -Information entsprechend der Spezifikation des Security-Layers an den DataURL-Server -(vergleiche Parameter auf der Startseite der Testapplikation) -übermittelt. Im Wesentlichen ist das der -Signaturprüfresponse entsprechend der Spezifikation des -Security-Layers.

- - - -- cgit v1.2.3