diff options
Diffstat (limited to 'spss.slinterface/handbook/system')
| -rw-r--r-- | spss.slinterface/handbook/system/images/Zusammenspiel.VSD | bin | 138240 -> 0 bytes | |||
| -rw-r--r-- | spss.slinterface/handbook/system/images/Zusammenspiel.mit.png | bin | 48649 -> 0 bytes | |||
| -rw-r--r-- | spss.slinterface/handbook/system/images/Zusammenspiel.ohne.png | bin | 36106 -> 0 bytes | |||
| -rw-r--r-- | spss.slinterface/handbook/system/system.html | 529 |
4 files changed, 0 insertions, 529 deletions
diff --git a/spss.slinterface/handbook/system/images/Zusammenspiel.VSD b/spss.slinterface/handbook/system/images/Zusammenspiel.VSD Binary files differdeleted file mode 100644 index 0088d5109..000000000 --- a/spss.slinterface/handbook/system/images/Zusammenspiel.VSD +++ /dev/null diff --git a/spss.slinterface/handbook/system/images/Zusammenspiel.mit.png b/spss.slinterface/handbook/system/images/Zusammenspiel.mit.png Binary files differdeleted file mode 100644 index 4e7fcda67..000000000 --- a/spss.slinterface/handbook/system/images/Zusammenspiel.mit.png +++ /dev/null diff --git a/spss.slinterface/handbook/system/images/Zusammenspiel.ohne.png b/spss.slinterface/handbook/system/images/Zusammenspiel.ohne.png Binary files differdeleted file mode 100644 index 0dc944cb9..000000000 --- a/spss.slinterface/handbook/system/images/Zusammenspiel.ohne.png +++ /dev/null diff --git a/spss.slinterface/handbook/system/system.html b/spss.slinterface/handbook/system/system.html deleted file mode 100644 index 7831b7eb6..000000000 --- a/spss.slinterface/handbook/system/system.html +++ /dev/null @@ -1,529 +0,0 @@ -<!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> |
