From 3290db73e02d6a8303a1d9b63b9460b1d1a43504 Mon Sep 17 00:00:00 2001 From: gregor Date: Wed, 28 Feb 2007 16:38:48 +0000 Subject: Dokumentation erstellt. git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/trunk@808 d688527b-c9ab-4aba-bd8d-4036d912da1d --- erecht.client.ss/build.xml | 6 +- erecht.client.ss/handbook/constraints.txt | 5 +- erecht.client.ss/handbook/index.html | 5 +- .../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 erecht.client.ss/handbook/operation/operation.html | 11 +- .../handbook/system/images/Zusammenspiel.VSD | Bin 138240 -> 113152 bytes .../handbook/system/images/Zusammenspiel.png | Bin 0 -> 51511 bytes erecht.client.ss/handbook/system/system.html | 595 ++++----------------- 11 files changed, 131 insertions(+), 491 deletions(-) delete mode 100644 erecht.client.ss/handbook/operation/images/testapp.screen1.png delete mode 100644 erecht.client.ss/handbook/operation/images/testapp.screen2.png delete mode 100644 erecht.client.ss/handbook/operation/images/testapp.screen3.png delete mode 100644 erecht.client.ss/handbook/operation/images/testapp.screen4.png create mode 100644 erecht.client.ss/handbook/system/images/Zusammenspiel.png diff --git a/erecht.client.ss/build.xml b/erecht.client.ss/build.xml index 23bd50bc6..fb8114841 100644 --- a/erecht.client.ss/build.xml +++ b/erecht.client.ss/build.xml @@ -91,7 +91,6 @@ - @@ -124,7 +123,10 @@ - + + + + diff --git a/erecht.client.ss/handbook/constraints.txt b/erecht.client.ss/handbook/constraints.txt index 637a7764e..d6ace776e 100644 --- a/erecht.client.ss/handbook/constraints.txt +++ b/erecht.client.ss/handbook/constraints.txt @@ -2,4 +2,7 @@ von MOA SS nur über die ungesicherte HTTP Webservice-Schnittstelle. - Der E-Recht Signaturclient bietet derzeit keine eigenständige - Benutzerauthentisierung. \ No newline at end of file + Benutzerauthentisierung. + +- Die Behandlung von fehlerhaften Benutzereingaben ist nur sehr rudimentär + ausgeführt. \ No newline at end of file diff --git a/erecht.client.ss/handbook/index.html b/erecht.client.ss/handbook/index.html index 005639b94..3975e8372 100644 --- a/erecht.client.ss/handbook/index.html +++ b/erecht.client.ss/handbook/index.html @@ -4,8 +4,6 @@ MOA SL - Übersicht - - @@ -32,6 +30,5 @@

Beschreibung der einzelnen Komponenten des Signaturclients und ihrem Zusammenspiel.

Beschreibung der Verwendung des Signaturclients.

- +

Beschreibung der einzelnen Komponenten des Signaturclients und ihrem Zusammenspiel.

\ No newline at end of file diff --git a/erecht.client.ss/handbook/operation/images/testapp.screen1.png b/erecht.client.ss/handbook/operation/images/testapp.screen1.png deleted file mode 100644 index 38a226d09..000000000 Binary files a/erecht.client.ss/handbook/operation/images/testapp.screen1.png and /dev/null differ diff --git a/erecht.client.ss/handbook/operation/images/testapp.screen2.png b/erecht.client.ss/handbook/operation/images/testapp.screen2.png deleted file mode 100644 index 45230d5c9..000000000 Binary files a/erecht.client.ss/handbook/operation/images/testapp.screen2.png and /dev/null differ diff --git a/erecht.client.ss/handbook/operation/images/testapp.screen3.png b/erecht.client.ss/handbook/operation/images/testapp.screen3.png deleted file mode 100644 index 7d5db9cad..000000000 Binary files a/erecht.client.ss/handbook/operation/images/testapp.screen3.png and /dev/null differ diff --git a/erecht.client.ss/handbook/operation/images/testapp.screen4.png b/erecht.client.ss/handbook/operation/images/testapp.screen4.png deleted file mode 100644 index 9fe7ee264..000000000 Binary files a/erecht.client.ss/handbook/operation/images/testapp.screen4.png and /dev/null differ diff --git a/erecht.client.ss/handbook/operation/operation.html b/erecht.client.ss/handbook/operation/operation.html index 25b152803..5c70ec453 100644 --- a/erecht.client.ss/handbook/operation/operation.html +++ b/erecht.client.ss/handbook/operation/operation.html @@ -1,8 +1,6 @@ -MOA -SL - Betriebshandbuch - +MOA SL - Betriebshandbuch

