für das E-Government
|
Open
Source für das E-Government |
|
MOA: Serverseitige Signaturprüfung (SL), V 1.1
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.
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.
Der Funktionsumfang von MOA SL kann wie folgt zusammengefasst werden:
SL2MOAFilterDie 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.
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.
MOAServletDie 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.
resultOverview.jspDie 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:
DataInfoBean:
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
Abschnitt 3.4)
im Filesystem zwischengespeichert sowie die Prüfung
vorgenommen, ob es sich bei einem gesicherten Dokument um ein
XHTML-Dokument gemäß Spezifikationen
zur österreichischen Bürgerkarte in der
Version 1.2 handelt (SLXHTML-Dokument) oder nicht. Die Bean ist im
Session Scope abgelegt.SignerInfoBean:
Enthält
alle notwendigen Informationen zum Ersteller der geprüften
XML-Signatur. Die Bean ist im Servlet Scope abgelegt.ChecksInfoBean:
Enthält
alle notwendigen Informationen zum Ergebnis der Prüfung der
XML-Signatur. Die Bean ist im Servlet Scope abgelegt.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:
Ein Beispiel für die resultierende HTML-Darstellung befindet sich hier.
HashInputDataServletDas 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.
ReturnServletDas 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.
URLRewriterDie 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.
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:
MOAServlet, HashInputServlet, ReturnServlet) relativ zum Root der Web Application erreichbar sind (XML-Elemente servlet bzw. servlet-mapping).MOAServlet zur Anwendung kommen sollen (XML Elemente filter bzw. filter-mapping). Die Konfiguration ist so eingerichtet, dass für das Servlet MOAServlet genau ein Filter, nämlich SL2MOAFilter konfiguriert ist. Die nachfolgende Grafik stellt das Zusammenspiel der Komponenten aus Abschnitt 3 mit dem Anwender und dem DataURL-Server dar.
| 1, 2 |
Prüfung der Signatur: Anfrage wird eigentlich an |
| 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 |
| 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 |
| 1, 2 |
Prüfung der Signatur: Anfrage wird eigentlich an |
| 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 |
| 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 |