diff options
Diffstat (limited to 'erecht.client.ss/handbook')
| -rw-r--r-- | erecht.client.ss/handbook/constraints.txt | 5 | ||||
| -rw-r--r-- | erecht.client.ss/handbook/index.html | 5 | ||||
| -rw-r--r-- | erecht.client.ss/handbook/operation/images/testapp.screen1.png | bin | 38150 -> 0 bytes | |||
| -rw-r--r-- | erecht.client.ss/handbook/operation/images/testapp.screen2.png | bin | 44749 -> 0 bytes | |||
| -rw-r--r-- | erecht.client.ss/handbook/operation/images/testapp.screen3.png | bin | 16625 -> 0 bytes | |||
| -rw-r--r-- | erecht.client.ss/handbook/operation/images/testapp.screen4.png | bin | 40110 -> 0 bytes | |||
| -rw-r--r-- | erecht.client.ss/handbook/operation/operation.html | 11 | ||||
| -rw-r--r-- | erecht.client.ss/handbook/system/images/Zusammenspiel.VSD | bin | 138240 -> 113152 bytes | |||
| -rw-r--r-- | erecht.client.ss/handbook/system/images/Zusammenspiel.png | bin | 0 -> 51511 bytes | |||
| -rw-r--r-- | erecht.client.ss/handbook/system/system.html | 595 |
10 files changed, 127 insertions, 489 deletions
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 @@ <title>MOA SL - Übersicht</title><meta content="Evrsoft First Page" name="GENERATOR"> <meta http-equiv="content-type" content="text/html; charset=us-ascii"> <link href="./common/handbook.css" type="text/css" rel="stylesheet"></head> - - <body alink="#cc9966" bgcolor="white" link="#990000" text="#000000" vlink="#666666"> <table class="logoTable" border="0" cellpadding="10" cellspacing="0" width="100%"> <tbody> @@ -32,6 +30,5 @@ <dt><a href="./system/system.html">Systemhandbuch</a></dt> - <dd>Beschreibung der einzelnen Komponenten des Signaturclients und ihrem Zusammenspiel.</dd><dt><a href="./usage/usage.html">Anwenderhandbuch</a></dt><dd>Beschreibung der Verwendung des Signaturclients.</dd> - </dl> + <dd>Beschreibung der einzelnen Komponenten des Signaturclients und ihrem Zusammenspiel.</dd></dl> </body></html>
\ 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 Binary files differdeleted file mode 100644 index 38a226d09..000000000 --- a/erecht.client.ss/handbook/operation/images/testapp.screen1.png +++ /dev/null diff --git a/erecht.client.ss/handbook/operation/images/testapp.screen2.png b/erecht.client.ss/handbook/operation/images/testapp.screen2.png Binary files differdeleted file mode 100644 index 45230d5c9..000000000 --- a/erecht.client.ss/handbook/operation/images/testapp.screen2.png +++ /dev/null diff --git a/erecht.client.ss/handbook/operation/images/testapp.screen3.png b/erecht.client.ss/handbook/operation/images/testapp.screen3.png Binary files differdeleted file mode 100644 index 7d5db9cad..000000000 --- a/erecht.client.ss/handbook/operation/images/testapp.screen3.png +++ /dev/null diff --git a/erecht.client.ss/handbook/operation/images/testapp.screen4.png b/erecht.client.ss/handbook/operation/images/testapp.screen4.png Binary files differdeleted file mode 100644 index 9fe7ee264..000000000 --- a/erecht.client.ss/handbook/operation/images/testapp.screen4.png +++ /dev/null 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 @@ <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html><head> -<meta content="text/html; charset=iso-8859-1" http-equiv="content-type"><title>MOA -SL - Betriebshandbuch</title> <link type="text/css" href="../common/handbook.css" rel="stylesheet"></head> - +<meta content="text/html; charset=iso-8859-1" http-equiv="content-type"><title>MOA SL - Betriebshandbuch</title> <link type="text/css" href="../common/handbook.css" rel="stylesheet"></head> <body style="color: rgb(0, 0, 0); background-color: white;" alink="#cc9966" link="#990000" vlink="#666666"><table class="logoTable" border="0" cellpadding="10" cellspacing="0" width="100%"> <tbody> <tr><td class="logoTitle" align="center" width="267"><img style="width: 267px; height: 37px; float: left;" alt="Logo BKA" src="../common/LogoBKA.png"></td> <td class="logoTitle" align="center">E-Recht</td> </tr> </tbody> </table><hr><p class="title"><a href="../index.html">E-Recht: Signaturclient für MOA SS, V0.9</a></p> @@ -38,8 +36,7 @@ plattformunabhängiges Modul ausgelegt, das als Webanwendung <p>Dieses Handbuch beschreibt einerseits die Installation des Clients, andererseits werden die Konfigurationsmöglichkeiten dargestellt. Für eine funktionale Beschreibung des Moduls -siehe <a href="../system/system.html">Systemhandbuch</a>, -für die Beschreibung der Verwendung siehe <a href="../usage/usage.html">Anwenderhandbuch</a>. +siehe <a href="../system/system.html">Systemhandbuch</a>. </p><h1><a name="installation" id="installation"></a>2 Installation</h1> <h2><a name="installation_einführung" id="installation_einführung"></a>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.</p> <p>Als Logging Toolkit verwendet das MOA SL Webservice <a href="http://logging.apache.org/log4j/">Apache Log4j</a>. </p> diff --git a/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD b/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD Binary files differindex 0088d5109..6ead1bd1c 100644 --- a/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD +++ b/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD diff --git a/erecht.client.ss/handbook/system/images/Zusammenspiel.png b/erecht.client.ss/handbook/system/images/Zusammenspiel.png Binary files differnew file mode 100644 index 000000000..16199e4a5 --- /dev/null +++ b/erecht.client.ss/handbook/system/images/Zusammenspiel.png 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 @@ <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> -<head> +<html><head> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> - <title>MOA SL - Systemhandbuch</title> + - <link rel="stylesheet" href="../common/handbook.css" type="text/css"> + <title>MOA SL - Systemhandbuch</title><link rel="stylesheet" href="../common/handbook.css" type="text/css"></head> -</head> - - -<body style="color: rgb(0, 0, 0); background-color: white;" alink="#cc9966" link="#990000" vlink="#666666"> - -<table class="logoTable" border="0" cellpadding="10" cellspacing="0" width="100%"> - - <tbody> - - <tr> - - <td class="logoTitle" align="center" width="267"><img src="../common/LogoBKA.png" alt="Logo BKA" align="left" height="37" width="267"></td> - - <td class="logoTitle" align="center">Open -Source<br> - -für das E-Government</td> - - <td class="logoTitle" align="center" width="123"><img src="../common/LogoMoa4c.jpg" alt="Logo MOA" align="right" height="138" width="123"></td> - - </tr> - - </tbody> -</table> - -<hr> -<p class="title"><a href="../index.html">MOA: -Serverseitige Signaturprüfung (SL), V 1.1</a></p> - -<p class="subtitle">Systemhandbuch</p> +<body style="color: rgb(0, 0, 0); background-color: white;" alink="#cc9966" link="#990000" vlink="#666666"><table class="logoTable" border="0" cellpadding="10" cellspacing="0" width="100%"> <tbody> <tr><td class="logoTitle" align="center" width="267"><img style="width: 267px; height: 37px; float: left;" alt="Logo BKA" src="../common/LogoBKA.png"></td> <td class="logoTitle" align="center">E-Recht</td> </tr> +</tbody> </table><hr><p class="title"><a href="../index.html">E-Recht: +Signaturclient für MOA SS, V0.9</a></p><p class="subtitle">Systemhandbuch</p> <hr> <h1>Inhalt</h1> @@ -45,38 +17,23 @@ Serverseitige Signaturprüfung (SL), V 1.1</a></p> <ol> <li> - <p><a href="#einf%FChrung">Einführung</a></p> + <p><a href="#einf%FChrung">Einführung</a></p> </li> - <li><a href="#%FCberblick">Überblick</a></li> + <li><a href="#%FCberblick">Überblick</a></li> <li> <a href="#komponenten">Komponenten</a> <ol> - <li><a href="#komponenten.sl2moafilter">Der -Filter <code>SL2MOAFilter</code></a> - </li> - - <li><a href="#komponenten.moaservlet">Das -Servlet <code>MOAServlet</code></a> - </li> - - <li><a href="#komponenten.resultoverview">Die -JSP-Seite <code>resultOverview.jsp</code></a> + <li><a href="#komponenten.dispatcher">Das Servlet <code>Dispatcher</code></a> </li> - <li><a href="#komponenten.hashinputservlet">Das -Servlet <code>HashInputDataServlet</code></a></li> + - <li><a href="#komponenten.returnservlet">Das -Servlet <code>ReturnServlet</code></a></li> - - <li><a href="#komponenten.urlrewriter">Die -Klasse URLRewriter</a></li> - - <li><a href="#komponenten.webxml">Der -Deployment Descriptor web.xml</a></li> + <li><a href="#komponenten.jspseiten">Die +JSP-Seiten</a></li><li><a href="#komponenten.moainvoker">Die Klasse <code>MOAInvoker</code></a></li><li><a href="#komponenten.requestbuilder">Die Klasse <code>RequestBuilder</code></a></li><li><a href="#komponenten.webxml">Der +Deployment Descriptor <code>web.xml</code></a></li> </ol> @@ -84,446 +41,130 @@ Deployment Descriptor web.xml</a></li> <li><a href="#zusammenspiel">Zusammenspiel der Komponenten</a> - <ol> - - <li><a href="#zusammenspiel.basis">Basisablauf</a></li> - - <li><a href="#zusammenspiel.rewrite">Ablauf mit Rewrite-Proxy</a></li> - - </ol> + <ol></ol> </li> </ol> <hr> -<h1><a name="einführung" id="einführung"></a>1 -Einführung </h1> +<h1><a name="einführung" id="einführung"></a>1 +Einführung </h1> -<p>Das Modul <span class="term">Serverseitige -Signaturprüfung</span> (MOA SL) ist als -plattformunabhängiges Modul ausgelegt, das als Webservice -über HTTP bzw. HTTPS angesprochen werden kann. </p> +<p>Das Modul <em>E-Recht Signaturclient für MOA SS</em> ist als +plattformunabhängiges Modul ausgelegt, das als Webanwendung +über HTTP angesprochen werden kann. </p> -<p>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 +<p>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.</p> -<p>Für die Installation und die Konfiguration von MOA SL -siehe <a href="../operation.html">Betriebshandbuch</a>. +<p>Für die Installation und die Konfiguration des <em>E-Recht Signaturclients für MOA SS</em> +siehe <a href="../operation/operation.html">Betriebshandbuch</a>. </p> -<h1><a name="überblick" id="überblick"></a>2 -Überblick</h1> - -<p>Das Modul <span class="term">Serverseitige -Signaturprüfung</span> (MOA SL) bietet für -Signaturprüfung eine serverseitige Implementierung einer -Bürgerkarten-Umgebung entsprechend den <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen -zur österreichischen Bürgerkarte</a> in der -Version 1.2. </p> - -<p>Der Funktionsumfang von MOA SL kann wie folgt zusammengefasst -werden:</p> - -<ul> - - <li>Von den XML-Befehlen der <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html">Applikationsschnittstelle -Security-Layer</a> wird genau ein Befehl unterstützt, -und zwar jener zur Prüfung von XML-Signaturen (<span class="term">VerifyXMLSignature</span>).</li> - - <li>Hinsichtlich der <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/bindings/Bindings.html">Transportprotokolle -des Security-Layer</a> wird ausschließlich die -HTTP-Bindung unterstützt, wobei für diese Bindung -zusätzlich folgende Einschränkungen gelten: - <ul> - - <li>Keine Unterstützung der Formularparameter -RedirectURL und StylesheetURL.</li> - - <li>Verpflichtende Verwendung des Formularparameters -DataURL. </li> - - <li>Keine Unterstützung von Weitergabe-Parametern -und Weitergabe-Headern.</li> - - <li>Keine Referenzierbarkeit von Formularfeldern.</li> - - <li>Hinsichtlich der Ablaufsteuerung laut <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/bindings/Bindings.html#http.ablauf.schritte">Abschnitt -3.2.3</a> wird ausschließlich Fall 5e -unterstützt. </li> - - </ul> - - </li> - - <li>Hinsichtlich der Anzeigeformate des Security-Layer wird -ausschließlich das <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/minimum/Minimum.html#anzeigeformate.formate.slxhtml">Standardanzeigeformat -des Security-Layers</a> 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. </li> - -</ul> - -<h1><a name="komponenten" id="komponenten"></a>3 +<h1><a name="überblick" id="überblick"></a>2 +Überblick</h1><p>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:</p><ul><li> die XML-Präsentation des Rechtsokuments;</li><li>der +Stylesheet für die Umwandlung der XML-Repräsentation des Rechtsdokuments in seine +HTML-Repräsentation durch MOA SS;</li><li>etwaige Bilder und Grafiken, die in der XML- und damit auch +HTML-Repräsentation +referenziert werden.</li></ul><p>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.</p><p>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.</p><p>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.</p><h1><a name="komponenten" id="komponenten"></a>3 Komponenten</h1> -<h2><a name="komponenten.sl2moafilter" id="komponenten"></a>3.1 -Der Filter <code>SL2MOAFilter</code></h2> - -<p>Die Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> -ist ein -<code><abbr title="javax.servlet.Filter">Filter</abbr></code>, -der einerseits -den <code><abbr title="javax.servlet.http.httpservletrequest=">HttpServletRequest</abbr></code> -verändert, bevor er an das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> -weitergeleitet wird, und andererseits den <code><abbr title="javax.servlet.http.HttpServletResponse">HttpServletResponse</abbr></code> -verändert, nachdem er vom Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> -bearbeitet wurde.</code></p> - -<p>Der <code><abbr title="javax.servlet.http.HttpServletRequest">HttpServletRequest</abbr></code> -enhält ja zunächst den Request zur Prüfung -der XML-Signatur in einem Format entsprechend der <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen -zur österreichischen Bürgerkarte</a> in der -Version 1.2 (SL-Request). Das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> -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 <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>s -ist es daher, vor der Ausführung des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>s -für eine passende Umsetzung des SL-Requests in den -entsprechenden MOA-Request zu sorgen. </p> - -<p>Zur Erfüllung dieser -Aufgabe bedient sich der <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> -der Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.transformers.SL2MOA">SL2MOA</abbr></code>, -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: -<ul> - <li>Einfügen eines <code>DateTime</code> Elements in den MOA-Request, wenn bisher kein solches existiert, und wenn in der im MOA-Request - enthaltenen XML Signatur kein Signaturattribut <code>etsi:SigningTime</code> existiert und wenn aus dem E-Recht XML Dokument, das von der - XML-Signatur signiert wird, die Metainformation (Attribut <code>h-created</code> im Wurzelelement <code>erechtdok</code>) des - Erzeugungszeitpunkts des E-Recht XML Dokuments erfolgreich extrahiert werden konnte.</li> - - <li>Hinzufügen des Elements <code>ReturnHashInputData</code>, das MOA SP anweist, die Hashinputdaten für jede <code>dsig:Reference</code> - der zu prüfenden XML Signatur als Teil der MOA-Response zu retournieren.</li> - - <li>Hinzufügen des verpflichtend anzugebenden Elements <code>TrustProfileID</code>, 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.</li> -</ul> -</p> - -<p>Das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> -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 <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> -aufruft, erwartet sich jedoch die Antwort auf den Request zur -Prüfung -der XML-Signatur in einem Format entsprechend der <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen -zur österreichischen Bürgerkarte</a> in der -Version 1.2 (SL-Response). Aufgabe des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>s -ist es daher, nach der Ausführung des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>s -für eine passende Umsetzung der MOA-Response in die -entsprechende SL-Response zu sorgen. Zur Erfüllung -dieser -Aufgabe bedient sich der <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> -der Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.transformers.MOA2SL">MOA2SL</abbr></code>, -in der die -Response-Transformation gekapselt ist.</p> - -<p>Eine weitere Aufgabe der Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> -ist es schließlich, die JSP-Seite <code>resultoverview.jsp</code> -einzubinden, die für eine benutzertaugliche HTML-Darstellung -der SL-Response sorgt. Diese benutzertaugliche Darstellung wird dann -tatsächlich als finales Resultat des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>s -an die Anwendung zurückübermittelt. Bevor die -JSP-Seite eingebunden wird, erzeugt <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> -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 <a href="#komponenten.resultoverview">Abschnitt 3.3</a>. -</p> - -<h2><a name="komponenten.moaservlet" id="komponenten"></a>3.2 -Das Servlet <code>MOAServlet</code></h2> - -<p>Die Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet"> -MOAServlet</abbr></code> ist ein <code><abbr title="javax.servlet.http.HttpServlet">HttpServlet</abbr></code> -und als solches für die Kommunikation mit dem Basismodul MOA -SP verantwortlich. </p> - -<p>Das Servlet liest aus dem <code><abbr title="javax.servlet.ServletInputStream">ServletInputStream</abbr></code> -des <code><abbr title="javax.servlet.http.HttpServletRequest">HttpServletRequest</abbr></code>s -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.</p> - -<p>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 <code><abbr title="javax.servlet.ServletOutputStream">ServletOutputStream</abbr></code> -der <code><abbr title="javax.servlet.http.HttpServletResponse">HttpServletResponse</abbr></code>.</p> - -<p>Das MOAServlet bedient sich zur Kommunikation mit MOA SP der -Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.moainvoker.MOAInvoker"> -MOAInvoker</abbr></code>, in der die -Funktionalität des Webservice-Clients für MOA SP -gekapselt ist.</p> - -<h2><a name="komponenten.resultoverview" id="komponenten"></a>3.3 Die JSP-Seite <code>resultOverview.jsp</code></h2> - -<p>Die JSP-Seite <code>resultOverview.jsp</code> ist -verantwortlich für die Aufbereitung -einer benutzertauglichen HTML-Darstellung der SL-Response, die -das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> -im Zusammenspiel mit dem Filter <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> -erzeugt. </p> - -<p>Die für die Aufbereitung erforderlichen Informationen -werden der JSP-Seite in Form von Java Beans zur Verfügung -gestellt, die zuvor vom <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter -</abbr></code>erzeugt worden sind (vergleiche <a href="#komponenten.sl2moafilter">Abschnitt 3.1</a>). -Folgende Java Beans stehen der JSP-Seite zur Verfügung:</p> - -<ul> - - <li><code><abbr title="at.gv.egovernment.moa.spss.slinterface.beans.DataInfoBean">DataInfoBean</abbr></code>: -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 - <a href="#komponenten.hashinputservlet">Abschnitt 3.4</a>) -im Filesystem zwischengespeichert sowie die Prüfung -vorgenommen, ob es sich bei einem gesicherten Dokument um ein -XHTML-Dokument gemäß <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen -zur österreichischen Bürgerkarte</a> in der -Version 1.2 handelt (SLXHTML-Dokument) oder nicht. Die Bean ist im -Session Scope abgelegt.</li> - - <li><code><abbr title="at.gv.egovernment.moa.spss.slinterface.beans.SignerInfoBean">SignerInfoBean</abbr></code>: -Enthält -alle notwendigen Informationen zum Ersteller der geprüften -XML-Signatur. Die Bean ist im Servlet Scope abgelegt.</li> - - <li><code><abbr title="at.gv.egovernment.moa.spss.slinterface.beans.ChecksInfoBean">ChecksInfoBean</abbr></code>: -Enthält -alle notwendigen Informationen zum Ergebnis der Prüfung der -XML-Signatur. Die Bean ist im Servlet Scope abgelegt.</li> - -</ul> - -<p>Die JSP-Seite <code>resultOverview.jsp</code> -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:</p> - -<ul> - - <li>Informationen zum Ersteller der geprüften -XML-Signatur: Name des Erstellers, Name des Ausstellers des -Zertifikats, Angaben zur Qualität des Zertifikats.</li> - - <li>Informationen zum Ergebnis der Prüfung der -XML-Signatur: Ergebnis der Signaturprüfung, Ergebnis der -Prüfung des Zertifikats.</li> - - <li>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.</li> - -</ul> - -<p>Ein Beispiel für die resultierende HTML-Darstellung -befindet sich <a href="../operation/images/testapp.screen2.png">hier</a>.</p> - -<h2><a name="komponenten.hashinputservlet" id="komponenten"></a>3.4 Das Servlet <code>HashInputDataServlet</code></h2> - -<p>Das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code> -ist -für die Verfügbarkeit der von der geprüften -XML-Signatur gesicherten Dokumente verantwortlich. </p> - -<p>In der HTML-Aufbereitung der SL-Response, die von der -JSP-Seite <code>resultOverview.jsp </code>erzeugt wird, -(vergleiche <a href="#komponenten.resultoverview">Abschnitt -3.3</a>) befinden sich Links auf alle gesicherten Dokumente. -Diese Links führen jeweils auf das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code>. </p> - -<p>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 <a href="#komponenten.resultoverview">Abschnitt 3.3</a> -erwähnte <code><abbr title="at.gv.egovernment.moa.spss.slinterface.beans.DataInfoBean">DataInfoBean</abbr></code>: -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.</p> - -<h2><a name="komponenten.returnservlet" id="komponenten"></a>3.5 -Das Servlet <code>ReturnServlet</code></h2> - -<p>Das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> -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.</p> - -<p>Damit verhält sich MOA SL genau wie in der -Spezifikation <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/bindings/Bindings.html">Transportprotokolle -Security-Layer</a> (Teil der <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen -zur österreichischen Bürgerkarte</a> in der -Version 1.2) in <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/bindings/Bindings.html#http.ablauf.schritte">Abschnitt -3.2.3</a> 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 <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> -die SL-Response an den DataURL-Server. Die URL des DataURL-Servers -wurde von der Anwendung im ursprünglichen Request an das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> -als Formular-Parameter angegeben. Der DataURL-Server antwortet auf das -Eintreffen der SL-Response mit einem HTTP-Response an das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code>, -diese wird vom <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> -als Antwort auf das Quittieren der HTML-Darstellung an den Browser -weitergeleitet. </p> - -<p>Nachdem mit diesem Schritt die Bearbeitung der zur -Prüfung übermittelten XML-Signatur durch MOA-SL -abgeschlossen ist, wird am Ende des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> -die Session und damit alle gespeicherten Informationen zur -geprüften XML-Signatur gelöscht. </p> - -<h2><a name="komponenten.urlrewriter" id="komponenten"></a>3.6 -Die Klasse <code>URLRewriter</code></h2> - -<p>Die Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.URLRewriter">URLRewriter</abbr></code> -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.</p> - -<p>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. </p> - -<p>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.</p> - -<p>Die Methode <code>rewrite</code> der Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.URLRewriter">URLRewriter</abbr></code> -wird bei der Erstellung der HTML-Aufbereitung der SL-Response durch die -JSP-Seite <code>resultOverview.jsp</code> 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.</p> - -<h2><a name="komponenten.webxml" id="komponenten"></a>3.7 +<h2><a name="komponenten.dispatcher" id="komponenten"></a>3.1 +Das Servlet <code>Dispatcher</code></h2> + +<p>Das Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> implementiert die zentrale Programmlogik der Webanwendung, die folgende Einzelaufgaben umfasst:</p><ul><li>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.</li><li>Einbindung der JSP-Seiten, welche die Bildschirm-Masken für die Interaktion mit dem Benutzer über dessen Webbrowser aufbauen.</li><li>Verwendung von Funktionalität der Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.RequestBuilder">RequestBuilder</abbr></code>, +um aus den hochgeladenen Informationen basierend auf einem +vorkonfigurierten XML-Template den Signaturerstellungsrequest für MOA +SS zu erzeugen.</li><li>Verwendung von Funktionaliät der Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.MOAInvoker">MOAInvoker</abbr></code>, +um den Signaturerstellungsrequest an MOA SS zu senden bzw. den +Signaturerstellungsresponse von MOA SS zu empfangen und +auszuwerten. </li></ul><h2><a name="komponenten.jspseiten" id="komponenten"></a>3.2 +Die JSP-Seiten</h2><p>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 <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> in den Programmfluss eingebunden. Folgende JSP-Seiten existieren:</p><ul><li><code>UploadXML.jsp</code>: +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 <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher </abbr></code>übermittelt.</li><li><code>UploadImages.jsp</code>: +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 <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher </abbr></code>übermittelt.</li><li><code>DownloadSignature.jsp</code>: +Diese Seite baut die Bildschirm-Maske auf, von welcher der Benutzer die +von MOA SS erzeugte Signatur herunterladen und lokal speichern kann.</li><li><code>Error.jsp</code>: +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.</li></ul><h2><a name="komponenten.moainvoker" id="komponenten"></a>3.3 Die Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.MOAInvoker">MOAInvoker</abbr></code></h2><p>Die Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.MOAInvoker">MOAInvoker </abbr></code>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. </p><h2><a name="komponenten.requestbuilder" id="komponenten"></a>3.4 Die Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.RequestBuilder">RequestBuilder</abbr></code><code></code></h2> + +<p>Die Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.RequestBuilder">RequestBuilder</abbr></code><code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet"></abbr></code> stellt dem Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> 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.</p><p> Im Wesentlichen umfasst die Klasse folgende Funktionen:</p><ul><li>Integration der XML-Repräsentation des zu signierenden Rechtsdokuments in den Signaturerstellungsrequest;</li><li>Integration +des Stylesheets in den Signaturerstellungsrequest (wurde vom Benutzer +ein Stylesheet hochgeladen, wird dieser integriert, ansonsten der +vorkonfigurierte Default-Stylesheet);</li><li>Integration der ggf. mitzusignierenden Bild-Dateien in den Signaturerstellungsrequest.</li></ul><h2><a name="komponenten.returnservlet" id="komponenten"></a></h2><h2><a name="komponenten.webxml" id="komponenten"></a>3.5 Der Deployment Descriptor <code>web.xml</code></h2> <p> -Im Deployment Descriptor <code><abbr title="WEB-INF/web.xml">web.xml</abbr></code>des -Web Archives (WAR-File) von MOA SL sind im Wesentlichen folgende -Konfigurationen eingerichtet, die im Normalfall nicht verändert -werden müssen:</p> +Im Deployment Descriptor <code><abbr title="WEB-INF/web.xml">web.xml</abbr></code> des +Web Archives (WAR-File) des E-Recht Signaturclients sind im Wesentlichen folgende +Konfigurationen eingerichtet, die im Normalfall nicht verändert +werden müssen:</p> <ul> - <li>Definition der URLs, unter denen die Servlets von MOA SL (<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>, <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code>, <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code>) relativ zum Root der Web Application erreichbar sind (XML-Elemente <code>servlet</code> bzw. <code>servlet-mapping</code>).</li> - <li>Definition der Filter, die für das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> zur Anwendung kommen sollen (XML Elemente <code>filter</code> bzw. <code>filter-mapping</code>). Die Konfiguration ist so eingerichtet, dass für das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> genau ein Filter, nämlich <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> konfiguriert ist. </li> + <li>Definition der URLs, unter denen das Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> in +den unterschiedlichen Anwendungsfällen (Hochladen des +XML-Rechtsdokuments, Hochladen von Bild-Dateien) relativ zum Root der +Web Application erreichbar sind (XML-Elemente <code>servlet</code> bzw. <code>servlet-mapping</code>).</li> + <li>Definition des <em>Context Listeners</em> für die Initialisierung der Webanwendung (XML Element <code>listener</code><code></code>). </li> </ul> <h1><a name="zusammenspiel" id="zusammenspiel"></a>4 Zusammenspiel der Komponenten</h1> -<h1><a name="zusammenspiel.basis" id="zusammenspiel"></a>4.1 Basisablauf</h1> -<p>Die nachfolgende Grafik stellt das Zusammenspiel der Komponenten aus Abschnitt 3 mit dem Anwender und dem DataURL-Server dar.</p> -<p style="text-align: center;"><img style="width: 760px; height: 463px;" alt="Zusammenspiel der Komponenten - Basisablauf" src="images/Zusammenspiel.ohne.png" vspace="25"></p> -<table style="text-align: left; width: 983px; height: 216px;" border="1" cellpadding="2" cellspacing="2"> - <tbody> - <tr> - <td>1, 2</td> - <td> - <p>Prüfung der Signatur: Anfrage wird eigentlich an <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> gerichtet, durch die Filter-Konfiguration über den Deployment-Descriptor web.xml wird jedoch vorher und nachher der <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> dazwischengeschalten. Die Aufbereitung der HTML-Darstellung der SL-Response wird vom <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> an die JSP-Seite <code>resultOverview.jsp</code> delegiert.</p> - </td> - </tr> - <tr> - <td>3,4</td> - <td> - <p>Ü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 <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code>, die Zuordnung im Servlet passiert über URL-Parameter (Session-ID, fortlaufende Nummer des Dokuments).</p> - </td> - </tr> - <tr> - <td>5, 6, 7, 8</td> - <td> - <p>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 <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> verweist. Das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> -sendet die SL-Response an den DataURL-Server. Der DataURL-Server -antwortet entsprechend auf die übermittelte SL-Response; diese -Antwort wird vom <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> unverändert an den Antwender weitergeleitet.</p> - </td> - </tr> - </tbody> -</table> -<h1><a name="zusammenspiel.rewrite" id="zusammenspiel"></a>4.2 Ablauf mit Rewrite-Proxy</h1> -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.<br> -<div style="text-align: center;"><img style="width: 1021px; height: 463px;" alt="Zusemmenspiel der Komponenten - mit Rewrite-Proxy" src="images/Zusammenspiel.mit.png" vspace="25"><br> -<div style="text-align: left;"> -<table style="text-align: left; width: 983px; height: 216px;" border="1" cellpadding="2" cellspacing="2"> - <tbody> - <tr> - <td>1, 2</td> - <td> - <p>Prüfung der Signatur: Anfrage wird eigentlich an <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> gerichtet, durch die Filter-Konfiguration über den Deployment-Descriptor web.xml wird jedoch vorher und nachher der <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> dazwischengeschalten. Die Aufbereitung der HTML-Darstellung der SL-Response wird vom <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> an die JSP-Seite <code>resultOverview.jsp</code> delegiert. Die Anfrage des Anwenders wird nicht direkt an das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> gerichtet, sondern über den Rewrite-Proxy, der die Anfrage-URL passend umschreibt.</p> - </td> - </tr> - <tr> - <td>3,4</td> - <td> - <p>Ü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 <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code>, sondern zunächst auf den Rewrite-Proxy, der die Links passend auf das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code> umsetzt. Die Zuordnung im Servlet passiert über URL-Parameter (Session-ID, fortlaufende Nummer des Dokuments).</p> - </td> - </tr> - <tr> - <td>5, 6, 7, 8</td> - <td> - <p>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 <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> verweist, sondern zunächst auf den Rewrite-Proxy, der die Links passend auf das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> umsetzt. Das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> -sendet die SL-Response an den DataURL-Server. Der DataURL-Server -antwortet entsprechend auf die übermittelte SL-Response; diese Antwort -wird vom <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> unverändert an den Antwender weitergeleitet.</p> - </td> - </tr> - </tbody> -</table> -</div> -</div> -</body> -</html> + +<p>Die nachfolgende Grafik eine Übersicht über die Komponenten aus +Abschnitt 3 sowie deren Interaktion untereinander sowie mit Anwender +und MOA SS dar.</p> +<p style="text-align: center;"><img style="width: 880px; height: 422px;" alt="Zusammenspiel der Komponenten - Basisablauf" src="images/Zusammenspiel.png" vspace="25"></p>Das Zusammenspiel der Komponenten für einen typischen Ablauf des E-Recht Signaturclients sieht wie folgt aus:<br><ol><li>Der Anwender beginnt mit dem Aufruf des Servlets <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> unter der URL <code>http://<Hostname>:<Port>//moa-ss-erecht-client/UploadXML</code>.</li><li>Das Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> bindet die JSP-Seite <code>UploadXML.jsp</code> ein, um dem Anwender die Maske für den Upload von XML-Rechtsdokument und Stylesheet anzuzeigen.</li><li>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 <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> gerichtet ist.</li><li>Das Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> +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 <code>UploadImages.jsp</code> ein, um dem Anwender die Maske für den Upload der Bild-Dateien anzuzeigen. Ansonsten fährt das Servlet mit Schritt 7 fort.</li><li>Der Anwender wählt die hochzuladenden Bild-Dateien aus und startet den Upload, der wiederum an das Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> gerichtet ist.</li><li>Das Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> speichert die Bild-Dateien im Session-Objekt der Anwender-Sitzung.</li><li>Das Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> nutzt die Funktionalität der Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.RequestBuilder">RequestBuilder</abbr></code>, +um aus den hochgeladenen Informationen, die im Session-Objekt temporär +gespeichert sind, den Signaturerstellungsrequest für MOA SS zu +erstellen.</li><li>Das Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> verwendet die Funktionalität der Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.MOAInvoker">MOAInvoker</abbr></code>, +um den Signaturerstellungsrequest an MOA SS zu senden, bzw. um den +entsprechenden Signaturerstellungsresponse von MOA SS zu empfangen.</li><li>Das Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> extrahiert die erstellte Signatur aus dem Signaturerstellungsresponse und bindet die JSP-Seite <code>DownloadSignature.jsp</code> ein, um dem Anwender die Maske für den Download der erstellten Signatur anzuzeigen.</li></ol></body></html>
\ No newline at end of file |
