<!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/MOA.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>