E-Recht

E-Recht: Signaturclient für MOA SS, V0.9

@@ -38,8 +36,7 @@ plattformunabh

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

2 Installation

2.1 @@ -74,7 +71,7 @@ des E-Recht Signaturclients für MOA SS ist es zunächst, alle Informationen zu sammeln, die notwendig sind, um ein Rechtsdokument aus E-Recht mit Hilfe des Moduls MOA SS elektronisch zu signieren. Zu diesen -Informationen zählen die XML-Präsentation des XML-Dokuments, der +Informationen zählen die XML-Präsentation des Rechtsdokuments, der Stylesheet für die Umwandlung der XML-Repräsentation in die HTML-Repräsentation, sowie etwaige Bilder und Grafiken, die in der XML- und damit auch @@ -85,7 +82,7 @@ Rechtsdokument herzustellen. Die erstellte Signatur kann wird dem Benutzer abschließend zur lokalen Speicherung zur Verfügung gestellt. Für den Betrieb des E-Recht Signaturclients ist daher die Verfügbarkeit einer -Webservice-Installation von MOA SP in der Version 1.2 oder +Webservice-Installation von MOA SP in der Version 1.3 oder höher Voraussetzung.

Als Logging Toolkit verwendet das MOA SL Webservice Apache Log4j.
diff --git a/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD b/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD index 0088d5109..6ead1bd1c 100644 Binary files a/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD and b/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD differ diff --git a/erecht.client.ss/handbook/system/images/Zusammenspiel.png b/erecht.client.ss/handbook/system/images/Zusammenspiel.png new file mode 100644 index 000000000..16199e4a5 Binary files /dev/null and b/erecht.client.ss/handbook/system/images/Zusammenspiel.png differ diff --git a/erecht.client.ss/handbook/system/system.html b/erecht.client.ss/handbook/system/system.html index e4924f5fb..53682500e 100644 --- a/erecht.client.ss/handbook/system/system.html +++ b/erecht.client.ss/handbook/system/system.html @@ -1,43 +1,15 @@ - - + - MOA SL - Systemhandbuch + - + MOA SL - Systemhandbuch - - - - - - - - - - - - - - - - - - - - -
Open -Source
- -für das E-Government
- -
-
MOA: -Serverseitige Signaturprüfung (SL), V 1.1
- -
Systemhandbuch
+ +

E-Recht

E-Recht: +Signaturclient für MOA SS, V0.9
Systemhandbuch

Inhalt

@@ -45,38 +17,23 @@ Serverseitige Signaturprüfung (SL), V 1.1

-
Einführung
+
Einführung
Überblick
Überblick
Komponenten
@@ -84,446 +41,130 @@ Deployment Descriptor web.xml
Zusammenspiel der Komponenten -
1. Basisablauf
2. Ablauf mit Rewrite-Proxy
+

1 -Einführung

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.

Das Modul E-Recht Signaturclient für MOA SS ist als +plattformunabhängiges Modul ausgelegt, das als Webanwendung +über HTTP 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 +

Dieses Handbuch beschreibt den Aufbau des Moduls. Abschnitt 2 +bietet einen groben Überblick über seine Funktionsweise. Abschnitt 3 beschreibt die einzelnen Komponenenten, aus +denen das Modul aufgebaut ist. Abschnitt 4 schließlich beschreibt das Zusammenspiel der einzelnen Komponenten.

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

Für die Installation und die Konfiguration des E-Recht Signaturclients für MOA SS +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:

- -

Von den XML-Befehlen der Applikationsschnittstelle -Security-Layer wird genau ein Befehl unterstützt, -und zwar jener zur Prüfung von XML-Signaturen (VerifyXMLSignature).
Hinsichtlich der Transportprotokolle -des Security-Layer wird ausschließlich die -HTTP-Bindung unterstützt, wobei für diese Bindung -zusätzlich folgende Einschränkungen gelten: -
- Keine Unterstützung der Formularparameter -RedirectURL und StylesheetURL.
- Verpflichtende Verwendung des Formularparameters -DataURL.
- Keine Unterstützung von Weitergabe-Parametern -und Weitergabe-Headern.
- Keine Referenzierbarkeit von Formularfeldern.
- Hinsichtlich der Ablaufsteuerung laut Abschnitt -3.2.3 wird ausschließlich Fall 5e -unterstützt.
- -
Hinsichtlich der Anzeigeformate des Security-Layer wird -ausschließlich das Standardanzeigeformat -des Security-Layers unterstützt. Liegen die von der -zu prüfenden Signatur gesicherten Daten in einem anderen -Format vor, können diese nicht angezeigt, sondern stattdessen -per Download bezogen werden.

