From 64c052c310ff1d23997efeb7f579d56e5ee13eec Mon Sep 17 00:00:00 2001 From: gregor Date: Tue, 30 May 2006 20:12:30 +0000 Subject: =?UTF-8?q?Betriebshandbuch=20und=20Systemhandbuch=20=C3=BCberarbe?= =?UTF-8?q?itet=20bzw.=20erweitert.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/trunk@707 d688527b-c9ab-4aba-bd8d-4036d912da1d --- .../handbook/system/images/Zusammenspiel.VSD | Bin 0 -> 138240 bytes .../handbook/system/images/Zusammenspiel.mit.png | Bin 0 -> 48649 bytes .../handbook/system/images/Zusammenspiel.ohne.png | Bin 0 -> 36106 bytes spss.slinterface/handbook/system/system.html | 960 +++++++++++---------- 4 files changed, 493 insertions(+), 467 deletions(-) create mode 100644 spss.slinterface/handbook/system/images/Zusammenspiel.VSD create mode 100644 spss.slinterface/handbook/system/images/Zusammenspiel.mit.png create mode 100644 spss.slinterface/handbook/system/images/Zusammenspiel.ohne.png (limited to 'spss.slinterface/handbook/system') diff --git a/spss.slinterface/handbook/system/images/Zusammenspiel.VSD b/spss.slinterface/handbook/system/images/Zusammenspiel.VSD new file mode 100644 index 000000000..0088d5109 Binary files /dev/null and b/spss.slinterface/handbook/system/images/Zusammenspiel.VSD differ diff --git a/spss.slinterface/handbook/system/images/Zusammenspiel.mit.png b/spss.slinterface/handbook/system/images/Zusammenspiel.mit.png new file mode 100644 index 000000000..4e7fcda67 Binary files /dev/null and b/spss.slinterface/handbook/system/images/Zusammenspiel.mit.png differ diff --git a/spss.slinterface/handbook/system/images/Zusammenspiel.ohne.png b/spss.slinterface/handbook/system/images/Zusammenspiel.ohne.png new file mode 100644 index 000000000..0dc944cb9 Binary files /dev/null and b/spss.slinterface/handbook/system/images/Zusammenspiel.ohne.png differ diff --git a/spss.slinterface/handbook/system/system.html b/spss.slinterface/handbook/system/system.html index eb287ee8a..b911d84c8 100644 --- a/spss.slinterface/handbook/system/system.html +++ b/spss.slinterface/handbook/system/system.html @@ -1,486 +1,512 @@ + - MOA SS und SP - Installation + MOA SL - Systemhandbuch + + + - - + + + + +
+ + + - - - + + + + + + + -
Logo BKAOpen Source
- für das E-Government		Logo MOALogo BKAOpen +Source
+ +für das E-Government		Logo MOA
-
-

MOA: Serversignatur (SS) und Signaturprüfung (SP), V 1.3

-

Installation

-
-

Inhalt

-
    -
  1. -

    Übersicht

    -
    2. -
  2. -

    Webservice

    -
      -
    1. Basisinstallation -
        -
      1. Einführung
        2. -
      2. Installation -
          -
        1. Vorbereitung
          2. -
        2. Konfiguration von Apache Tomcat -
            -
          1. Konfiguration des HTTP Connectors
            2. -
          2. Konfiguration des HTTPS Connectors
            3. -
          3. Einrichten des MOA SP/SS Administrators
            4. -
          -
          3. -
        3. Einsatz des MOA SP/SS Webservices in Tomcat
          4. -
        4. Starten und Stoppen von Tomcat -
            -
          1. Unter Windows
            2. -
          2. Unter Unix
            3. -
          3. Prüfen des erfolgreichen Starts
            4. -
          -
          5. -
        5. Änderung der Konfiguration im laufenden Betrieb
          6. -
        -
        3. -
      3. Logging -
          -
        1. Format der Log-Meldungen
          2. -
        2. Wichtige Log-Meldungen
          3. -
        -
        4. -
      -
      2. -
    2. Erweiterungsmöglichkeiten
        -
      1. Vorgeschalteter Webserver
          -
        1. Microsoft Internet Information Server (MS IIS)
            -
          1. Konfiguration von Jakarta mod_jk im MS IIS
            2. -
          2. Konfiguration von Tomcat
            3. -
          3. Konfiguration von SSL
            4. -
          -
          2. -
        2. Apache
            -
          1. Konfiguration von Jakarta mod_jk im Apache
            2. -
          2. Konfiguration von Tomcat
            3. -
          3. Konfiguration von SSL mit mod_SSL
            4. -
          -
          3. -
        -
        2. -
      2. Datenbank
          -
        1. PostgreSQL
            -
          1. Anlegen eines Benutzers und einer Datenbank für MOA SP/SS
            2. -
          2. Archivierung von CRLs
            3. -
          3. Logging
            4. -
          -
          2. -
        2. Andere Datenbanken
          3. -
        -
        3. -
      -
      3. -
    -
  3. Klassenbibliothek -
      -
    1. Basisinstallation -
        -
      1. Einführung
        2. -
      2. Vorbereitung
        3. -
      3. Verwendung
        4. -
      4. Logging
        5. -
      -
      2. -
    2. Erweiterungsmöglichkeiten
      3. -
    -
    4. -
-
    -
  1. Referenzierte Software
    2. -
-
-

1 Übersicht

-

Die Module Signaturprüfung (SP) und Serversignatur (SS) sind als plattformunabhängige Module ausgelegt, die entweder als Webservice über HTTP bzw. HTTPS oder als Klassenbibliothek über ein API angesprochen werden können. Dieses Handbuch beschreibt die Installation der beiden Module als Webservice oder als Klassenbibliothek, sowie die Einrichtung der Systemumgebung.

-

2 Webservice

-

Dieser Abschnitt beschreibt die Installation von MOA SP/SS als Webservice. Im ersten Unterkapitel wird eine minimale Basisinstallation beschrieben. Das zweite Unterkapitel zeigt eine Reihe von optionalen Erweiterungsmöglichkeiten auf.

-

2.1 Basisinstallation

-

2.1.1 Einführung

-

