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/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 ++++----------------- 10 files changed, 127 insertions(+), 489 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 (limited to 'erecht.client.ss/handbook') 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 @@
Systemhandbuch
-
Beschreibung der einzelnen Komponenten des Signaturclients und ihrem Zusammenspiel.
Anwenderhandbuch
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
Logo BKA 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 - - - - - - - - - - - - - - - - - - - - -
Logo BKAOpen -Source
- -für das E-Government		Logo MOA
- -
-

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

- -

Systemhandbuch

+ +
Logo BKA E-Recht

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

Systemhandbuch

Inhalt

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

  1. -

    Einführung

    +

    Einführung

    2. -
  2. Überblick
    3. +
  3. Überblick
  4. Komponenten
      -
    1. Der -Filter SL2MOAFilter -
      2. - -
    2. Das -Servlet MOAServlet -
      3. - -
    3. Die -JSP-Seite resultOverview.jsp +
    4. Das Servlet Dispatcher
      5. -
    5. Das -Servlet HashInputDataServlet
      6. + -
    6. Das -Servlet ReturnServlet
      7. - -
    7. Die -Klasse URLRewriter
      8. - -
    8. Der -Deployment Descriptor web.xml
      9. +
    9. Die +JSP-Seiten
    10. Die Klasse MOAInvoker
    11. Die Klasse RequestBuilder
    12. Der +Deployment Descriptor web.xml
    @@ -84,446 +41,130 @@ Deployment Descriptor web.xml
  5. Zusammenspiel der Komponenten -
      - -
    1. Basisablauf
      2. - -
    2. Ablauf mit Rewrite-Proxy
      3. - -
    +
    -

    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:

    - - - -

    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:

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

    -

    - -

    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 +

    3.1 +Das Servlet Dispatcher

    + +

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

    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:

    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:

    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:

    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:
    1. Der Anwender beginnt mit dem Aufruf des Servlets Dispatcher unter der URL http://<Hostname>:<Port>//moa-ss-erecht-client/UploadXML.
    2. 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.
    3. 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.
    4. 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.
    5. Der Anwender wählt die hochzuladenden Bild-Dateien aus und startet den Upload, der wiederum an das Servlet Dispatcher gerichtet ist.
    6. Das Servlet Dispatcher speichert die Bild-Dateien im Session-Objekt der Anwender-Sitzung.
    7. 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.
    8. 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.
    9. 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