- -

3 +

2 +Überblick

Aufgabe +des E-Recht +Signaturclients für MOA SS ist es zunächst, alle Informationen zu +sammeln, die notwendig sind, um ein Rechtsdokument aus E-Recht mit +Hilfe des Moduls MOA SS elektronisch zu signieren. Zu diesen +Informationen, die vom Benutzer hochgeladen werden müssen, zählen:

die XML-Präsentation des Rechtsokuments;
der +Stylesheet für die Umwandlung der XML-Repräsentation des Rechtsdokuments in seine +HTML-Repräsentation durch MOA SS;
etwaige Bilder und Grafiken, die in der XML- und damit auch +HTML-Repräsentation +referenziert werden.

Liegen +all diese Informationen vor, steuert der +Signaturclient das Modul MOA SS, um die Signatur über das +Rechtsdokument herzustellen. Dazu erzeugt es basierend auf einem +vorkonfigurierten Template und den vom Benutzer hochgeladenen +Informationen einen Signaturerstellungsrequest für MOA SS. Dieser +Signaturerstellungsrequest wird über die Webservice-Schnittstelle von +MOA SS an diesen Dienst übermittelt.

Aus +dem von MOA SS retour übermittleten Signaturerstellungsresponse +extrahiert der Signaturclient die erstellte Signatur und stellt sie dem +Benutzer zum Download bzw. zur lokalen Speicherung zur Verfügung.

Für den Betrieb des E-Recht Signaturclients ist daher +die Verfügbarkeit einer +Webservice-Installation von MOA SP in der Version 1.3 oder +höher Voraussetzung.

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. Zunächst wird eine einfache Transformation des SL-Requests in den MOA-Request durchgeführt, -indem die Namen der XML-Elemente entsprechend angepasst werden. Danach werden am dadurch entstandenen MOA-Request noch folgende Modifikationen -durchgeführt: -

Einfügen eines DateTime Elements in den MOA-Request, wenn bisher kein solches existiert, und wenn in der im MOA-Request - enthaltenen XML Signatur kein Signaturattribut etsi:SigningTime existiert und wenn aus dem E-Recht XML Dokument, das von der - XML-Signatur signiert wird, die Metainformation (Attribut h-created im Wurzelelement erechtdok) des - Erzeugungszeitpunkts des E-Recht XML Dokuments erfolgreich extrahiert werden konnte.
Hinzufügen des Elements ReturnHashInputData, das MOA SP anweist, die Hashinputdaten für jede dsig:Reference - der zu prüfenden XML Signatur als Teil der MOA-Response zu retournieren.
Hinzufügen des verpflichtend anzugebenden Elements TrustProfileID, das MOA SP den Hinweis gibt, welches Vertrauensprofil - für die Evaluierung der Vertrauenswürdigkeit des für die Erstellung der XML Signatur verwendeten Signaturzertifikats verwendet - werden soll.

- -

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:

- -

DataInfoBean: -Enthält -alle notwendigen Informationen zu den von der geprüften -XML-Signatur gesicherten Dokumenten. Beim Erzeugen dieser Java Bean -werden unter anderem die gesicherten Dokumente für den -späteren Abruf durch die Anwendung (vergleiche - Abschnitt 3.4) -im Filesystem zwischengespeichert sowie die Prüfung -vorgenommen, ob es sich bei einem gesicherten Dokument um ein -XHTML-Dokument gemäß Spezifikationen -zur österreichischen Bürgerkarte in der -Version 1.2 handelt (SLXHTML-Dokument) oder nicht. Die Bean ist im -Session Scope abgelegt.
SignerInfoBean: -Enthält -alle notwendigen Informationen zum Ersteller der geprüften -XML-Signatur. Die Bean ist im Servlet Scope abgelegt.
ChecksInfoBean: -Enthält -alle notwendigen Informationen zum Ergebnis der Prüfung der -XML-Signatur. Die Bean ist im Servlet Scope abgelegt.

- -

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:

- -