Die Basisinstallation des Webservices stellt einerseits die minimalen Anforderungen für den Betrieb von MOA SP/SS als Webservices dar, andererseits dient sie als Ausgangspunkt für optionale Erweiterungsmöglichkeiten.

-

Folgende Software ist Voraussetzung für die Basisinstallation des Webservices:

- -

In diesem Betriebs-Szenario wird das MOA SP/SS Webservice in Tomcat zum Einsatz gebracht. Tomcat fungiert gleichzeitig als HTTP- und HTTPS-Endpunkt für das MOA SP/SS Webservice. Beide Protokolle werden direkt in Tomcat konfiguriert. Das MOA SP/SS Webservice verwendet Log4j als Logging Toolkit.

-

2.1.2 Installation

-

2.1.2.1 Vorbereitung

-

Die folgenden Schritte dienen der Vorbereitung der Installation.

-
-
Installation von J2SE SDK
-
Installieren Sie J2SE 1.3.1 SDK oder J2SE 1.4.2 SDK oder J2SE 5.0 SDK in ein beliebiges Verzeichnis. Wir empfehlen die Installation von J2SE 5.0 SDK. Das Wurzelverzeichnis der J2SE SDK Installation wird im weiteren Verlauf als $JAVA_HOME bezeichnet.
-
Installation von Apache Tomcat 4.1
-
Installieren Sie Apache Tomcat 4.1.18 oder höher in ein Verzeichnis, das keine Leerzeichen im Pfadnamen enthält. Wir empfehlen die Installation von Apache Tomcat 4.1.31. 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.
-
Entpacken der MOA SP/SS Webservice Distribution
-
Entpacken Sie die Datei moa-spss-1.2.x.zip in ein beliebiges Verzeichnis. Dieses Verzeichnis wird im weiteren Verlauf als $MOA_SPSS_INST bezeichnet.
-
Installation der Krypographiebibliotheken von SIC/IAIK
-
-

Die Installation der Kryptographiebibliotheken von SIC/IAIK ist abhängig vom eingesetzten J2SE SDK:

-
-
J2SE 1.3.1 SDK
-
Kopieren Sie alle Dateien aus dem Verzeichnis - - - $MOA_SPSS_INST/ext13 in das Verzeichnis $JAVA_HOME/jre/lib/ext.
-
J2SE 1.4.2 SDK oder JSE 5.0 SDK
-
Kopieren Sie alle Dateien aus dem Verzeichnis $MOA_SPSS_INST/ext14 in das Verzeichnis $JAVA_HOME/jre/lib/ext. Zusätzlich müssen Sie die Rechtedateien Ihres J2SE 1.4.2 SDK bzw. J2SE 5.0 SDK austauschen. Laden Sie dazu die Unlimited Strength - - - Jurisdiction Policy Files von der J2SE 1.4.2 SDK Downloadseite bzw. J2SE 5.0 SDK Downloadseite und folgen Sie der darin enthaltenen Installationsanweisung.
-
-
-
-

2.1.2.2 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.1.2.2.1 Konfiguration des HTTP Connectors
-

Die Datei $MOA_SPSS_INST/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 SP/SS Webservice in einer abgeschlossenen Netzwerkumgebung betrieben wird.

-
2.1.2.2.2 Konfiguration des HTTPS Connectors
-

Wird das MOA SP/SS Webservice in einer nicht abgeschlossenen Umgebung (z.B. Erreichbarkeit über das Internet) betrieben, ist die gegenseitige Identitätsfeststellung von Kunde und Webservice essentiell:

- -

Beide Identitätsprüfungen können mit hoher Qualität vorgenommen werden, wenn die Erreichbarkeit des Webservice auf SSL mit Server- (für MOA SP) bzw. Client- und Serverauthentisierung (für MOA SS) 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:

- -

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.2.1).

-
2.1.2.2.3 Einrichten des MOA SP/SS Administrators
-

Das MOA SP/SS Webservice kann remote durch den Aufruf einer speziellen URL des Webservices dazu veranlasst werden, seine Konfiguration neu einzulesen (vergleiche Abschnitt 2.1.2.5). Der Zugriff auf diese URL ist durch eine Passwort-Abfrage geschützt, und kann nur von Tomcat-Benutzern aufgerufen werden, denen die Tomcat-Benutzer-Rolle moa-admin zugeordnet wurde.

-

Um diese Benutzer-Rolle und einen oder mehrere Benutzer einzurichten, müssen in der Datei $CATALINA_HOME/conf/tomcat-users.xml unter dem Element <tomcat-users> sinngemäß folgende Einträge hinzugefügt werden:

-

- 

<role rolename="moa-admin"/> 
-<user username="moa-chief" password="openSesam" roles="moa-admin"/>
-

Soll der Aufruf dieser URL niemandem ermöglicht werden, sind die oben beschriebenen Einträge einfach nicht vorzunehmen.

- -

2.1.2.3 Einsatz des MOA SP/SS Webservices in Tomcat

-

Um das MOA SP/SS Webservice in Tomcat für den Einsatz vorzubereiten, sind folgende Schritte notwendig:

+ + + + +
+

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

+ +

Systemhandbuch

+ +
+

Inhalt

+ +
    + +
  1. +

    Einführung

    + +
    2. + +
  2. Überblick
    3. + +
  3. Komponenten +
      + +
    1. Der +Filter SL2MOAFilter +
      2. + +
    2. Das +Servlet MOAServlet +
      3. + +
    3. Die +JSP-Seite resultOverview.jsp +
      4. + +
    4. Das +Servlet HashInputDataServlet
      5. + +
    5. Das +Servlet ReturnServlet
      6. + +
    6. Die +Klasse URLRewriter
      7. + +
    7. Der +Deployment Descriptor web.xml
      8. + +
    + +
    4. + +
  4. Zusammenspiel der +Komponenten +
      + +
    1. Basisablauf
      2. + +
    2. Ablauf mit Rewrite-Proxy
      3. + +
    + +
    5. + +
+ +
+

1 +Einführung

+ +

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 den Aufbau von MOA SL. Abschnitt 2 +bietet einen groben Überblick über die Funktionsweise +von MOA SL. Abschnitt 3 beschreibt die einzelnen Komponenenten, aus +denen MOA SL aufgebaut ist. Abschnitt 4 schließlich +beschreibt das Zusammenspiel der einzelnen Komponenten.

