- -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. 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 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 |
-