Informationen zum Ersteller der geprüften -XML-Signatur: Name des Erstellers, Name des Ausstellers des -Zertifikats, Angaben zur Qualität des Zertifikats.
Informationen zum Ergebnis der Prüfung der -XML-Signatur: Ergebnis der Signaturprüfung, Ergebnis der -Prüfung des Zertifikats.
Informationen zu jedem von der XML-Signatur gesicherten -Dokument: Angabe, ob es sich beim Dokument um ein SLXHTML-Dokument -handelt, Link zum Download des gesicherten Dokuments. Wenn es sich um -ein SLXHTML-Dokument handelt, wird das Dokument bei Verfolgung des -Links in einem neuen Browserfenster angezeigt, ansonsten kann das -Dokument heruntergeladen und gespeichert werden.

- -

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 +

3.1 +Das Servlet `Dispatcher`

+ +

Das Servlet Dispatcher implementiert die zentrale Programmlogik der Webanwendung, die folgende Einzelaufgaben umfasst:

Empfang der +vom Benutzer hochgeladenen Informationen für die Erstellung des +Signaturerstellungsrequests (XML-Rechtsdokument, Stylesheet, ggf. +Bilddateien) sowie Speicherung der Informationen im Session-Objekt +der zugehörigen Session.
Einbindung der JSP-Seiten, welche die Bildschirm-Masken für die Interaktion mit dem Benutzer über dessen Webbrowser aufbauen.
Verwendung von Funktionalität der Klasse RequestBuilder, +um aus den hochgeladenen Informationen basierend auf einem +vorkonfigurierten XML-Template den Signaturerstellungsrequest für MOA +SS zu erzeugen.
Verwendung von Funktionaliät der Klasse MOAInvoker, +um den Signaturerstellungsrequest an MOA SS zu senden bzw. den +Signaturerstellungsresponse von MOA SS zu empfangen und +auszuwerten.

3.2 +Die JSP-Seiten

Die +JSP-Seiten sind für den Aufbau der Bildschirm-Masken für den Webbrowser +des Benutzers verantwortlich, über welche die Webanwendung mit dem +Benutzer kommuniziert. Sie werden vom Servlet Dispatcher in den Programmfluss eingebunden. Folgende JSP-Seiten existieren:

UploadXML.jsp: +Diese Seite baut die Bildschirm-Maske zum Hochladen der +XML-Repräsentation des zu signierenden Rechtsdokuments sowie des +Stylesheets für die Erzeugung der HTML-Repräsentation des +Rechtsdokuments auf. Die hochzuladenden Dateien werden an das Servlet Dispatcher übermittelt.
UploadImages.jsp: +Diese Seite baut die Bildschirm-Maske zum Hochladen von Bild-Dateien +auf, die ggf. in der XML-Repräsentation des zu signierenden +Rechtsdokuments referenziert werden. Falls keine Bild-Dateien +referenziert werden, wird diese Bildschirm-Maske nicht aufgebaut. Die hochzuladenden Dateien werden an das Servlet Dispatcher übermittelt.
DownloadSignature.jsp: +Diese Seite baut die Bildschirm-Maske auf, von welcher der Benutzer die +von MOA SS erzeugte Signatur herunterladen und lokal speichern kann.
Error.jsp: +Diese Seite baut die Bildschirm-Maske auf, die dem Benutzer im Falle +eines aufgetretenen Fehlers präsentiert wird. Sie enthält dann eine +Beschreibung des sowie Detailinformationen zum aufgetretenen Fehler.

3.3 Die Klasse `MOAInvoker`

Die Klasse MOAInvoker ist +für die Kommunikation der Webanwendung mit dem MOA SS Webservice +verantwortlich. Sie sendet den Signaturerstellungsrequest an MOA SS und +empfängt die entsprechende Signaturerstellungsresponse. Die Response +wird gegen das XML-Schema von MOA SS validiert.

3.4 Die Klasse `RequestBuilder`

+ +

Die Klasse RequestBuilder stellt dem Servlet Dispatcher die +notwendige Funktionalität zur Verfügung, um aus den hochgeladenenen +Informationen des Benutzers basierend auf einem vorkonfigurierten +Template den XML-Signaturerstellungsrequest für das MOA SS Webservice +zu erzeugen.

Im Wesentlichen umfasst die Klasse folgende Funktionen:

Integration der XML-Repräsentation des zu signierenden Rechtsdokuments in den Signaturerstellungsrequest;
Integration +des Stylesheets in den Signaturerstellungsrequest (wurde vom Benutzer +ein Stylesheet hochgeladen, wird dieser integriert, ansonsten der +vorkonfigurierte Default-Stylesheet);
Integration der ggf. mitzusignierenden Bild-Dateien in den Signaturerstellungsrequest.

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

+Im Deployment Descriptor web.xml des +Web Archives (WAR-File) des E-Recht Signaturclients sind im Wesentlichen folgende +Konfigurationen eingerichtet, die im Normalfall nicht verändert +werden müssen:

Definition der URLs, unter denen die Servlets von MOA SL (MOAServlet, HashInputServlet, ReturnServlet) relativ zum Root der Web Application erreichbar sind (XML-Elemente servlet bzw. servlet-mapping).
Definition der Filter, die für das Servlet MOAServlet zur Anwendung kommen sollen (XML Elemente filter bzw. filter-mapping). Die Konfiguration ist so eingerichtet, dass für das Servlet MOAServlet genau ein Filter, nämlich SL2MOAFilter konfiguriert ist.
Definition der URLs, unter denen das Servlet Dispatcher in +den unterschiedlichen Anwendungsfällen (Hochladen des +XML-Rechtsdokuments, Hochladen von Bild-Dateien) relativ zum Root der +Web Application erreichbar sind (XML-Elemente servlet bzw. servlet-mapping).
Definition des Context Listeners für die Initialisierung der Webanwendung (XML Element listener).

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

- - + +

Die nachfolgende Grafik eine Übersicht über die Komponenten aus +Abschnitt 3 sowie deren Interaktion untereinander sowie mit Anwender +und MOA SS dar.

Zusammenspiel der Komponenten - Basisablauf

Das Zusammenspiel der Komponenten für einen typischen Ablauf des E-Recht Signaturclients sieht wie folgt aus:

Der Anwender beginnt mit dem Aufruf des Servlets Dispatcher unter der URL http://<Hostname>:<Port>//moa-ss-erecht-client/UploadXML.
Das Servlet Dispatcher bindet die JSP-Seite UploadXML.jsp ein, um dem Anwender die Maske für den Upload von XML-Rechtsdokument und Stylesheet anzuzeigen.
Der +Anwender wählt jedenfalls das XML-Rechtsdokument und optional auch den +Stylesheet für den Upload aus und startet den Upload, der wiederum an +das Servlet Dispatcher gerichtet ist.
Das Servlet Dispatcher +speichert das XML-Rechtsdokument und ggf. den Stylesheet im +Session-Objekt der Anwender-Sitzung. Weiters prüft es das +XML-Rechtsdokument, ob darin Bild-Dateien referenziert werden. Ist dies +der Fall, bindet es die JSP-Seite UploadImages.jsp ein, um dem Anwender die Maske für den Upload der Bild-Dateien anzuzeigen. Ansonsten fährt das Servlet mit Schritt 7 fort.
Der Anwender wählt die hochzuladenden Bild-Dateien aus und startet den Upload, der wiederum an das Servlet Dispatcher gerichtet ist.
Das Servlet Dispatcher speichert die Bild-Dateien im Session-Objekt der Anwender-Sitzung.
Das Servlet Dispatcher nutzt die Funktionalität der Klasse RequestBuilder, +um aus den hochgeladenen Informationen, die im Session-Objekt temporär +gespeichert sind, den Signaturerstellungsrequest für MOA SS zu +erstellen.
Das Servlet Dispatcher verwendet die Funktionalität der Klasse MOAInvoker, +um den Signaturerstellungsrequest an MOA SS zu senden, bzw. um den +entsprechenden Signaturerstellungsresponse von MOA SS zu empfangen.
Das Servlet Dispatcher extrahiert die erstellte Signatur aus dem Signaturerstellungsresponse und bindet die JSP-Seite DownloadSignature.jsp ein, um dem Anwender die Maske für den Download der erstellten Signatur anzuzeigen.

\ No newline at end of file -- cgit v1.2.3

2 Installation

Inhalt

1 -Einführung

1 +Einführung

2 -Überblick

3 +

2 +Überblick

3 Komponenten

3.1 -Der Filter SL2MOAFilter

3.2 -Das Servlet MOAServlet

3.3 Die JSP-Seite resultOverview.jsp

3.4 Das Servlet HashInputDataServlet

3.5 -Das Servlet ReturnServlet

3.6 -Die Klasse URLRewriter