From ab3d4fc97d673afce126e62be160c2feb4e6e588 Mon Sep 17 00:00:00 2001 From: "(no author)" <(no author)@d688527b-c9ab-4aba-bd8d-4036d912da1d> Date: Mon, 18 Dec 2006 14:17:02 +0000 Subject: This commit was manufactured by cvs2svn to create tag 'Build_ID-1_3_3'. git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/tags/Build_ID-1_3_3@757 d688527b-c9ab-4aba-bd8d-4036d912da1d --- spss.slinterface/handbook/common/LogoBKA.png | Bin 8062 -> 0 bytes spss.slinterface/handbook/common/LogoMoa4c.jpg | Bin 45624 -> 0 bytes spss.slinterface/handbook/common/LogoMoaBw.jpg | Bin 41375 -> 0 bytes spss.slinterface/handbook/common/MOA.css | 300 ----- spss.slinterface/handbook/constraints.txt | 6 - spss.slinterface/handbook/index.html | 41 - .../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 -------------------- .../handbook/system/images/Zusammenspiel.VSD | Bin 138240 -> 0 bytes .../handbook/system/images/Zusammenspiel.mit.png | Bin 48649 -> 0 bytes .../handbook/system/images/Zusammenspiel.ohne.png | Bin 36106 -> 0 bytes spss.slinterface/handbook/system/system.html | 512 -------- 15 files changed, 2210 deletions(-) delete mode 100644 spss.slinterface/handbook/common/LogoBKA.png delete mode 100644 spss.slinterface/handbook/common/LogoMoa4c.jpg delete mode 100644 spss.slinterface/handbook/common/LogoMoaBw.jpg delete mode 100644 spss.slinterface/handbook/common/MOA.css delete mode 100644 spss.slinterface/handbook/constraints.txt delete mode 100644 spss.slinterface/handbook/index.html 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 delete mode 100644 spss.slinterface/handbook/system/images/Zusammenspiel.VSD delete mode 100644 spss.slinterface/handbook/system/images/Zusammenspiel.mit.png delete mode 100644 spss.slinterface/handbook/system/images/Zusammenspiel.ohne.png delete mode 100644 spss.slinterface/handbook/system/system.html (limited to 'spss.slinterface/handbook') diff --git a/spss.slinterface/handbook/common/LogoBKA.png b/spss.slinterface/handbook/common/LogoBKA.png deleted file mode 100644 index 6a92647fd..000000000 Binary files a/spss.slinterface/handbook/common/LogoBKA.png and /dev/null differ diff --git a/spss.slinterface/handbook/common/LogoMoa4c.jpg b/spss.slinterface/handbook/common/LogoMoa4c.jpg deleted file mode 100644 index a1102090b..000000000 Binary files a/spss.slinterface/handbook/common/LogoMoa4c.jpg and /dev/null differ diff --git a/spss.slinterface/handbook/common/LogoMoaBw.jpg b/spss.slinterface/handbook/common/LogoMoaBw.jpg deleted file mode 100644 index 5a31e3e15..000000000 Binary files a/spss.slinterface/handbook/common/LogoMoaBw.jpg and /dev/null differ diff --git a/spss.slinterface/handbook/common/MOA.css b/spss.slinterface/handbook/common/MOA.css deleted file mode 100644 index b8428d58d..000000000 --- a/spss.slinterface/handbook/common/MOA.css +++ /dev/null @@ -1,300 +0,0 @@ -body -{ - font-family: "Times New Roman", Times, serif; - font-size: medium; - font-weight: normal; - margin-left: 2.5em; - margin-right: 2.5em; -} - -p -{ - margin-top: 0pt; - margin-bottom: 0.5em; - text-align: justify -} - -pre -{ - font-family: "Courier New", monospace; - font-size: 90%; - background-color: #cccccc; - color: #000000; - margin-left:1.5%; - margin-right:1.5%; - margin-top: 1em; - margin-bottom: 1em; - border: #008000 none; -} - -hr -{ - color: #000080; - background-color: #000080; - margin-top: 0.5em; - margin-bottom: 0.5em; -} - -table.fixedWidth -{ - width: 97%; - margin-left:1.5%; - margin-right:1.5%; - margin-top: 1em; - margin-bottom: 1em; -} - - -table.varWidth -{ - margin-left:1.5%; - margin-top: 1em; - margin-bottom: 1em; -} - -th -{ - text-align: left; -} - -h1 -{ - color: #000080; - text-align: left; - font-size: 167%; - font-family: Arial, Helvetica, sans-serif; - font-weight: normal -} - -h2 -{ - color: #000080; - font-size: 150%; - font-family: Arial, Helvetica, sans-serif; - font-weight: normal -} - -h3 -{ - color: #000080; - font-size: 133%; - font-family: Arial, Helvetica, sans-serif; - font-weight: normal -} - -h4 -{ - color: #000080; - font-size: 116%; - font-family: Arial, Helvetica, sans-serif; - font-weight: normal -} - -h5 -{ - color: #000080; - font-size: 100%; - font-family: Arial, Helvetica, sans-serif; - font-weight: normal -} - -h6 -{ - color: #000080; - font-size: 83%; - font-family: Arial, Helvetica, sans-serif; - font-weight: normal -} - -code -{ - font-family: "Courier New", Courier, monospace; - font-size: 90%; - color: #000000 -} - -dd -{ - margin-top: 0.8em; - margin-bottom: 0.8em; - text-align: justify - -} - -dt -{ - margin-top: 0.8em; - font-family: Arial, Helvetica, sans-serif; - color: #000080 -} - -ol -{ - margin-top: 0.5em; - margin-bottom: 0.5em -} - -ol.alpha -{ - list-style-type: lower-alpha -} - -li -{ - margin-top: 0.25em; - margin-bottom: 0.25em; - text-align: justify -} - -a:hover -{ - color: #990000 -} - - -.title -{ - text-align: left; - font-size: 167%; - color: #000080; - font-family: Arial, Helvetica, sans-serif; - margin-top: 0.4em; - margin-bottom: 0.4em -} - -.subtitle -{ - text-align: left; - font-size: 133%; - color: #000080; - font-family: Arial, Helvetica, sans-serif; - margin-top: 0.4em; - margin-bottom: 0.4em -} - -.glossaryTerm -{ - font-style: italic; - color: #006699 -} - -.example -{ - font-family: "Courier New", monospace; - background-color: #CCFFFF; - color: #000000; - margin: 0pt 0pt; - border: #008000 none -} - -.schema -{ - font-family: "Courier New", monospace; - background-color: #FFFFCC; - color: #000000; - margin: 0pt 0pt; - border: #008000 none -} - -.documentinfo -{ - font-family: Arial, Helvetica, sans-serif; - font-size: 100%; -} - -.ol-contents -{ - font-size: 100%; - margin-top: 0.0em; - margin-bottom: 0.0em; -} - -.li-contents -{ - font-size: 100%; - margin-top: 0.0em; - margin-bottom: 0.0em; -} - -.logoTitle -{ - text-align: center; - font-size: 133%; - color: #000080; - font-family: Arial, Helvetica, sans-serif; -} - -.logoTable -{ - margin-bottom: 0px; - margin-left: 0px -} - -.superscript -{ - vertical-align: super; - font-size: 66%; -} - -.term -{ - font-style: italic; -} - -.comment -{ - color: #000000; - background: #ffff00; - font-style: italic -} - -.addedErrata12 -{ - color: #FF0000; - background-color: #FFEEEE; - text-decoration: underline -} - -.deletedErrata12 -{ - color: #999999; - background-color: #EEEEEE; - text-decoration: line-through -} - -.added12 -{ - color: #FF0000; - text-decoration: underline -; background-color: #F8F0FF -} - -.deleted12 -{ - color: #999999; - text-decoration: line-through -; background-color: #f8f0ff -} - -.rfc2119Keyword -{ - font-variant: small-caps; - font-style: normal; -} - -.remark { font-style: italic} - -li.faq -{ - margin-top: 1.5em; - margin-bottom: 1.5em; -} - -.faq-question -{ - color: #000080; - font-size: 100%; - font-family: Arial, Helvetica, sans-serif; - font-weight: normal; - margin-bottom: 0.4em; -} diff --git a/spss.slinterface/handbook/constraints.txt b/spss.slinterface/handbook/constraints.txt deleted file mode 100644 index f21d385c8..000000000 --- a/spss.slinterface/handbook/constraints.txt +++ /dev/null @@ -1,6 +0,0 @@ -- Prüfung eines ggf. vorhandenen SL-Manifests wird nicht durchgeführt. - In der Antwort wird der Code 98 zurückgeliefert. - -- Prüfung von dsig-Manifesten escheint nicht in der Auswertungsseite. - -- Bei signiertem XHTML-Dokument wird list-style-image-URL nicht geprüft. \ No newline at end of file diff --git a/spss.slinterface/handbook/index.html b/spss.slinterface/handbook/index.html deleted file mode 100644 index e8b496563..000000000 --- a/spss.slinterface/handbook/index.html +++ /dev/null @@ -1,41 +0,0 @@ - - - - - MOA SL - Übersicht - - - - - - - - - - - - - - - - -
Logo BKAOpen Source
- für das E-Government		Logo MOA
-
- -

MOA: Serverseitige Signaturprüfung (SL)

- -

Übersicht zur Dokumentation der Version 1.0

-
- -
-
Betriebshandbuch
- -
Detaillierte Anleitung für die Installation sowie Erläuterung aller Konfigurationsoptionen.
- -
Systemhandbuch
- -
Beschreibung der einzelnen Komponenten von MOA SL und ihrem Zusammenspiel.
-
- - 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 - - - - - - - - - - - - - - - - - - - - - - - - -
Logo BKAOpen -Source
- -für das E-Government		Logo MOA
- -
-

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

- -

Betriebshandbuch

- -
-

Inhalt

- -
    - -
  1. -

    Übersicht

    - -
    2. - -
  2. Installation -
      - -
    1. Einführung
      2. - -
    2. Vorbereitung
      3. - -
    3. Konfiguration -von Apache Tomcat -
        - -
      1. Konfiguration -des HTTP Connectors
        2. - -
      2. Konfiguration -des HTTPS Connectors
        3. - -
      - -
      4. - -
    4. Einsatz des -MOA SL Webservices in Tomcat
      5. - -
    5. Starten -und Stoppen von Tomcat -
        - -
      1. Unter -Windows
        2. - -
      2. Unter -Unix
        3. - -
      3. Logging -
          - -
        1. Format -der Log-Meldungen
          2. - -
        - -
        4. - -
      4. Prüfen -des erfolgreichen Starts
        5. - -
      - -
      6. - -
    - -
    3. - -
  3. Konfiguration -
      - -
    1. Zentrale -Konfigurationsdatei -
        - -
      1. XML-Schemata -für Request- und Response-Validierung
        2. - -
      2. Arbeitsverzeichnis
        3. - -
      3. Parameter -der verwendeten MOA SP Installation
        4. - -
      4. Umfang der -Prüfberichtseite
        5. - -
      5. Parameter -für das Umschreiben der Links in der Prüfberichtseite
        6. - -
      - -
      2. - -
    2. Layout des -Prüfberichts
      3. - -
    - -
    4. - -
  4. Durchlaufen der -Testapplikation
    5. - -
- -
-

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:

- - - -

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:

- - - -

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 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:

- - - -

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Namelocation.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

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Namelocation.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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Namelocation.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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Nameservice.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

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Nameservice.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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Nameresult.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

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Nameresult.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.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Namerewrite
Erläuterung -

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

- -

der 

- -
Beispiel -

true

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Namerewrite.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

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Namerewrite.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>

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Namerewrite.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

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Namerewrite.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

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Namerewrite.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):