+ +

Für die Installation und die Konfiguration von MOA SL +siehe Betriebshandbuch. +

+ +

2 +Überblick

+ +

Das Modul Serverseitige +Signaturprüfung (MOA SL) bietet für +Signaturprüfung eine serverseitige Implementierung einer +Bürgerkarten-Umgebung entsprechend den Spezifikationen +zur österreichischen Bürgerkarte in der +Version 1.2.

+ +

Der Funktionsumfang von MOA SL kann wie folgt zusammengefasst +werden:

+ -

2.1.2.4 Starten und Stoppen von Tomcat

-
2.1.2.4.1 Unter Windows
-
-

Das Verzeichnis $MOA_SPSS_INST/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.1.2.3 besprochenen System Properties anpassen.

-
-
2.1.2.4.2 Unter Unix
-

Zunächst müssen die in Abschnitt 2.1.2.3 besprochenen System Properties mit Hilfe der Umgebungsvariablen CATALINA_OPTS gesetzt sein. Die Datei $MOA_SPSS_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.1.2.4.3 Prüfen des erfolgreichen Starts
-
-

Ein erfolgreicher Start des MOA SP/SS Webservices ist an folgender Log-Meldung ersichtlich:
-

-
-
INFO | 18 10:09:45,155 | main | TID=startup NID=<null> MSG=MOA Konfiguration erfolgreich geladen
-
-

Bei leichten Fehlern in der Konfiguration geben WARN Log-Meldungen unmittelbar davor Aufschluss über fehlerhafte Konfigurations-Einträge. - Nach dem Starten von Tomcat steht das MOA SP/SS Webservice für die Server-Signatur und Signatur-Prüfung unter den Endpunkten

-
http://<host>:<port>/moa-spss/services/SignatureCreation
-
-

bzw. + +

3 +Komponenten

+ +

3.1 +Der Filter SL2MOAFilter

+ +

Die Klasse SL2MOAFilter +ist ein +Filter, +der einerseits +den HttpServletRequest +verändert, bevor er an das Servlet MOAServlet +weitergeleitet wird, und andererseits den HttpServletResponse +verändert, nachdem er vom Servlet MOAServlet +bearbeitet wurde.

+ +

Der HttpServletRequest +enhält ja zunächst den Request zur Prüfung +der XML-Signatur in einem Format entsprechend der Spezifikationen +zur österreichischen Bürgerkarte in der +Version 1.2 (SL-Request). Das MOAServlet +erwartet sich jedoch den +Request zur Prüfung der XML-Signatur in einem Format +entsprechend der Webservice-Schnittstelle für das Basismodul +MOA SP (MOA-Request). Aufgabe des SL2MOAFilters +ist es daher, vor der Ausführung des MOAServlets +für eine passende Umsetzung des SL-Requests in den +entsprechenden MOA-Request zu sorgen. Zur Erfüllung dieser +Aufgabe bedient sich der SL2MOAFilter +der Klasse SL2MOA, +in der die +Request-Transformation gekapselt ist.

+ +

Das MOAServlet +würde dann die Antwort des Basismoduls MOA SP in einem Format +entsprechend der Webservice-Schnittstelle für das Basismodul +MOA SP (MOA-Response) retournieren. Die Anwendung, die das MOAServlet +aufruft, erwartet sich jedoch die Antwort auf den Request zur +Prüfung +der XML-Signatur in einem Format entsprechend der Spezifikationen +zur österreichischen Bürgerkarte in der +Version 1.2 (SL-Response). Aufgabe des SL2MOAFilters +ist es daher, nach der Ausführung des MOAServlets +für eine passende Umsetzung der MOA-Response in die +entsprechende SL-Response zu sorgen. Zur Erfüllung +dieser +Aufgabe bedient sich der SL2MOAFilter +der Klasse MOA2SL, +in der die +Response-Transformation gekapselt ist.

+ +

Eine weitere Aufgabe der Klasse SL2MOAFilter +ist es schließlich, die JSP-Seite resultoverview.jsp +einzubinden, die für eine benutzertaugliche HTML-Darstellung +der SL-Response sorgt. Diese benutzertaugliche Darstellung wird dann +tatsächlich als finales Resultat des MOAServlets +an die Anwendung zurückübermittelt. Bevor die +JSP-Seite eingebunden wird, erzeugt SL2MOAFilter +Java Beans aus den Informationen der SL-Response und speichert sie im +Request Scope bzw. Session Scope. Diese Java Beans werden dann von der +JSP-Seite zum +Aufbau der benutzertauglichen HTML-Darstellung herangezogen. +Für weitere Informationen zur JSP-Seite sowie zu den von ihr +verwendeten Java Beans siehe Abschnitt 3.3.

-
http://<host>:<port>/moa-spss/services/SignatureVerification
-
-

zur Verfügung. Die Verfügbarkeit des Services können Sie einfach überprüfen, indem Sie die Endpunkte mit einem Web-Browser aufgerufen; dies sollte nach erfolgreichem Start zur Anzeige einer Informationsseite führen.

-

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

-
FATAL | 18 10:17:03,475 | main | TID=startup NID=<null> 
  MSG=Fehler beim Lesen der MOA Konfiguration: das Service steht nicht zur Verfügung
-
-In diesem Fall geben die WARN bzw. ERROR Log-Meldungen unmittelbar davor Aufschluss über den genaueren Grund. -

2.1.2.5 Änderung der Konfiguration im laufenden Betrieb

-

Sie können die Konfiguration für MOA SP/SS im laufenden Betrieb aktualisieren, in dem Sie mittels eines Web-Browsers folgende URL aufrufen:

-
 http://<host>:<port>/moa-spss/ConfigurationUpdate
-

Damit dies funktioniert, muss in der Konfiguration von Tomcat ein spezieller Benutzer sowie eine spezielle Benutzerrolle eingerichtet werden (vergleiche Abschnitt 2.1.2.2.3).

-

2.1.3 Logging

-

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

3.2 +Das Servlet MOAServlet

+ +

Die Klasse +MOAServlet ist ein HttpServlet +und als solches für die Kommunikation mit dem Basismodul MOA +SP verantwortlich.

+ +

