MOA SL - Systemhandbuch

Das Modul Serverseitige +Signaturprüfung (MOA SL) ist als +plattformunabhängiges Modul ausgelegt, das als Webservice +über HTTP bzw. HTTPS angesprochen werden kann.

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.

Für die Installation und die Konfiguration von MOA SL +siehe Betriebshandbuch. +

2 +Überblick

Das Modul Serverseitige +Signaturprüfung (MOA SL) bietet für +Signaturprüfung eine serverseitige Implementierung einer +Bürgerkarten-Umgebung entsprechend den Spezifikationen +zur österreichischen Bürgerkarte in der +Version 1.2.

3 +Komponenten

3.1 +Der Filter SL2MOAFilter

Die Klasse SL2MOAFilter +ist ein +Filter, +der einerseits +den HttpServletRequest +verändert, bevor er an das Servlet MOAServlet +weitergeleitet wird, und andererseits den HttpServletResponse +verändert, nachdem er vom Servlet MOAServlet +bearbeitet wurde.

Der HttpServletRequest +enhält ja zunächst den Request zur Prüfung +der XML-Signatur in einem Format entsprechend der Spezifikationen +zur österreichischen Bürgerkarte in der +Version 1.2 (SL-Request). Das MOAServlet +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 SL2MOAFilters +ist es daher, vor der Ausführung des MOAServlets +für eine passende Umsetzung des SL-Requests in den +entsprechenden MOA-Request zu sorgen.

Zur Erfüllung dieser +Aufgabe bedient sich der SL2MOAFilter +der Klasse SL2MOA, +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: +

Das MOAServlet +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 MOAServlet +aufruft, erwartet sich jedoch die Antwort auf den Request zur +Prüfung +der XML-Signatur in einem Format entsprechend der Spezifikationen +zur österreichischen Bürgerkarte in der +Version 1.2 (SL-Response). Aufgabe des SL2MOAFilters +ist es daher, nach der Ausführung des MOAServlets +für eine passende Umsetzung der MOA-Response in die +entsprechende SL-Response zu sorgen. Zur Erfüllung +dieser +Aufgabe bedient sich der SL2MOAFilter +der Klasse MOA2SL, +in der die +Response-Transformation gekapselt ist.

Eine weitere Aufgabe der Klasse SL2MOAFilter +ist es schließlich, die JSP-Seite resultoverview.jsp +einzubinden, die für eine benutzertaugliche HTML-Darstellung +der SL-Response sorgt. Diese benutzertaugliche Darstellung wird dann +tatsächlich als finales Resultat des MOAServlets +an die Anwendung zurückübermittelt. Bevor die +JSP-Seite eingebunden wird, erzeugt SL2MOAFilter +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 Abschnitt 3.3. +

3.2 +Das Servlet MOAServlet

Die Klasse


+MOAServlet

ist ein HttpServlet +und als solches für die Kommunikation mit dem Basismodul MOA +SP verantwortlich.

Das Servlet liest aus dem ServletInputStream +des HttpServletRequests +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.

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 ServletOutputStream +der HttpServletResponse.

Das MOAServlet bedient sich zur Kommunikation mit MOA SP der +Klasse


+MOAInvoker

, in der die +Funktionalität des Webservice-Clients für MOA SP +gekapselt ist.

3.3 Die JSP-Seite resultOverview.jsp

Die JSP-Seite resultOverview.jsp ist +verantwortlich für die Aufbereitung +einer benutzertauglichen HTML-Darstellung der SL-Response, die +das Servlet MOAServlet +im Zusammenspiel mit dem Filter SL2MOAFilter +erzeugt.

Die für die Aufbereitung erforderlichen Informationen +werden der JSP-Seite in Form von Java Beans zur Verfügung +gestellt, die zuvor vom

SL2MOAFilter
+

erzeugt worden sind (vergleiche Abschnitt 3.1). +Folgende Java Beans stehen der JSP-Seite zur Verfügung:

Die JSP-Seite resultOverview.jsp +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:

3.4 Das Servlet HashInputDataServlet

Das Servlet HashInputServlet +ist +für die Verfügbarkeit der von der geprüften +XML-Signatur gesicherten Dokumente verantwortlich.

In der HTML-Aufbereitung der SL-Response, die von der +JSP-Seite resultOverview.jsp erzeugt wird, +(vergleiche Abschnitt +3.3) befinden sich Links auf alle gesicherten Dokumente. +Diese Links führen jeweils auf das Servlet HashInputServlet.

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 Abschnitt 3.3 +erwähnte DataInfoBean: +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.

3.5 +Das Servlet ReturnServlet

Das Servlet ReturnServlet +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.

Damit verhält sich MOA SL genau wie in der +Spezifikation Transportprotokolle +Security-Layer (Teil der Spezifikationen +zur österreichischen Bürgerkarte in der +Version 1.2) in Abschnitt +3.2.3 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 ReturnServlet +die SL-Response an den DataURL-Server. Die URL des DataURL-Servers +wurde von der Anwendung im ursprünglichen Request an das MOAServlet +als Formular-Parameter angegeben. Der DataURL-Server antwortet auf das +Eintreffen der SL-Response mit einem HTTP-Response an das ReturnServlet, +diese wird vom ReturnServlet +als Antwort auf das Quittieren der HTML-Darstellung an den Browser +weitergeleitet.