- -

pplikation - Screen 1

- -

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:

- -

pplikation - Screen 2

- -

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:

- -

Testapplikation - Screen 3 -

- -

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

- -

Testapplikation - Screen 4

- -

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.

- - - diff --git a/spss.slinterface/handbook/system/images/Zusammenspiel.VSD b/spss.slinterface/handbook/system/images/Zusammenspiel.VSD deleted file mode 100644 index 0088d5109..000000000 Binary files a/spss.slinterface/handbook/system/images/Zusammenspiel.VSD and /dev/null differ diff --git a/spss.slinterface/handbook/system/images/Zusammenspiel.mit.png b/spss.slinterface/handbook/system/images/Zusammenspiel.mit.png deleted file mode 100644 index 4e7fcda67..000000000 Binary files a/spss.slinterface/handbook/system/images/Zusammenspiel.mit.png and /dev/null differ diff --git a/spss.slinterface/handbook/system/images/Zusammenspiel.ohne.png b/spss.slinterface/handbook/system/images/Zusammenspiel.ohne.png deleted file mode 100644 index 0dc944cb9..000000000 Binary files a/spss.slinterface/handbook/system/images/Zusammenspiel.ohne.png and /dev/null differ diff --git a/spss.slinterface/handbook/system/system.html b/spss.slinterface/handbook/system/system.html deleted file mode 100644 index b911d84c8..000000000 --- a/spss.slinterface/handbook/system/system.html +++ /dev/null @@ -1,512 +0,0 @@ - - - - - - MOA SL - Systemhandbuch - - - - - - - - - - - - - - - - - - - - - - - - -
Logo BKAOpen -Source
- -für das E-Government		Logo MOA
- -
-

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:

- - - -

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

- -

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:

- - - -

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:

- - - -

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

- - - - - - - - - - - - - - - -
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