Das Servlet liest aus dem ServletInputStream +des HttpServletRequests +den MOA SP Request +zur Prüfung der XML-Signatur und sendet diesen XML-Request +unter Verwendung der Webservice-Schnittstelle von MOA SP an das +Basismodul MOA SP.

+ +

Danach liest das Servlet die vom Basismodul MOA SP auf den +Request zur Prüfung der XML-Signatur +rückübermittelte Response und schreibt diese +XML-Response in den ServletOutputStream +der HttpServletResponse.

+ +

Das MOAServlet bedient sich zur Kommunikation mit MOA SP der +Klasse +MOAInvoker, in der die +Funktionalität des Webservice-Clients für MOA SP +gekapselt ist.

+ +

3.3 Die JSP-Seite resultOverview.jsp

+ +

Die JSP-Seite resultOverview.jsp ist +verantwortlich für die Aufbereitung +einer benutzertauglichen HTML-Darstellung der SL-Response, die +das Servlet MOAServlet +im Zusammenspiel mit dem Filter SL2MOAFilter +erzeugt. 

+ +

Die für die Aufbereitung erforderlichen Informationen +werden der JSP-Seite in Form von Java Beans zur Verfügung +gestellt, die zuvor vom SL2MOAFilter +erzeugt worden sind (vergleiche Abschnitt 3.1). +Folgende Java Beans stehen der JSP-Seite zur Verfügung:

+ -

Das MOA SP/SS Webservice verwendet folgende Log-Hierarchien:

+ +

Die JSP-Seite resultOverview.jsp +erzeugt aus den mittels der erwähnten Java Beans zur +Verfügung gestellten Informationen eine HTML-Darstellung. +Diese HTML-Darstellung ist in die folgenden Informationsblöcke +unterteilt:

+ -

Eine für MOA SP/SS passende Konfigurationsdatei für Log4j finden Sie hier. Wird diese Datei als Logging-Konfiguration verwendet, so werden alle Log-Meldungen sowohl in die Konsole, als auch in die Datei moa-spss.log geschrieben.

-

2.1.3.1 Format der Log-Meldungen

-

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

- 
INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=node1 
-  MSG=Starte neue Transaktion: TID=1049225059594-100, Service=SignatureVerification
-
-

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

- -

Der nächste Wert 01 21:25:26,540 gibt den Zeitpunkt an, zu dem die Log-Meldung generiert wurde (in diesem Fall den 1. Tag im aktuellen Monat, sowie die genaue Uhrzeit).

-

Der Wert Thread-3 bezeichnet den Thread, von dem die Anfrage bearbeitet wird.

-

Der Wert von TID gibt die für jede Anfrage eindeutige Transaktions-ID an. Log-Meldungen, die bei der Abarbeitung dieser Anfrage geschrieben werden, enthalten alle einen Hinweis auf die entsprechende Transaktions-ID.

-

Der Wert von NID gibt den Rechner-Knoten an, auf dem das MOA SP/SS Webservice läuft (bei NID=<null> ist dieser Wert nicht konfiguriert, vergleiche Abschnitt 2.1.2.3).

-

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.1.3.2 Wichtige Log-Meldungen

-

Neben den im Abschnitt 2.1.2.4.3 beschriebenen Log-Meldungen, die anzeigen, ob das Service ordnungsgemäß gestartet wurde, geben nachfolgenden Log-Meldungen Aufschluss über die Abarbeitung von Anfragen.

-

Die Entgegennahme einer Anfrage wird angezeigt durch: - -

- 
INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=<null> 
-  MSG=Starte neue Transaktion: TID=1049225059594-100, Service=SignatureVerification
-INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=<null> 
-  MSG=Aufruf von Adresse=127.0.0.1
-INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=<null> 
-  MSG=Client-Zertifikat nicht verfügbar
-

Die dritte Log-Meldung besagt, dass für die Abarbeitung dieser Anfrage kein Client-Zertifikat verfügbar ist (entweder, weil die Anfrage über HTTP eingelangt ist, oder weil die SSL Client-Authentisierung nicht eingeschaltet ist). Bei erfolgreicher SSL Client-Authentisierung, gibt beispielsweise folgende Log-Meldung Informationen über das Client-Zertifikat aus: - 

INFO | 12 13:58:08,772 | Thread-10 | TID=1045054687159-2 NID=<null> 
-  MSG=Client-Zertifikat: Subject=CN=Testuser, OU=MOA, O=BRZ, L=Vienna, ST=Vienna, C=AT, 
-  Serial=1.039.104.204, Issuer=CN=TestCA, OU=MOA, O=BRZ, L=Vienna, ST=Vienna, C=AT
-

Eine erfolgreich abgearbeitete Anfrage wird angezeigt durch: -

- 
INFO | 01 21:25:53,168 | Thread-3 | TID=1049225059594-106 NID=<null> 
-  MSG=Anfrage erfolgreich abgearbeitet
-

Ein Fehler beim Abarbeiten der Anfrage wird angezeigt durch:

- 
INFO | 01 21:25:27,642 | Thread-3 | TID=1049225059594-100 NID=<null> 
-  MSG=Fehler beim Abarbeiten der Anfrage
-
-

In diesem Fall gibt der mitgeloggte Stacktrace Auskunft über die Art des Fehlers. Der Aufrufer des MOA SP/SS Webservices bekommt einen Fehlercode sowie eine kurze Beschreibung des Fehlers als Antwort zurück.

-

Die Tatsächlich übertragenen Anfragen bzw. Antworten werden aus Effizienzgründen nur im Log-Level DEBUG angezeigt.

-
-

2.2 Erweiterungsmöglichkeiten

-

Ausgehend von der Basisinstallation können die optionalen Erweiterungen, die in den nachfolgenden Abschnitten beschrieben werden, unabhängig und in beliebiger Kombination aufgesetzt werden.

-

2.2.1 Vorgeschalteter Webserver

-

2.2.1.1 Microsoft Internet Information Server (MS IIS)

-

Den MOA SP/SS Webservices kann optional ein MS IIS vorgeschaltet sein. In diesem Fall übernimmt der MS IIS die HTTP- bzw. HTTPS-Kommunikation mit dem Aufrufer des Webservices. Die Kommunikation zwischen MS IIS und dem in Tomcat eingerichteten MOA SP/SS Webservice wird durch Jakarta mod_jk durchgeführt. Die angeführten Konfigurationsschritte gehen von einer MS IIS Standard-Installation aus.

