aboutsummaryrefslogtreecommitdiff
path: root/erecht.client.ss/handbook/system
diff options
context:
space:
mode:
authorgregor <gregor@d688527b-c9ab-4aba-bd8d-4036d912da1d>2007-02-28 13:17:57 +0000
committergregor <gregor@d688527b-c9ab-4aba-bd8d-4036d912da1d>2007-02-28 13:17:57 +0000
commit1c900609d64445040e8c5bdbfa01ae1a0f563f43 (patch)
tree732cceb74a72b1d638835e632a59dfc38f358198 /erecht.client.ss/handbook/system
parentc034f4156169801d44308e8e505bb9c7e0cc33fb (diff)
downloadmoa-id-spss-1c900609d64445040e8c5bdbfa01ae1a0f563f43.tar.gz
moa-id-spss-1c900609d64445040e8c5bdbfa01ae1a0f563f43.tar.bz2
moa-id-spss-1c900609d64445040e8c5bdbfa01ae1a0f563f43.zip
Initial commit
git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/trunk@806 d688527b-c9ab-4aba-bd8d-4036d912da1d
Diffstat (limited to 'erecht.client.ss/handbook/system')
-rw-r--r--erecht.client.ss/handbook/system/images/Zusammenspiel.VSDbin0 -> 138240 bytes
-rw-r--r--erecht.client.ss/handbook/system/images/Zusammenspiel.mit.pngbin0 -> 48649 bytes
-rw-r--r--erecht.client.ss/handbook/system/images/Zusammenspiel.ohne.pngbin0 -> 36106 bytes
-rw-r--r--erecht.client.ss/handbook/system/system.html529
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
new file mode 100644
index 000000000..0088d5109
--- /dev/null
+++ b/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD
Binary files differ
diff --git a/erecht.client.ss/handbook/system/images/Zusammenspiel.mit.png b/erecht.client.ss/handbook/system/images/Zusammenspiel.mit.png
new file mode 100644
index 000000000..4e7fcda67
--- /dev/null
+++ b/erecht.client.ss/handbook/system/images/Zusammenspiel.mit.png
Binary files differ
diff --git a/erecht.client.ss/handbook/system/images/Zusammenspiel.ohne.png b/erecht.client.ss/handbook/system/images/Zusammenspiel.ohne.png
new file mode 100644
index 000000000..0dc944cb9
--- /dev/null
+++ b/erecht.client.ss/handbook/system/images/Zusammenspiel.ohne.png
Binary files differ
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&uuml;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&uuml;fung (SL), V 1.1</a></p>
+
+<p class="subtitle">Systemhandbuch</p>
+
+<hr>
+<h1>Inhalt</h1>
+
+<ol>
+
+ <li>
+ <p><a href="#einf%FChrung">Einf&uuml;hrung</a></p>
+
+ </li>
+
+ <li><a href="#%FCberblick">&Uuml;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&nbsp;<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&uuml;hrung" id="einf&uuml;hrung"></a>1
+Einf&uuml;hrung </h1>
+
+<p>Das Modul <span class="term">Serverseitige
+Signaturpr&uuml;fung</span> (MOA SL) ist als
+plattformunabh&auml;ngiges Modul ausgelegt, das als Webservice
+&uuml;ber HTTP bzw. HTTPS angesprochen werden kann. </p>
+
+<p>Dieses Handbuch beschreibt den Aufbau von MOA SL. Abschnitt 2
+bietet einen groben &Uuml;berblick &uuml;ber die Funktionsweise
+von MOA SL. Abschnitt 3 beschreibt die einzelnen Komponenenten, aus
+denen MOA SL aufgebaut ist. Abschnitt 4 schlie&szlig;lich
+beschreibt das Zusammenspiel der einzelnen Komponenten.</p>
+
+<p>F&uuml;r die Installation und die Konfiguration von MOA SL
+siehe <a href="../operation.html">Betriebshandbuch</a>.
+</p>
+
+<h1><a name="&uuml;berblick" id="&uuml;berblick"></a>2
+&Uuml;berblick</h1>
+
+<p>Das Modul <span class="term">Serverseitige
+Signaturpr&uuml;fung</span> (MOA SL) bietet f&uuml;r
+Signaturpr&uuml;fung eine serverseitige Implementierung einer
+B&uuml;rgerkarten-Umgebung entsprechend den <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen
+zur &ouml;sterreichischen B&uuml;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&uuml;tzt,
+und zwar jener zur Pr&uuml;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&szlig;lich die
+HTTP-Bindung unterst&uuml;tzt, wobei f&uuml;r diese Bindung
+zus&auml;tzlich folgende Einschr&auml;nkungen gelten:
+ <ul>
+
+ <li>Keine Unterst&uuml;tzung der Formularparameter
+RedirectURL und StylesheetURL.</li>
+
+ <li>Verpflichtende Verwendung des Formularparameters
+DataURL. </li>
+
+ <li>Keine Unterst&uuml;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&szlig;lich Fall 5e
+unterst&uuml;tzt. </li>
+
+ </ul>
+
+ </li>
+
+ <li>Hinsichtlich der Anzeigeformate des Security-Layer wird
+ausschlie&szlig;lich das <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/minimum/Minimum.html#anzeigeformate.formate.slxhtml">Standardanzeigeformat
+des Security-Layers</a> unterst&uuml;tzt. Liegen die von der
+zu pr&uuml;fenden Signatur gesicherten Daten in einem anderen
+Format vor, k&ouml;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&auml;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&auml;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&auml;lt ja zun&auml;chst den Request zur Pr&uuml;fung
+der XML-Signatur in einem Format entsprechend der&nbsp;<a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen
+zur &ouml;sterreichischen B&uuml;rgerkarte</a> in der
+Version 1.2 (SL-Request). Das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>
+erwartet sich jedoch den
+Request zur Pr&uuml;fung der XML-Signatur in einem Format
+entsprechend der Webservice-Schnittstelle f&uuml;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&uuml;hrung des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>s
+f&uuml;r eine passende Umsetzung des SL-Requests in den
+entsprechenden MOA-Request zu sorgen. </p>
+
+<p>Zur Erf&uuml;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&uuml;hrt,
+indem die Namen der XML-Elemente entsprechend angepasst werden. Danach werden am dadurch entstandenen MOA-Request noch folgende Modifikationen
+durchgef&uuml;hrt:
+<ul>
+ <li>Einf&uuml;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&uuml;gen des Elements <code>ReturnHashInputData</code>, das MOA SP anweist, die Hashinputdaten für jede <code>dsig:Reference</code>
+ der zu pr&uuml;fenden XML Signatur als Teil der MOA-Response zu retournieren.</li>
+
+ <li>Hinzuf&uuml;gen des verpflichtend anzugebenden Elements <code>TrustProfileID</code>, das MOA SP den Hinweis gibt, welches Vertrauensprofil
+ f&uuml;r die Evaluierung der Vertrauensw&uuml;rdigkeit des für die Erstellung der XML Signatur verwendeten Signaturzertifikats verwendet
+ werden soll.</li>
+</ul>
+</p>
+
+<p>Das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>
+w&uuml;rde dann die Antwort des Basismoduls MOA SP in einem Format
+entsprechend der Webservice-Schnittstelle f&uuml;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&uuml;fung
+der XML-Signatur in einem Format entsprechend der&nbsp;<a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen
+zur &ouml;sterreichischen B&uuml;rgerkarte</a> in der
+Version 1.2 (SL-Response). Aufgabe&nbsp;des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>s
+ist es daher, nach der Ausf&uuml;hrung&nbsp;des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>s
+f&uuml;r eine passende Umsetzung der MOA-Response in die
+entsprechende SL-Response zu sorgen.&nbsp;Zur Erf&uuml;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&szlig;lich, die JSP-Seite <code>resultoverview.jsp</code>
+einzubinden, die f&uuml;r eine benutzertaugliche HTML-Darstellung
+der SL-Response sorgt. Diese benutzertaugliche Darstellung wird dann
+tats&auml;chlich als finales Resultat des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>s
+an die Anwendung zur&uuml;ck&uuml;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&uuml;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&uuml;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&uuml;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&uuml;fung der XML-Signatur
+r&uuml;ck&uuml;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&auml;t des Webservice-Clients f&uuml;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&uuml;r die Aufbereitung
+einer&nbsp;benutzertauglichen HTML-Darstellung der SL-Response, die
+das Servlet&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>
+im Zusammenspiel mit dem Filter&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>
+erzeugt.&nbsp;</p>
+
+<p>Die f&uuml;r die Aufbereitung erforderlichen Informationen
+werden der JSP-Seite in Form von Java Beans zur Verf&uuml;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&uuml;gung:</p>
+
+<ul>
+
+ <li><code><abbr title="at.gv.egovernment.moa.spss.slinterface.beans.DataInfoBean">DataInfoBean</abbr></code>:
+Enth&auml;lt
+alle notwendigen Informationen zu den von der gepr&uuml;ften
+XML-Signatur gesicherten Dokumenten. Beim Erzeugen dieser Java Bean
+werden unter anderem die gesicherten Dokumente f&uuml;r den
+sp&auml;teren Abruf durch die Anwendung (vergleiche
+ <a href="#komponenten.hashinputservlet">Abschnitt 3.4</a>)
+im Filesystem zwischengespeichert sowie die Pr&uuml;fung
+vorgenommen, ob es sich bei einem gesicherten Dokument um ein
+XHTML-Dokument gem&auml;&szlig;&nbsp;<a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen
+zur &ouml;sterreichischen B&uuml;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&auml;lt
+alle notwendigen Informationen zum Ersteller der gepr&uuml;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&auml;lt
+alle notwendigen Informationen zum Ergebnis der Pr&uuml;fung der
+XML-Signatur.&nbsp;Die Bean ist im Servlet Scope abgelegt.</li>
+
+</ul>
+
+<p>Die JSP-Seite <code>resultOverview.jsp</code>
+erzeugt aus den mittels der erw&auml;hnten Java Beans zur
+Verf&uuml;gung gestellten Informationen eine HTML-Darstellung.
+Diese HTML-Darstellung ist in die folgenden Informationsbl&ouml;cke
+unterteilt:</p>
+
+<ul>
+
+ <li>Informationen zum Ersteller der gepr&uuml;ften
+XML-Signatur: Name des Erstellers, Name des Ausstellers des
+Zertifikats, Angaben zur Qualit&auml;t des Zertifikats.</li>
+
+ <li>Informationen zum Ergebnis der Pr&uuml;fung der
+XML-Signatur: Ergebnis der Signaturpr&uuml;fung, Ergebnis der
+Pr&uuml;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&uuml;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&uuml;r die Verf&uuml;gbarkeit der von der gepr&uuml;ften
+XML-Signatur gesicherten Dokumente verantwortlich.&nbsp;</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&uuml;hren jeweils auf das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code>.&nbsp;</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&auml;hnte&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.beans.DataInfoBean">DataInfoBean</abbr></code>:
+gespeichert, die alle notwendigen Informationen enth&auml;lt, damit
+das Servlet das angefragte gesicherte Dokument aus dem Filesystem lesen
+und als Ergebnis an den Browser zur&uuml;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&uuml;ften
+XML-Signatur durch den Benutzer f&uuml;r die Weiterleitung der
+SL-Response an den DataURL-Server sowie f&uuml;r die Weiterleitung
+der daraus resultierenden Antwort des DataURL-Servers an den Benutzer
+verantwortlich.</p>
+
+<p>Damit verh&auml;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&nbsp;<a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen
+zur &ouml;sterreichischen B&uuml;rgerkarte</a> in der
+Version 1.2) in&nbsp;<a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/bindings/Bindings.html#http.ablauf.schritte">Abschnitt
+3.2.3</a> f&uuml;r den Fall 5e beschrieben ist: Wenn der
+Benutzer die HTML-Aufbereitung der Ergebnisse der gepr&uuml;ften
+XML-Signatur gesichtet hat und durch Verfolgung des darin enthaltenen
+Links quittiert, sendet das&nbsp;<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&uuml;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&nbsp;<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.&nbsp;</p>
+
+<p>Nachdem mit diesem Schritt die Bearbeitung der zur
+Pr&uuml;fung &uuml;bermittelten XML-Signatur durch MOA-SL
+abgeschlossen ist, wird am Ende des&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code>
+die Session und damit alle gespeicherten Informationen zur
+gepr&uuml;ften XML-Signatur&nbsp;gel&ouml;scht.&nbsp;</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&uuml;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&nbsp;nicht&nbsp;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&nbsp;Rewrite-Proxy sorgt
+f&uuml;r die Umsetzung des aus dem umgeschriebenen Link
+resultierenden
+Requests an ihn selbst in einen Request an MOA SL.&nbsp;</p>
+
+<p>Sinnvoll ist diese Konfigurationsvariante dann, wenn MOA SL
+nicht direkt vom Internet aus erreichbar sein soll, sondern nur auf dem
+Umweg &uuml;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 &uuml;bergebene
+URL tats&auml;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&auml;ndert
+werden m&uuml;ssen:</p>
+<ul>
+ <li>Definition der URLs, unter denen die Servlets&nbsp;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&uuml;r das Servlet&nbsp;<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>). &nbsp;Die Konfiguration ist so&nbsp;eingerichtet, dass f&uuml;r das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> genau ein Filter, n&auml;mlich <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>&nbsp;konfiguriert ist.&nbsp;&nbsp;</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&uuml;fung der Signatur: Anfrage wird eigentlich an&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> gerichtet, durch die Filter-Konfiguration &uuml;ber den Deployment-Descriptor web.xml wird jedoch vorher und nachher der&nbsp;<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&nbsp;<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>&Uuml;ber die HTML-Ansicht der SL-Response kann der Anwender
+die einzelnen, von der XML-Signatur gesicherten&nbsp;Dokumente abrufen.
+Die Links f&uuml;r die Dokumente verweisen auf das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code>, die Zuordnung im Servlet passiert &uuml;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 &uuml;ber einen Link in der
+HTML-Darstellung, der auf das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> verweist. Das&nbsp;<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 &uuml;bermittelte SL-Response; diese
+Antwort wird vom&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> unver&auml;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
+&uuml;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&uuml;fung der Signatur: Anfrage wird eigentlich an&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> gerichtet, durch die Filter-Konfiguration &uuml;ber den Deployment-Descriptor web.xml wird jedoch vorher und nachher der&nbsp;<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&nbsp;<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 &uuml;ber den Rewrite-Proxy, der die Anfrage-URL passend umschreibt.</p>
+ </td>
+ </tr>
+ <tr>
+ <td>3,4</td>
+ <td>
+ <p>&Uuml;ber
+die HTML-Ansicht der SL-Response kann der Anwender die einzelnen, von
+der XML-Signatur gesicherten&nbsp;Dokumente abrufen. Die Links f&uuml;r die
+Dokumente verweisen nicht direkt auf das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code>, sondern zun&auml;chst auf den Rewrite-Proxy, der die Links passend auf das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code> umsetzt. Die Zuordnung im Servlet passiert &uuml;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 &uuml;ber einen Link in der HTML-Darstellung,
+der&nbsp;nicht direkt auf das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> verweist, sondern zun&auml;chst auf den Rewrite-Proxy, der die Links passend auf das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> &nbsp;umsetzt. Das&nbsp;<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 &uuml;bermittelte SL-Response; diese Antwort
+wird vom&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> unver&auml;ndert an den Antwender weitergeleitet.</p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+</div>
+</div>
+</body>
+</html>