Nachdem mit diesem Schritt die Bearbeitung der zur +Prüfung übermittelten XML-Signatur durch MOA-SL +abgeschlossen ist, wird am Ende des ReturnServlet +die Session und damit alle gespeicherten Informationen zur +geprüften XML-Signatur gelöscht.

3.6 +Die Klasse URLRewriter

Die Klasse URLRewriter +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.

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.

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.

Die Methode rewrite der Klasse URLRewriter +wird bei der Erstellung der HTML-Aufbereitung der SL-Response durch die +JSP-Seite resultOverview.jsp 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.

3.7 +Der Deployment Descriptor web.xml

+Im Deployment Descriptor web.xmldes +Web Archives (WAR-File) von MOA SL sind im Wesentlichen folgende +Konfigurationen eingerichtet, die im Normalfall nicht verändert +werden müssen:

4 +Zusammenspiel der Komponenten

4.1 Basisablauf

Die nachfolgende Grafik stellt das Zusammenspiel der Komponenten aus Abschnitt 3 mit dem Anwender und dem DataURL-Server dar.

4.2 Ablauf mit Rewrite-Proxy

Zusemmenspiel der Komponenten - mit Rewrite-Proxy

+ + + + + + + + + + + + + + + +

1, 2	+ Prüfung der Signatur: Anfrage wird eigentlich an `MOAServlet` gerichtet, durch die Filter-Konfiguration über den Deployment-Descriptor web.xml wird jedoch vorher und nachher der `SL2MOAFilter` dazwischengeschalten. Die Aufbereitung der HTML-Darstellung der SL-Response wird vom `SL2MOAFilter` an die JSP-Seite `resultOverview.jsp` delegiert. Die Anfrage des Anwenders wird nicht direkt an das `MOAServlet` gerichtet, sondern über den Rewrite-Proxy, der die Anfrage-URL passend umschreibt. +
3,4	+ Ü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 `HashInputServlet`, sondern zunächst auf den Rewrite-Proxy, der die Links passend auf das `HashInputServlet` umsetzt. Die Zuordnung im Servlet passiert über URL-Parameter (Session-ID, fortlaufende Nummer des Dokuments). +
5, 6, 7, 8	+ 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 `ReturnServlet` verweist, sondern zunächst auf den Rewrite-Proxy, der die Links passend auf das `ReturnServlet` umsetzt. Das `ReturnServlet` +sendet die SL-Response an den DataURL-Server. Der DataURL-Server +antwortet entsprechend auf die übermittelte SL-Response; diese Antwort +wird vom `ReturnServlet` unverändert an den Antwender weitergeleitet. +

Inhalt

1 +Einführung

2 +Überblick

3 +Komponenten

3.1 +Der Filter `SL2MOAFilter`

3.2 +Das Servlet `MOAServlet`

3.3 Die JSP-Seite `resultOverview.jsp`

3.4 Das Servlet `HashInputDataServlet`

3.5 +Das Servlet `ReturnServlet`

3.6 +Die Klasse `URLRewriter`

3.7 +Der Deployment Descriptor `web.xml`

4 +Zusammenspiel der Komponenten

4.1 Basisablauf

4.2 Ablauf mit Rewrite-Proxy

1, 2	+ Prüfung der Signatur: Anfrage wird eigentlich an `MOAServlet` gerichtet, durch die Filter-Konfiguration über den Deployment-Descriptor web.xml wird jedoch vorher und nachher der `SL2MOAFilter` dazwischengeschalten. Die Aufbereitung der HTML-Darstellung der SL-Response wird vom `SL2MOAFilter` an die JSP-Seite `resultOverview.jsp` delegiert. +
3,4	+ Ü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 `HashInputServlet`, die Zuordnung im Servlet passiert über URL-Parameter (Session-ID, fortlaufende Nummer des Dokuments). +
5, 6, 7, 8	+ 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 `ReturnServlet` verweist. Das `ReturnServlet` +sendet die SL-Response an den DataURL-Server. Der DataURL-Server +antwortet entsprechend auf die übermittelte SL-Response; diese +Antwort wird vom `ReturnServlet` unverändert an den Antwender weitergeleitet. +

Inhalt

1 +Einführung

2 +Überblick

3 +Komponenten

3.1 +Der Filter SL2MOAFilter

3.2 +Das Servlet MOAServlet

3.3 Die JSP-Seite resultOverview.jsp

3.4 Das Servlet HashInputDataServlet

3.5 +Das Servlet ReturnServlet

3.6 +Die Klasse URLRewriter

3.7 +Der Deployment Descriptor web.xml

4 +Zusammenspiel der Komponenten

4.1 Basisablauf

4.2 Ablauf mit Rewrite-Proxy

3.1 +Der Filter `SL2MOAFilter`

3.2 +Das Servlet `MOAServlet`

3.3 Die JSP-Seite `resultOverview.jsp`

3.4 Das Servlet `HashInputDataServlet`

3.5 +Das Servlet `ReturnServlet`

3.6 +Die Klasse `URLRewriter`

3.7 +Der Deployment Descriptor `web.xml`