From 4075bf26b65cf2be4c55f2e9cbdc1b854a41dbce Mon Sep 17 00:00:00 2001
From: pdanner 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: Die Klasse Der Zur Erfüllung dieser
-Aufgabe bedient sich der
-
-
-
-
-
-
-
-
-
-
-
-
- Open
-Source
-
-
-
-für das E-Government
-
-
-
-Inhalt
-
-
-
-
-
-
-
-
-
-
-1
-Einführung
-
-2
-Überblick
-
-
-
-
-
-
-
-
-
- 3
-Komponenten
-
-3.1
-Der Filter
-
-SL2MOAFilter
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.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 SL2MOAFilter
s
-ist es daher, vor der Ausführung des MOAServlet
s
-für eine passende Umsetzung des SL-Requests in den
-entsprechenden MOA-Request zu sorgen. 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:
-
-
-DateTime
Elements in den MOA-Request, wenn bisher kein solches existiert, und wenn in der im MOA-Request
- enthaltenen XML Signatur kein Signaturattribut etsi:SigningTime
existiert und wenn aus dem E-Recht XML Dokument, das von der
- XML-Signatur signiert wird, die Metainformation (Attribut h-created
im Wurzelelement erechtdok
) des
- Erzeugungszeitpunkts des E-Recht XML Dokuments erfolgreich extrahiert werden konnte.ReturnHashInputData
, das MOA SP anweist, die Hashinputdaten für jede dsig:Reference
- der zu prüfenden XML Signatur als Teil der MOA-Response zu retournieren.TrustProfileID
, 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.
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 SL2MOAFilter
s
-ist es daher, nach der Ausführung des MOAServlet
s
-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 MOAServlet
s
-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.
-
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 HttpServletRequest
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.
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.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:
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.
- -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.
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.
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.
web.xml
-Im Deployment Descriptor web.xml
des
-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 |
-