-
2.2.1.1.1 Konfiguration von Jakarta mod_jk im MS IIS
-

Für die Kommunikation des MS IIS mit dem im Tomcat eingerichteten MOA SP/SS Webservice wird das ISAPI-Modul von Jakarta mod_jk im MS IIS installiert und konfiguriert. Eine detaillierte Installations- und Konfigurationsanleitung gibt das mod_jk IIS HowTo. Beispiele für workers.properties und uriworkermap.properties Dateien liegen im Verzeichnis $MOA_SPSS_INST/tomcat bei.

-
2.2.1.1.2 Konfiguration von Tomcat
-

Damit Tomcat die Aufrufe entgegennehmen kann, die von MS IIS mittels Jakarta mod_jk weiterleitet werden, muss in $CATALINA_HOME/conf/server.xml der AJP 1.3 Connector aktiviert werden. Im Gegenzug können die Konnektoren für HTTP und HTTPS deaktiviert werden. Das geschieht am einfachsten durch Ein- bzw. Auskommentieren der entsprechenden Connector Konfigurations-Elemente in dieser Datei. Die Datei $MOA_SPSS_INST/tomcat/server.mod_jk.xml enthält eine Konfiguration, die ausschließlich den Port für den AJP 1.3 Connector offen lässt.

-
2.2.1.1.3 Konfiguration von SSL
-

Die Dokumentation zum Einrichten von SSL auf dem MS IIS steht nach Installation des IIS unter http://localhost/iisHelp/ oder aber auch auf den Websiten vo Mircrosoft zur Verfügung.

-

2.2.1.2 Apache

-

Den MOA SP/SS Webservices kann ein Apache Webserver vorgeschaltet sein. Das Prinzip funktioniert wie bei MS IIS, auch hier wird Jakarta mod_jk für die Kommunikation zwischen Webserver und Tomcat eingesetzt. Die angeführten Konfigurationsschritte gehen von einer Standard-Installation des Apache Webservers aus und sind ident für die Versionen 1.3.x und 2.0.x.

-
2.2.1.2.1 Konfiguration von Jakarta mod_jk im Apache
-

Um das MOA-SPSS Webservice hinter einem Apache Webserver zu betreiben, ist die Konfiguration des Apache-Moduls mod_jk erforderlich. Eine detaillierte Installations- und Konfigurationsanleitung gibt das mod_jk Apache HowTo. Ein Beispiel für eine workers.properties Datei liegt im Verzeichnis $MOA_SPSS_INST/tomcat bei.

-

Um das MOA SP/SS Webservice dem Apache Webserver bekannt zu machen, sind zumindest folgende Einträge im globalen Kontext der Apache-Konfigurationsdatei notwendig:

