diff options
Diffstat (limited to 'erecht.client.ss/handbook/system')
| -rw-r--r-- | erecht.client.ss/handbook/system/images/Zusammenspiel.VSD | bin | 0 -> 138240 bytes | |||
| -rw-r--r-- | erecht.client.ss/handbook/system/images/Zusammenspiel.mit.png | bin | 0 -> 48649 bytes | |||
| -rw-r--r-- | erecht.client.ss/handbook/system/images/Zusammenspiel.ohne.png | bin | 0 -> 36106 bytes | |||
| -rw-r--r-- | erecht.client.ss/handbook/system/system.html | 529 |
4 files changed, 529 insertions, 0 deletions
diff --git a/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD b/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD Binary files differnew file mode 100644 index 000000000..0088d5109 --- /dev/null +++ b/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD diff --git a/erecht.client.ss/handbook/system/images/Zusammenspiel.mit.png b/erecht.client.ss/handbook/system/images/Zusammenspiel.mit.png Binary files differnew file mode 100644 index 000000000..4e7fcda67 --- /dev/null +++ b/erecht.client.ss/handbook/system/images/Zusammenspiel.mit.png diff --git a/erecht.client.ss/handbook/system/images/Zusammenspiel.ohne.png b/erecht.client.ss/handbook/system/images/Zusammenspiel.ohne.png Binary files differnew file mode 100644 index 000000000..0dc944cb9 --- /dev/null +++ b/erecht.client.ss/handbook/system/images/Zusammenspiel.ohne.png diff --git a/erecht.client.ss/handbook/system/system.html b/erecht.client.ss/handbook/system/system.html new file mode 100644 index 000000000..e4924f5fb --- /dev/null +++ b/erecht.client.ss/handbook/system/system.html @@ -0,0 +1,529 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<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"> + +</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> + +<hr> +<h1>Inhalt</h1> + +<ol> + + <li> + <p><a href="#einf%FChrung">Einführung</a></p> + + </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> + + <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> + + </ol> + + </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> + + </li> + +</ol> + +<hr> +<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>Dieses Handbuch beschreibt den Aufbau von MOA SL. Abschnitt 2 +bietet einen groben Überblick über die Funktionsweise +von MOA SL. Abschnitt 3 beschreibt die einzelnen Komponenenten, aus +denen MOA SL aufgebaut ist. Abschnitt 4 schließlich +beschreibt das Zusammenspiel der einzelnen Komponenten.</p> + +<p>Für die Installation und die Konfiguration von MOA SL +siehe <a href="../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 +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 +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> +<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> +</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> |
