From f25a072fd1c3b131d5f2f15689942ca7c55a62c0 Mon Sep 17 00:00:00 2001 From: "(no author)" <(no author)@d688527b-c9ab-4aba-bd8d-4036d912da1d> Date: Mon, 6 Aug 2007 14:26:08 +0000 Subject: This commit was manufactured by cvs2svn to create tag 'Build-ID-1_4_0'. git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/tags/Build-ID-1_4_0@907 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 @@ - - -
- - -- - | Open
-Source - -für das E-Government |
-
- - - |
MOA: -Serverseitige Signaturprüfung (SL), V 1.1
- -Betriebshandbuch
- -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. -
- -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. -
- -Die folgenden Schritte dienen der Vorbereitung der -Installation.
- -$JAVA_HOME
-bezeichnet. $CATALINA_HOME
-bezeichnet.moa-sl-1.1.x.zip
-in ein beliebiges Verzeichnis. Dieses Verzeichnis wird im weiteren
-Verlauf als $MOA_SL_INST
bezeichnet. 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.
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.
-
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:
- -keytool
-erstellen, einem Programm, das Ihrem J2SE SDK beiliegt.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. $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).
- -Um das MOA SL Webservice in Tomcat für den Einsatz -vorzubereiten, sind folgende Schritte notwendig:
- -$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. $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
.
- 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.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.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.
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- -
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.
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.
- -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'.
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.
-
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 |
-
-
Beispiel | - -
-
|
-
-
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 |
-
-
Beispiel | - -
-
|
-
-
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 |
-
-
Beispiel | - -
-
|
-
-
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 | - -
-
|
-
-
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 |
-
-
Beispiel | - -
-
|
-
-
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 |
-
-
Beispiel | - -
-
|
-
-
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 |
-
-
Beispiel | - -
-
|
-
-
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 | - -
-
|
-
-
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 |
-
-
Beispiel | - -
-
|
-
-
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 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 |
-
-
Beispiel | - -
-
|
-
-
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 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: Das Beispiel geht von zwei möglichen Rewrite-Proxys aus, denen die
-IP-Adressen |
-
-
Beispiel | - -
-
|
-
-
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. |
-
-
Beispiel | - -
-
|
-
-
Name | - -rewrite.MOASLWebAppServUrl |
-
-
Erläuterung | - -
- Dieser Konfigurationsparameter gibt jene URL an, unter
-der der Webapplikationsserver mit MOA SL vom 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 ( |
-
-
Beispiel | - -
-
|
-
-
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.
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.