- 
LoadModule jk_module /usr/lib/apache/mod_jk.so
AddModule jk_module
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkWorkersFile conf/workers.properties 
JkMount /moa-spss/* moaworker
-

Die Pfad- und Dateinamen können je nach existierender Apache Installation geringfügig variieren.

-
2.2.1.2.2 Konfiguration von Tomcat
-

Die Konfiguration von Tomcat ist analog zu Abschnitt 2.2.1.1.2 durchzuführen.

-
2.2.1.2.2 Konfiguration von SSL mit mod_SSL
-

Apache kann in Verbindung mit mod_SSL als SSL-Endpunkt für das MOA SP/SS Webservice fungieren. In diesem Fall entfällt die SSL-Konfiguration in Tomcat, da Apache und Tomcat auch im Fall von SSL Daten via mod_jk austauschen. Eine detaillierte Installations- und Konfigurationsanleitung enthält die Online-Dokumentation von mod_SSL.

-

Bei der Verwendung von Client-Authentisierung muss darauf geachtet werden, dass mod_ssl die HTTP-Header mit den Informationen über das Client-Zertifikat exportiert. Dies wird durch Angabe der folgenden Option in der Apache-Konfiguration erreicht:

- 
SSLOptions +ExportCertData +StdEnvVars
-

Je nach vorhandener SSL-Konfiguration des Apache Webservers kann diese Option im globalen Kontext, im Kontext des Virtual Hosts oder im Kontexts eines Verzeichnisses spezifiziert werden.

-

2.2.2 Datenbank

-

Die MOA SP/SS Module können eine Datenbank zum Archivieren von Certificate Revocation Lists (CRLs), sowie zum Abspeichern von Log-Meldungen verwenden. In beiden Fällen wird eine installierte und konfigurierte Datenbank vorausgesetzt.

-

2.2.2.1 PostgreSQL

-

Eine detaillierte Übersicht über die Installation und Konfiguration von PostgreSQL gibt die Online-Dokumentation.

-

Bitte beachten Sie: Eine Möglichkeit, PostgreSQL unter MS Windows zu installieren, besteht darin, Cygwin mit dem PostgreSQL-Package zu installieren. Alternative Installationsvarianten werden auf dieser Seite angeführt.

-
2.2.2.1.1 Anlegen eines Benutzers und einer Datenbank für MOA SP/SS
-

Damit die MOA SP/SS Module eine Verbindung zu PostgreSQL aufbauen kann, müssen der Name eines PostgreSQL-Benutzers und einer PostgreSQL-Datenbank bekannt sein. Sollten diese nicht vorhanden sein, kann mit folgenden Kommandos ein Benutzer namens moa und eine Datenbank namens moadb angelegt werden:

- 
createuser -U postgres -d -A -P moa
createdb -U moa moadb
-

Da die MOA SP/SS Module über JDBC mit der Datenbank kommunizieren, ist in der Folge die Angabe einer JDBC-URL notwendig, welche die Verbindungsparameter enthält. Wurden der Benutzer und die Datenbank wie im obigen Beispiel angelegt, ist folgende JDBC-URL anzugeben (Annahme: als Passwort für den Benutzer moa wurde moapass gewählt):

- 
 jdbc:postgresql://host/moadb?user=moa&password=moapass
-

Die Zeichen jdbc:postgresql:// sind unveränderliche Bestandteile einer PostgreSQL JDBC-URL. host gibt den Rechner an, auf dem PostgreSQL läuft. moadb identifiziert den Namen der Datenbank. Über die Parameter user= und pass= werden Benutzername und Passwort für den DB-User bekanntgegeben.

-
2.2.2.1.2 Archivierung von CRLs
-

Zum Archivieren von CRLs müssen in der MOA SP/SS Konfigurationsdatei die Kinder des Elements cfg:MOAConfiguration/cfg:SignatureVerification/cfg:CertificateValidation/cfg:RevocationChecking/cfg:Archiving entsprechend - konfiguriert werden:

- -

Vergleiche auch Abschnitt 2.3.1.3.4 im - Konfigurationshandbuch.

-
2.2.2.1.3 Logging
-

Für das Logging in eine PostgreSQL Datenbank mittels Jakarta Log4j muss zunächst eine Tabelle für die Log-Meldungen angelegt werden. Dies kann mit folgendem SQL-Statement erreicht werden:

- 
 create table spss_log (log_time timestamp, log_level varchar(5), log_msg text);
-

Damit Log4j die Log-Meldungen in diese Datenbanktabelle schreibt, muss die Log4j-Konfiguration adaptiert werden. Die mit MOA SP/SS mitgelieferte, beispielhafte Log4j-Konfiguration enthält bereits die notwendigen Einträge für das Logging in eine PostgreSQL Datenbank, die jedoch standardmäßig ausgeschaltet sind.

-

Wie beim Caching von CRLs ist auch hier die Angabe einer JDBC-URL notwendig, damit die MOA SP/SS Module eine Verbindung zur Datenbank aufnehmen können.

-

Bitte beachten Sie: Bei Tests hat sich das Logging in eine Datenbank mit Jakarta Log4j als Performance-Engpass herausgestellt. Es wird deshalb empfohlen, dieses Feature mit Bedacht einzusetzen.

-

2.2.2.2 Andere Datenbanken

-

Über die generische Anbindung JDBC können auch andere Datenbanken für die Archivierung von CRLs bzw. für die Speicherung der Log-Meldungen eingesetzt werden. Hinweise zu bestimmten Datenbanken finden Sie in den FAQ.

-

Die in Abschnitt 2.2.2.1 gemachten Angaben zu Archivierung von CRLs bzw. zur Speicherung von Log-Meldungen gelten sinngemäß.

-

2.2.3 Hardware Security Module (HSM)

-

MOA SS kann für die Erstellung von Signaturen auf die Dienste eines HSM zurückgreifen. Voraussetzung dafür ist, dass für das HSM eine Implementierung der Schnittstelle PCKS#11 (PKCS#11-Bibliothek) angeboten wird.

-

Für die Einbindung des HSM in MOA SS müssen zunächst die Bibliotheken aus $MOA_SPSS_INST/pkcs11 in ein beliebiges Verzeichnis kopiert werden, welches dann in den Libray-Pfad des jeweiligen Betriebssystems aufgenommen werden muss (Windows: Umgebungsvariable PATH; Linux: Umgebungsvariable LD_LIBRARY_PATH).

-

Der Name der für das HSM spezifischen PKCS#11-Bibliothek muss in der Konfigurationsdatei eingetragen werden (vergleiche Abschnitt 2.2.1.1 des Konfigurationshandbuchs).

-

3 Klassenbibliothek

-

Dieser Abschnitt beschreibt die Verwendung von MOA SP/SS als Klassenbibliothek. Im ersten Unterkapitel wird eine minimale Basisinstallation beschrieben. Das zweite Unterkapitel zeigt eine Reihe von optionalen Erweiterungsmöglichkeiten auf.

-

3.1 Basisinstallation

-

3.1.1 Einführung

-

Die Basisinstallation der Klassenbibliothek stellt einerseits die minimalen Anforderungen für den Einsatz von MOA SP/SS als Klassenbibliothek dar, andererseits dient sie als Ausgangspunkt für optionale Erweiterungsmöglichkeiten.

-

Folgende Software ist Voraussetzung für die Basisinstallation der Klassenbibliothek:

- -

3.1.2 Vorbereitung

-

Die folgenden Schritte dienen der Vorbereitung der Installation.

-
-
Installation von J2SE SDK
-
Installieren Sie J2SE 1.3.1 SDK oder J2SE 1.4.2 SDK oder J2SE 5.0 SDK in ein beliebiges Verzeichnis. Wir empfehlen die Installation von J2SE 5.0 SDK. Das Wurzelverzeichnis der J2SE SDK Installation wird im weiteren Verlauf als $JAVA_HOME bezeichnet.
-
Entpacken der MOA SP/SS Klassenbibliotheks-Distribution
-
Entpacken Sie die Datei moa-spss-1.2.x-lib.zip in ein beliebiges Verzeichnis. Dieses Verzeichnis wird im weiteren Verlauf als $MOA_SPSS_INST bezeichnet.
-
Installation der Krypographiebibliotheken von SIC/IAIK
-
-

Die Installation der Kryptographiebibliotheken von SIC/IAIK ist abhängig vom eingesetzten J2SE SDK:

-
-
J2SE 1.3.1 SDK
-
Kopieren Sie alle Dateien aus dem Verzeichnis $MOA_SPSS_INST/ext13 in das Verzeichnis $JAVA_HOME/jre/lib/ext.
-
J2SE 1.4.2 SDK oder JSE 5.0 SDK
-
Kopieren Sie alle Dateien aus dem Verzeichnis $MOA_SPSS_INST/ext14 in das Verzeichnis $JAVA_HOME/jre/lib/ext. Zusätzlich müssen Sie die Rechtedateien Ihres J2SE 1.4.2 SDK bzw. J2SE 5.0 SDK austauschen. Laden Sie dazu die Unlimited Strength Jurisdiction Policy Files von der J2SE 1.4.2 SDK Downloadseite bzw. J2SE 5.0 SDK Downloadseite und folgen Sie der darin enthaltenen Installationsanweisung.
-
-
-
-

3.1.3 Verwendung

-

Um die MOA SP/SS Klassenbibliothek in einer Applikation verwenden zu können, müssen die mit MOA SP/SS ausgelieferten Bibliotheken in den Java Klassenpfad der Applikation eingebunden werden.

-

Die nachfolgende Tabelle listet diese Klassenbibliotheken auf; die Einträge in der Spalte Dateien sind relativ zum Verzeichnis $MOA_SPSS_INST zu interpretieren.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
KlassenbibliothekVersionDateien
MOA SP/SS1.2.x  moa-spss.jar, moa-common.jar
MOA IAIK1.0.7 

lib/iaik_moa_full.jar, lib/iaik_Pkcs11Wrapper.jar, - lib/iaik_cms.jar, lib/iaik_ixsil.jar

-
JAXP1.2_01  lib/jaxp-api.jar, lib/sax.jar, lib/dom.jar
Xerces-J2.4.0  lib/xercesImpl.jar, lib/xmlParserAPIs.jar
Xalan-J2.5.1 

lib/xalan.jar

-

Bitte beachten Sie: Wenn Sie J2SE 1.4.2 JRE oder J2SE 5.0 JRE verwenden, müssen Sie diese Bibliothek der Java VM als endorsed bekanntgeben. Sie können dies tun, indem Sie entweder

-
    -
  • die Bibliothek in das (ggf. vorher anzulegende) Verzeichnis $JAVA_HOME/jre/lib/endorsed/ kopieren; oder
    • -
  • die System Property java.endorsed.dirs verwenden, und als Wert den Pfad zu jenem Verzeichnis angeben, in dem Sie die Bibliothek vorhalten (also z.B. java.endorsed.dirs=c:/mylibdir).
    • -
Jaxen1.0  lib/jaxen-core.jar, lib/jaxen-dom.jar, lib/saxpath.jar
Commons-Logging1.0.4  lib/commons-logging-api.jar, lib/commons-logging.jar
Log4j1.2.7  lib/log4j-1.2.7.jar
Commons-Discovery0.2  lib/commons-discovery.jar
JSSE1.0.3_01 

Diese Bibliotheken benötigen Sie nur, wenn Sie J2SE 1.3.1 verwenden:

-

lib/ext13/jsse.jar, lib/ext13/jcert.jar, lib/ext13/jnet.jar

-

Bitte beachten Sie: Diese Bibliotheken benötigen Sie nur, wenn Sie J2SE 1.3.1 verwenden.

Postgres JDBC27.3 

lib/pg73jdbc2.jar

-

Bitte beachten Sie: Wenn Sie keine Datenbank für MOA SP/SS verwenden (vergleiche 2.2.2), benötigen Sie diese Bibliothek nicht.

- -

3.1.4 Logging

-

Die MOA SP/SS Klassenbibliothek verwendet Jakarta Log4j für die Ausgabe von Log-Meldungen am Bildschirm bzw. in Log-Dateien. Die im Abschnitt 2.1.3 gemachten Aussagen lassen sich großteils auf den Einsatz der MOA SP/SS Klassenbibliothek übertragen.

-

3.2 Erweiterungsmöglichkeiten

-

Die im Abschnitt 2.2 angeführten Erweiterungsmöglichkeiten für die MOA SP/SS Webservices gelten in analoger Weise auch für die Klassenbibliothek.

-

A Referenzierte Software

-

Auf folgende Software-Pakete wird in diesem Handbuch verwiesen:

- - - - - - - - - - - - - - - - - - - - - - - - - + +

Ein Beispiel für die resultierende HTML-Darstellung +befindet sich hier.

+ +

3.4 Das Servlet HashInputDataServlet

+ +

Das Servlet HashInputServlet +ist +für die Verfügbarkeit der von der geprüften +XML-Signatur gesicherten Dokumente verantwortlich. 

+ +

In der HTML-Aufbereitung der SL-Response, die von der +JSP-Seite resultOverview.jsp erzeugt wird, +(vergleiche Abschnitt +3.3) befinden sich Links auf alle gesicherten Dokumente. +Diese Links führen jeweils auf das Servlet HashInputServlet. 

+ +

Das Servlet entnimmt aus der aufgerufenen URL die Parameter +zum Auffinden des Session Scopes sowie die fortlaufende Nummer des +gesicherten Dokuments. Im Session Scope ist als Attribut die in Abschnitt 3.3 +erwähnte DataInfoBean: +gespeichert, die alle notwendigen Informationen enthält, damit +das Servlet das angefragte gesicherte Dokument aus dem Filesystem lesen +und als Ergebnis an den Browser zurückliefern kann. Je nach +dem, ob es sich beim gesicherten Dokument um ein SLXHTML-Dokument +handelt oder nicht, wird der Content-Type Header der HTTP Response an +den Browser passend gesetzt.

+ +

3.5 +Das Servlet ReturnServlet

+ +

Das Servlet ReturnServlet +ist nach Quittierung der HTML-Darstellung zur geprüften +XML-Signatur durch den Benutzer für die Weiterleitung der +SL-Response an den DataURL-Server sowie für die Weiterleitung +der daraus resultierenden Antwort des DataURL-Servers an den Benutzer +verantwortlich.

+ +

Damit verhält sich MOA SL genau wie in der +Spezifikation Transportprotokolle +Security-Layer (Teil der Spezifikationen +zur österreichischen Bürgerkarte in der +Version 1.2) in Abschnitt +3.2.3 für den Fall 5e beschrieben ist: Wenn der +Benutzer die HTML-Aufbereitung der Ergebnisse der geprüften +XML-Signatur gesichtet hat und durch Verfolgung des darin enthaltenen +Links quittiert, sendet das ReturnServlet +die SL-Response an den DataURL-Server. Die URL des DataURL-Servers +wurde von der Anwendung im ursprünglichen Request an das MOAServlet +als Formular-Parameter angegeben. Der DataURL-Server antwortet auf das +Eintreffen der SL-Response mit einem HTTP-Response an das ReturnServlet, +diese wird vom ReturnServlet +als Antwort auf das Quittieren der HTML-Darstellung an den Browser +weitergeleitet. 

+ +

Nachdem mit diesem Schritt die Bearbeitung der zur +Prüfung übermittelten XML-Signatur durch MOA-SL +abgeschlossen ist, wird am Ende des ReturnServlet +die Session und damit alle gespeicherten Informationen zur +geprüften XML-Signatur gelöscht. 

+ +

3.6 +Die Klasse URLRewriter

+ +

Die Klasse URLRewriter +ist +für das Umschreiben von URLs verantwortlich die in der +HTML-Aufbereitung der SL-Response enthalten sind, die dem Benutzer in +seinem Webbrowser angezeigt wird.

+ +

MOA SL kann so konfiguriert werden, dass die in der +HTML-Aufbereitung der SL-Response enthaltenen +URLs nicht direkt +auf +Ressourcen von MOA SL (z.B. die von der Signatur gesicherten +Dokumente), sondern auf einen Rewrite-Proxy +verweisen. Die URL auf die eigentliche Ressource von MOA SL ist in dem +umgeschriebenen Link als URL-Parameter kodiert. Der Rewrite-Proxy sorgt +für die Umsetzung des aus dem umgeschriebenen Link +resultierenden +Requests an ihn selbst in einen Request an MOA SL. 

+ +

Sinnvoll ist diese Konfigurationsvariante dann, wenn MOA SL +nicht direkt vom Internet aus erreichbar sein soll, sondern nur auf dem +Umweg über einen dedizierten Webserver, dem Rewrite-Proxy.

+ +

Die Methode rewrite der Klasse URLRewriter +wird bei der Erstellung der HTML-Aufbereitung der SL-Response durch die +JSP-Seite resultOverview.jsp jedenfalls +aufgerufen; die Entscheidung, ob die in die Methode übergebene +URL tatsächlich umgeschrieben wird oder nicht, entscheidet die +Methode auf Grund der Konfigurationseinstellungen von MOA SL.

+ +

3.7 +Der Deployment Descriptor web.xml

+

+Im Deployment Descriptor web.xmldes +Web Archives (WAR-File) von MOA SL sind im Wesentlichen folgende +Konfigurationen eingerichtet, die im Normalfall nicht verändert +werden müssen:

+ + +

4 +Zusammenspiel der Komponenten

+ +

4.1 Basisablauf

+

Die nachfolgende Grafik stellt das Zusammenspiel der Komponenten aus Abschnitt 3 mit dem Anwender und dem DataURL-Server dar.

+

Zusammenspiel der Komponenten - Basisablauf

+
NameBeschreibung
Apache Tomcat 4.1.x Servlet-Container des Apache Jakarta Projekts in der Version 4.1.x
J2SE 1.3.1 SDK/JRE Java 2 Standard Edition in der Version 1.3.1 (Software Development Kit bzw. Java Runtime Environment)
J2SE 1.4.2 SDK/JREJava 2 Standard Edition in der Version 1.4.2 (Software Development Kit bzw. Java Runtime Environment)
J2SE 5.0 SDK/JRE Java 2 Standard Edition in der Version 5.0 (Software Development Kit bzw. Java Runtime Environment)
Jakarta Log4J Logging Framework des Apache Jakarta Projekts
+ + + + + + + + + + + + + +
1, 2 +

Prüfung der Signatur: Anfrage wird eigentlich an MOAServlet gerichtet, durch die Filter-Konfiguration über den Deployment-Descriptor web.xml wird jedoch vorher und nachher der SL2MOAFilter dazwischengeschalten. Die Aufbereitung der HTML-Darstellung der SL-Response wird vom SL2MOAFilter an die JSP-Seite resultOverview.jsp delegiert.

+
3,4 +

Über die HTML-Ansicht der SL-Response kann der Anwender +die einzelnen, von der XML-Signatur gesicherten Dokumente abrufen. +Die Links für die Dokumente verweisen auf das HashInputServlet, die Zuordnung im Servlet passiert über URL-Parameter (Session-ID, fortlaufende Nummer des Dokuments).

+
5, 6, 7, 8 +

In Schritt 5 quittiert der Anwender die HTML-Darstellung der +SL-Response. Das Quittieren funktioniert über einen Link in der +HTML-Darstellung, der auf das ReturnServlet verweist. Das ReturnServlet +sendet die SL-Response an den DataURL-Server. Der DataURL-Server +antwortet entsprechend auf die übermittelte SL-Response; diese +Antwort wird vom ReturnServlet unverändert an den Antwender weitergeleitet.

+
+

4.2 Ablauf mit Rewrite-Proxy

+Die nachfolgende Grafik stellt das Zusammenspiel der Komponenten aus +Abschnitt 3 mit dem Anwender und dem DataURL-Server dar, wobei die +Anfragen vom Anwender nicht direkt an MOA SL, sondern indirekt +über einen Rewrite-Proxy gestellt werden.
+
Zusemmenspiel der Komponenten - mit Rewrite-Proxy
+
+ + + + + + + + + + + + + + + +
1, 2 +

Prüfung der Signatur: Anfrage wird eigentlich an MOAServlet gerichtet, durch die Filter-Konfiguration über den Deployment-Descriptor web.xml wird jedoch vorher und nachher der SL2MOAFilter dazwischengeschalten. Die Aufbereitung der HTML-Darstellung der SL-Response wird vom SL2MOAFilter an die JSP-Seite resultOverview.jsp delegiert. Die Anfrage des Anwenders wird nicht direkt an das MOAServlet gerichtet, sondern über den Rewrite-Proxy, der die Anfrage-URL passend umschreibt.

+
3,4 +

Über +die HTML-Ansicht der SL-Response kann der Anwender die einzelnen, von +der XML-Signatur gesicherten Dokumente abrufen. Die Links für die +Dokumente verweisen nicht direkt auf das HashInputServlet, sondern zunächst auf den Rewrite-Proxy, der die Links passend auf das HashInputServlet umsetzt. Die Zuordnung im Servlet passiert über URL-Parameter (Session-ID, fortlaufende Nummer des Dokuments).

+
5, 6, 7, 8 +

In +Schritt 5 quittiert der Anwender die HTML-Darstellung der SL-Response. +Das Quittieren funktioniert über einen Link in der HTML-Darstellung, +der nicht direkt auf das ReturnServlet verweist, sondern zunächst auf den Rewrite-Proxy, der die Links passend auf das ReturnServlet  umsetzt. Das ReturnServlet +sendet die SL-Response an den DataURL-Server. Der DataURL-Server +antwortet entsprechend auf die übermittelte SL-Response; diese Antwort +wird vom ReturnServlet unverändert an den Antwender weitergeleitet.

+
+
+
-- cgit v1.2.3